[hatari-devel] Hatari UI with Qt

[Eero Tamminen]

Hi,

On torstai 02 kesäkuu 2011, Nicolas Pomarède wrote:
> Le 02/06/2011 20:27, Eero Tamminen a écrit :
> > Hm.  Switching Hatari itself from SDL-only to Qt+SDL would be quite
> > large change.  Before considering that, I'd like to see for a bit
> > longer how well Nokia manages Qt...
> 
> By doing a quick search for QT + SDL, it appears it's quite easy to
> embed an SDL program in a QT ones (need to pass to SDL the window's id
> provided by QT)

After looking at some of the search results, that's exactly the same way
as what I use in the PyGtk Hatari UI.

However, you will then have same issues that the PyGtk UI has:
1. embedding SDL window using SDL's own facilities disables all of SDL's
   own input processing
2. embedding of SDL window is completely OS specific, it's not something
   you write once and it works everywhere
3. SDL has separate windows for fullscreen & windowed mode

1) is why I had to add my own code to Hatari for embedding its window.

2) is the reason why the current Hatari & Python UI have embedding support
only for X11 as I only know how to do it on X11.

I've understood from SDL's code that it's possible also on Windows, but as
I cannot test it myself (and it requires also Windows specific socket code
in case of remote API, somebody else needs to look into that).


> Regarding what nokia will do with QT, even if development stopped
> definitly today, QT 4.7 is powerful enough to fill all our needs.

Doing Hatari's own UI with Qt will also mean switching from C to C++
compiler.  As WinUAE & Aranym are both C++ code, that will make some
things easier.

However, while I like Qt as widget set, I don't like C++ (debugging or
otherwise), it reminds me too much of Perl (missing orthogonality in
the language design etc).  If C's facilities for writing OO-code aren't
enough, I'd rather use some higher level language like Python than C++. :-/


> > Ok, then it really needs a real, modern widget toolkit.
> > 
> > In that case I think it's better to do the UI separately from Hatari
> > and utilize the remote API.  Only if the remote UI turns out
> > infeasible, I would go for integrating everything to Hatari binary
> > itself.
> 
> I wonder if this could be an opportunity to "clean" Hatari and do a
> proper abstraction between the hardware emulation (which in the end
> mostly provides one video frame and one sound frame per vbl) and the
> emulator (which is reponsible for displaying video result and sending
> sound data to the audio system used by the OS).

Using a real widget toolkit for the UI provides:
- good file selector that supports remote file systems, user shortcuts etc
- support for internationalization and UTF-8 (filenames etc)
- UI that scales automatically with content (needed for localization)
etc.

Doing Hatari options dialogs with something like that and their size
not being constrained by Hatari's own window size is really nice.


> The remote API implies to develop a lot of protocol to exchange data
> between the emulation and the emulator's UI ; I'm not really a big fan
> of this client-server mode when both parts are running on the same
> computer.

Except for debugger, it's really quite small amount of data & one-way.

For the debugger data, there's no need for extra protocol, you can
either save the information to a file with existing debugger facilities
or give debugger a filename that's actually a fifo.  For things like CPU
instruction traces, you would anyway want to use a temporary file
as you need to give it to some external viewer that can efficiently
handle (potentially) really huge files.

For the debugger data I think only thing needed is formalizing the current
output a bit more (e.g. use tabs to separate columns), so that UI can find
the data from it when it wants to put it into table columns instead of just 
showing it as-is with monospace font.  Output might need also a terminator
so that UI knows when to stop reading the fifo, but these are more of
debugger code cleanup that new protocol...

(I really don't want to support two different data output formats e.g. for
disassembly, one for internal CLI debugger and one for internal GUI
debugger.)


Regarding the current (Python) Hatari UI, handling the configuration
in Python without being able to re-use Hatari's configuration structures
& code was much more pain that the small amount of socket data.  That
shouldn't be a problem for native code as it can include code from Hatari.


> I think that what has beed made with SDL can be abstracted in a
> "modularized" way to allow other toolkits to access the emulation's data
> (registers, IO, ram, cpu, dsp, configuration, ...).
> 
> This would require some work to refactor some code in Hatari, but then
> it would benefit us for the emulation-emulator's UI integration in the
> same program, which would save some time on working on a remote API.
> 
> At least, openmsx and vice went this way, and they succeeded in doing
> it. I think it's the best choice performance-wise.


	- Eero