Re: [hatari-devel] Hatari UI with Qt?

[ Thread Index | Date Index | More Archives ]

On 25/11/2012 23:03, Eero Tamminen wrote:

I was giving some thought for Hatari UI done with
a compiled language and some widget toolkit (not SDL).

Is everybody still thinking that Qt would be the best alternative
for this?  Even in the light of the Qt ownership changes and some
uncertainty of its future?

As Qt is C++, it means that:
- Hatari will have Qt & C++-compiler dependencies
- Either all code is compiled with:
   - C++ compiler and needs to be cleaned of C stuff that's
     not valid in C++ (most already done I guess)
   - UI part is compiled with C++ compiler and rest is
     compiled with C-compiler in which case headers need
     to declared that prototypes in them aren't C++ ones
     (i.e. those symbols don't have C++ mangling when linked)

Which one of the latter options it should be?


considering that QT UI should remain an option, I think we should keep a model where most code is C (as it is now).

Then adding a generic UI layer between current hatari and SDL UI or QT UI. So, QT would only know this layer, and only it should be C++ aware (with some slight exceptions in other part maybe).

Each UI type could be considered as a "control plugin" (to extend it to the socket code as well).

It would be more work, but I think the best would be to have a structure of things to change from the UI for each part (cpu, sound, system, ...).

Then SDL or QT UI would manipulate only these structures (either directly, or using some set/get functions with some flags to indicate if the option was changed in the UI or not).

And these structure would be passed to the generic UI/control layer (that would be independant of the toolkit) and propagated to each "low level" part (video.c, mfp.c, sound.c, ...).

The socket layer could also be considered has an "UI plugin", so in the end we would have a way to add as many UI/control plugins that we want (so, someone could even write a GTK UI or whatever).

For the generic layer, we need to define what generic access method we need when Hatari requires some informations from the user :
 - dialog box with 1..n choices
 - fileselector
- input window with 1..n text/type/value parameters and optional layout parameter ?

If I recall the c64 "VICE" emulator has a similar layout, that allows it to come with several UI methods.

I could probably start looking into coding the UI itself next
month, if somebody will later on look into CMake integration
for that. :-)

That would be great, as for cmake integration, I don't think it will be a problem with QT.

Regarding QT's future, we can't know how it evolve, but it seems it's quite alive, with QT 5 coming soon. And even so it certainly remains the most integrated linux/windows/os x and IMO the best choice for a new UI (which doesn't mean some other toolkit could not be used later as a 2nd choice, using the above "plugin" mechanism).

PS : on a different subject, note that SDL 2.0 is supposed to be released soon (a few months ?), so maybe we will be able to update hatari to compile with it before next Hatari's release (it's already possible to test this by building sdl 2 yourself, but I didn't have time to check this for now). It should fix some OSX fullscreen problem and also add some vsync options, amongst other things.


Mail converted by MHonArc 2.6.19+