Questions regarding the structure and implementation of the Calligraphy project [Summer of Haskell]

[DMills27]

I'm the selected Summer of Haskell participant for the Calligraphy project and I'm writing to seek some clarification about the intended refactoring of Calligraphy. Are we looking to compartmentalise various aspects of the project (CLI, GUI, etc) in a manner similar to, say, how pandoc segregates its various components, that is, each component has its own folder with its own cabal file so that that specific component can be used independently if needed or all at once if the cabal file is run from the main folder? See image below for further clarification.

Moreover, as it relates to the GUI component, I was considering using GTK based on the positive impression I gained from this video. Would this be considered a good choice? And if not are there an other GUI frameworks that could be considered instead?

[jonascarpay]

Hi @DMills27, thanks for your participation, and for reaching out.

Are we looking to compartmentalise various aspects of the project (CLI, GUI, etc) in a manner similar to, say, how pandoc segregates its various components

Yes, I think pandoc is a great role model for where we'd like to be.

And if not are there an other GUI frameworks that could be considered instead?

I think it depends on your goal; the GUI could just be an interactive version of the CLI with immediate visual feedback, but it could also be a more interactive call graph explorer similar to what @considerate was doing in #1, and @afcondon is doing here.

In the first case, you can still just have graphviz render the graph, and then presenting it in a native GUI app would be pretty straightforward, I imagine GTK would be fine but I don't really have any significant GUI programming experience.

In the second case I think you'd probably want to do something browser-based because you get a bunch of graph/dataviz JS libraries for free. Maybe you'd spin up a web server, maybe you'd write a single-page HTML file similar to criterion reports, both work.

FWIW, I would strongly recommend the first approach, since it's much easier to deliver a working, useful product within a reasonable timeframe. The design space for interactive code exploration is enormous, and if you don't already have a clear vision/approach/plan, you can very easily get lost.