|Re: [hatari-devel] Debugger GUI enquiry|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 5/14/20 11:32 AM, Steven Tattersall wrote:
OK, I deliberately didn't add the remote-debug command implementations that
set those values in this patch, so that nothing can trigger it by accident
I'll do a patch tonight with something to set them (basically strcmp s for
I don't have any builds that use the FIFO, so am not sure what that
involves. Conceptually I don't think it would differ from the socket
approach. In general, if something can service external commands then call
DebugUI_ProcessRemoteDebug with strings, it should work.
FIFOs work differently from sockets. They block
until there's something in the other end, so it's
very easy to deadlock process with them if you
e.g. use multiple of them, without setting them to
By "wait until remote debugger socket/FIFO has something", do you mean
write a function different from Control_CheckUpdates() to read and process
the incoming commands? Or do you just want me to set bRemotePaused before
calling the function?
I meant that this busylooping isn't acceptable:
+ while (bRemoteBreakIsActive)
+ (void) remoteDebugcmdCallback();
+ /* allow wakeup on a thread here? Run any other SDL update
Before seeing fully functional patch, I can't
exactly say how it should be done instead. :-)
The UI is still the original Python/GTK at the moment. The more I use it,
the more uncomfortable I feel with it, but since this is prototyping I'll
see where it takes me.
GUI was originally written against PyGtk v2.
There may be easier ways to do things with
the Gtk v3 widgets & Gobject introspection
(the porting was done with minimal changes,
it didn't redesign anything). At least it
has more flexible ways of doing layouts.
(Qt had nicer widget layout handling, but latest
Gtk is getting there too. Qt had also better
model/view split for lists, but I think latest
Gtk versions were fixing that too. Otherwise
both widget sets were fairly even.)
Or are you talking about text handling?