Consider switching from gtk2hs to haskell-gi

[Mitsutoshi Aoe]

haskell-gi seems to be better maintained than gtk2hs is. I think we should consider switching to haskell-gi.

There are some questions:

• Is cross-platform support of haskell-gi good enough? In particular how well is it supported on Windows?
• Is the extra runtime dependency (on GIRepository) a problem? Hopefully no.
• Are the bigger build dependencies an issue? Probably no.

The transition to haskell-gi means we're going to port ThreadScope from GTK 2 to GTK 3, which is not quite trivial.

[Lautaro Emanuel]

I was wondering if maybe dropping GTK completely in favor of an HTML output like haddock does is the way to go forward.

• Currently, the builds under the release section don't work for Windows (you need to get the GTK, Cairo and some other dependencies .dlls which are not bundled, and that also can fail easily).
• OSX is not very user-friendly (installing dependencies through brew, launching the app from the terminal).
• Haven't tried Linux.

ThreadScope's UI is not very complex (and certainly dated by today's standards) so porting it to HTML/CSS/JS shouldn't be too complex. Also, this could be a good opportunity to give the app a new, modern look. I'll look into it in the following months, but I can't promise anything

[Mikolaj Konarski]

@emlautarom1 : Would you use GHCJS to generate the JS that would be communicating with a native app somehow or do you have anything else in mind? Because, unlike the haddock output, this is an interactive app with a lot of heavy computation going on.

[Lautaro Emanuel]

Well, I've been thinking about some options on how to deal with that. First, I must clarify that I'm not an expert on the Haskell ecosystems (been tinkering with the language for the last year) so maybe I'm missing a better tool for the job. Currently, this is what I have in mind:

• Haskell just does not have a solid GUI toolkit like Java Swing, JavaFX or WPF (C#), so I would avoid any attempt on a native app.

• We could build static files from a CLI tool threadscope and use the browser to see the contents a la haddock. I haven't played a lot with the current source code but if, as you say, there are a lot of heavy calculations that we can't run in the browser then just building static files won't be enough.

• In case the computations are simple enough we could try to just write those in JS (not too fond of this idea tbh). Another option would be to write those in PureScript, but we would be introducing a new dependency (albeit only at build time). I did not consider using either GHCJS nor Haste since I haven't used those before.

• If we just can't move the computations onto the browser then I think we could:

  • Build static HTML/CSS/JS files, serve them with a minimal web server and communicate the web front-end with it through either a REST API or WebSockets.
  • Use a library like threepenny-gui to handle pretty much everything.
  • Go all the way and use something like ElectronJS to get a "native" app, spawning a background threadscope server and send messages between the electron app and the server.

• For the HTML UI and interactivity, I would use something battle-tested like Elm instead of some Haskell HTML DSL. For example, I found a nice Elm package that could help with data visualization: elm-visualize. Again, this would introduce a new dependency, so it should be considered carefully.

In summary, there are a lot of things to consider and I'm not sold on any solution. I'll dig into the current source code and eventually try to build some PoC.

[Simon Marlow]

I think the main issue with converting to HTML/JS would be ThreadScope's interactive zooming and navigation - it's not clear to me that you could make a web-based UI that performs well enough to support that. But I'd be happy to be proved wrong.

[Matthew Pickering]

speedscope.app does quite well processing big time profiles, there are some notes about the implementation in this post. It seems they are implementing a lot of the rendering directly in WebGL.