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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 26 marraskuu 2012, Nicolas Pomarède wrote:
> Le 26/11/2012 10:07, Eero Tamminen a écrit :
> > Some CMake option would need to be introduced to state whether
> > Hatari is built with Qt UI.  That would affect for example to
> > where its main() function is.
> 
> Is it necessary to use QT's main() function ? Some toolkits provide
> wrapper functions to their internal C++ main(), so that you can call it
> from your existing C main() function.
> So, there's only one main() function (in our case in main.c) and it
> would for example call qt_main()  (but I don't know if QT provides such
> a function)

Sorry I was imprecise, with main I meant event mainloop.

The loop where the Hatari code runs is in the top level m68k emulation
instruction processing one, and event processing Main_EventHandler()
function is called from IKBD_InterruptHandler_AutoSend().


For now I'm thinking of using the SDL code for Atari screen and sound 
output.  However, both event and screen output have problems when
both SDL and Qt are used.

As for having the actual UI done with Qt, there are couple of options:
A. invoke the Qt UI only when user invokes options/query/fsel dialog,
   i.e. it's more like replacement for the SDL UI
B. embed the Hatari screen into Qt window with application menu and
   extra UI elements around the Hatari screen like the Python UI has


A) option would be easy for the event processing part as Qt stuff would be
quite self contained in its event prosessing and have its own window.
However, then you probably couldn't use options when in fullscreen, so
invoking anything from Qt would need to disable fullscreen first.


As to B), both event and screen handling would be problem.

Events:

The SDL event processing needs to be interfaced with Qt and as far I've read
from web, one would need to map all relevant Qt events to SDL events for
that to work, or I would need to reimplement Hatari event processing from
main.c.

And then there's the question does Qt support joystick events
(on Linux, Windows & OSX etc)?


Screen:

There are two options, either converting SDL screen contents to Qt widget
(e.g. QtPixmap) on every VBL, or remapping SDL window inside Qt UI. Former
could cause fairly large performance overhead and latter is obviously
completely OS specific.

If I would implement B) in separate process there would still be the same
portability problems for process communication (sockets on Windows)
and window embedding as with the Python GUI.


So, for now I would be leaning towards A) and not having menubar etc.
It would be just an alternative for the SDL GUI (maybe later also
GUI for debugger).


	- Eero

PS. If somebody considers Python the problem in current Python UI,
I could consider re-implementing the Python UI in Vala, a converter from
higher level language to Gobject based C:
	http://en.wikipedia.org/wiki/Vala_(programming_language)