| |
Slajerek
Registered: May 2015
Posts: 63 |
Release id #187948 : C64 65XE Debugger V0.64.58
I am using NFD library to open files in Linux. Please guide me how to fix this annoying bug.
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/MTEn.. |
|
... 20 posts hidden. Click here to view all posts....
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I checked out the latest version from trunk, moved ~/.C64Debugger/settings.dat to settings.dat.bak (to avoid using the X11 dialogs), and now Ctrl+8 actually pops up a usable Gtk3 dialog.
Edit:
uname: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
/etc/debian_version: 10.4
gtk3: 3.24.5
glib: 2.58.3
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
While am at it, Gtk4 will deprecated/remove `result = gtk_dialog_run()` because that breaks the nature of a UI, a UI is event driven and thus async. I agree with the Gtk devs at this point.
So in the 'future', NFD (or perhaps your own custom code) will have to set up a temp GMainLoop, create a GtkDialog with an event handler for "response" and in that event handler call back to your code to signal a filename/path was accepted, or not.
The problem with this is that gtk_dialog_run() blocks, but:
GtkWidget *dialog = gtk_dialog_new(...);
gtk_widget_show(dialog);
will not.
So you need to make the dialog 'Modal'. Since you don't have a proper GtkWindow/Widget to use as a parent to set Modal for, you'd have to use some OS-dependent code to somehow grab an X11, Win32 or whatever window handle via GDK
and use that as the parent.
Another thing is unrolling the GMainLoop events and then destroying the temp GMainLoop, via the GtkDialog's "response" event handler. I have a feeling it'll not go well.
By Wodan, I love Gtk (or any other UI toolkit with its own threads and objects, looking at you Qt!) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
Works here too!
One weird thing... UPX crashes when packing the exe... which is weird and unexpected. However, i'd suggest making this a seperate build step, and copy the binary to be packed first - in that case UPX crashing wont really matter and still leave you with a working binary. (actually... just dont use upx, 11mb is nothing, depacking will be slower than just loading the binary) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I did this without upx. UPX is weird and just adds a lot of time to the build process. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
I just kept UPX because it looks nice to see a small self-contained and portable binary, but more and more people are complaining so I guess I'll have to give it a go.
Regarding that experimental dev version, note it uses Zenity, not direct GTK. Thus, the dialog is spawned through a forked process that communicates over stdout, meaning that the original process does not have to have the GMainLoop. I hope that solves that open/file dialogs problem once for all :) Thanks for testing. |
| Previous - 1 | 2 | 3 - Next |
