| Re: [hatari-devel] Hatari UI with Qt? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 25/11/2012 23:03, Eero Tamminen wrote:
Hi,
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?
Hello
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.
Nicolas