| Re: [hatari-devel] Debugger GUI enquiry |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 5/7/20 2:31 PM, Thorsten Otto wrote:
On Donnerstag, 7. Mai 2020 11:33:48 CEST Steven Tattersall wrote:
Obviously exposing remote debug is very powerful if the interface is right,
and it means I could develop the tooling without tinkering with the core
Hatari codebase too much. On the other side, that might be over-engineering
it, when something simpler might do the job.
I once tried to implement something similar to hatari's python ui in aranym,
and some of my experiences are:
- although of course more complicated, there is not much choice about
implementing that through some kind of remote interface. Implementing it
directly in the executable would mean you have to link Hatari with all the GUI
libraries needed for it (GTK, KDE, QT, whatever). That is way to troublesome,
and adds lots of dependencies that are not needed for normal operation.
Although dependencies wouldn't be a problem, it
would require rewriting all Hatari GUI code and
the main loop for that toolkit, which would be
a multi-year project.
- the hatariui embeds the SDL main window of hatari into a frame of the GUI.
That looks really nice, but does not work on very well on windows.
Current Hatari window embedding is X11 specific
(it doesn't work even on Wayland, except with
Xwayland X11 server).
SDL does support window embedding [1] and its
sources seemed to have some support for that also
on Windows, so I think Windows could also support
window embedding if somebody contributes code for
it.
No idea whether on Mac windows can be embedded
between processes.
[1] NOTE: SDL's own window embedding support is
completely useless for Hatari because SDL disables
all keyboard input when it's used.
- also mostly windows related: when using some scripting language like python
(or perl as in my case), you run into trouble getting a working environment. I
was using ActivePerl for that, but that does not provide all the needed
interface libraries for GUIs (like GTK in my case).
- another problem (not only for windows) is that you have to make sure that
the interface library that was compiled for python/perl used the same version
of the GUI libs that are actually in use at runtime. And with "same" i mean
not only the same major version, but really the exact same version.
Basically you would need to bundle everything for the user, like e.g.
the PyGTK based Gramps
genealogy project does:
https://www.gramps-project.org/wiki/index.php/All_In_One_Gramps_Software_Bundle_for_Windows
Easiest would be just to tell users to install
Windows Linux subsystem (WSL), pulseaudio,
X server and Ubuntu from Windows store:
https://wiki.ubuntu.com/WSL
Then install & run Hatari from the Ubuntu inside
Windows.
- then there is the question which of the processes should be the server
(creating the socket, and listen on it), and which one the client.
Theoretically, it would be best to let hatari be the server, so that you can
connect to it not only from the ui, but for example also using some
commandline tool, thus being able to send commands to an already running
hatari instance. However, that makes starting up a bit difficult, since you
first have to run hatari, wait until it has created the socket, and then
connect to it. OTOH, hatari may also have to wait for some initial commands
from the ui before actually launching the OS. IIRC, the current solution does
it the other way around, and the python script is the "server".
Hatari supports both models:
* --cmd-fifo is created by Hatari itself,
* --control-socket is something to which
it connects to
FIFO is supposed to be used by command scripts[1],
socket by remote UIs & CLIs.
- Eero
[1] Hatari opens FIFO in non-blocking mode, but
if something has already opened the other end of
FIFO, it will automatically block until Hatari
opens its own end.