| Re: [hatari-devel] Hatari UI with Qt? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Hatari UI with Qt?
- From: Didier Plaza <didier.plaza@xxxxxxxxx>
- Date: Mon, 26 Nov 2012 00:03:34 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=8Aa+b9IyvgC7Fk5vMMkE3CeXwWxxwFkM4EJWrob9Zgw=; b=q5+EupUhCZKi7ikrAMq0ES/Xp/7vMe1MExZc8jnlKIeM7ubiZTsZ9oJG/CeRCtitef o9S1sj1T+zkFBoOqliVAXt+qbhNncaU1Q/svNWJzT/BV3PB5q4iVpDYhYwhFDBA0cNMZ RrL9LWYfeemwTPEi9iF68LieGL+IEASiSmTsn5URRxZiLoR27iRwHR0dg7Gr7+pEoM5a bbWlUIdApxWaTJ0NKDla3f0cq9Xrg1lTV+l0/ZuEBSDtHa0rJyFBrUb1+dt3BrHxzCyW Z/PVcykfEACyyHUWmPjdmZLclj1uDyHj3xXnPffi1yf1KQa2yqHuFmcHHGx87la4Pvj6 O33Q==
You was faster than me :). I totally agree.
Le 25 nov. 2012 à 23:51, Nicolas Pomarède a écrit :
> 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
>
>