MTGUI: Cross-platform backend, GTK? wxWidgets?

[flibitijibibo]

Virtually no work has been done for MTGUI, except for a small batch of declarations that use GTK.

While this is open, feel free to make cases for using GTK or wxWidgets. I prefer wx, but that may require a bit more work depending on how much Yannick prepared MTGUI for GTK (if at all).

[irrenhaus3]

Just from looking at their API's I'd tend towards wxWidgets, since it's a lot less callback-ish and has a somewhat consistent modern-c++-friendly API. e.g. Event receivers allow you to bind an even handler via a Bind() function that works with std::function, lambdas and function pointers, which keeps everything in scope nicely and doesn't throw macros all over the place. I haven't used either of them so far though, so I can't really say anything about differences in functionality.

[AmEv7Fam]

I've also got a bit of experience with wx myself, albeit on Python.

GUI seems to be "there", just not hooked up to anything, really,

[liquidscorpio]

Is there any reason QT is not even in consideration?

[flibitijibibo]

Back when this was posted ImGui hadn't been made yet, I would absolutely use this over anything else:

https://github.com/ocornut/imgui

[AmEv7Fam]

Whoa. Thanks @flibitijibibo! Looks like it would be perfect for what we're doing!

[liquidscorpio]

From the (ImGui) repository's README.md:

You can alter the look of the interface to some degree: changing colors, sizes, padding, rounding, fonts. However, as ImGui is designed and optimised to create debug tools, the amount of skinning you can apply is limited. There is only so much you can stray away from the default look and feel of the interface.

I'd, honestly, want to go with something that delivers a native UX experience; even if, to begin with, we support minimal set of platforms or even just stick to windows with proper UI abstractions. If we try too much at first go, we might end up overwhelmed and loose motivation.

[AmEv7Fam]

Hrmm....

Quite the predicament.

I do have experience with QT Designer myself.

I think the main thing is we need to find an appropriate engine, and stick with it.

I also think playing with the debug .EXE, seeing how the current interface is lke, and poking through the log it outputs, will help us the most.

Darn my rambling!

[AmEv7Fam]

It looks like a move to QT might actually not be a bad idea. It seems like a lot of the code might be able to be replaced by native QT functions.

IIRC, Yannick said that a lot of the functions were just "there", not yet hooked up to much. I think he also said MTAudio was not hooked up at all.

I'm not in favor of a total codebase rewrite (Netscape, anybody?), but I feel that a move to QT and related functions could make our code much more manageable.