|Re: [hatari-devel] Hatari UI with Qt?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On maanantai 26 marraskuu 2012, Nicolas Pomarède wrote:
> > Normal UI interaction is modal, and it's Hatari that invokes the UI.
> > Emulation is stopped while user changes the options, and all the
> > changes are applied at the same time before emulation continues. The
> > UI part will next time get the changed settings.
> Not always modal ; consider a button in the UI that would allow to go to
> fast forward mode when pressed (as in Steem). In that case, emulation is
> not stopped, it's immediatly updated.
That's also how it works in the Python UI, but that embeds the Hatari
UI from another process and SDL window embedding has its own problems
like portability, and when in same process, also event handling.
(as I noted in the other mail)
> >> - fileselector
> Maybe we can loose zip support when using the QT UI, but IMO we should
> keep it for the SDL UI.
> Like it or not, but most/all games/demos you can download on various
> site are zip file.
> Being able to download a zip file and use it directly
> is really handy (the gain of gzip compared to zip on a 700 K floppy is
> neglictable) and also many users on Windows/Mac are not always used to
> unzip their files (in the Atari emulation world, zip support is standard
> amongst major emulator)
So, if Qt would be the primary UI for Hatari on all platforms, how
the users would select disk images within zip archives with that?
Are you saying that:
- instead of Qt fsel user should get SDL fsel,
- user needs to be able to use SDL GUI within Qt GUI,
- that you have a volunteer for adding zip archive support to Qt fsel,
- Hatari readme should point users to WinZip etc download sites, or
- Hatari should have separate UI for extracting disk images from