4 ms·

There is gtk_window_set_transient_for() and gtk_window_set_modal(), and GtkDialog is basically a synchronous wrapper for those two + a nested event loop. But ne

There is gtk_window_set_transient_for() and gtk_window_set_modal(), and GtkDialog is basically a synchronous wrapper for those two + a nested event loop. But nested event loops are very easy to get wrong, so my guess is that, these days, you want to write the code for modal dialogs as if they were not modal, even if to the user they prevent interaction with other parts of the program. EDIT: yep, the nested event loop part is not found in AdwDialog either (https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Dialog.html https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/cla...) so that's probably why GtkDialog is considered deprecated. There is also GtkAlertDialog which is a replacement for GtkMessageDialog but has a better design (for example it does not inherit from GtkWindow, which was a very 90s OOP thing to do) and it uses a callback instead of a synchronous, nested event loop.

AlienRobot 2y ago
>these days, you want to write the code for modal dialogs as if they were not modal, even if to the user they prevent interaction with other parts of the program I'm never going to use a toolkit that can't guarantee a modal is modal.
- bonzini 2y ago
  It is modal. https://docs.gtk.org/gtk4/method.Window.set_modal.html https://docs.gtk.org/gtk4/method.Window.set_modal.html The user can't interact with the parent until you close it. The problem with nested event loops is that there can always be timers or idle callbacks that fire while the nested event loop is running. Back in the day where windows were rendered on demand, you could also get expose events just because the user moved another window around. So at the code level, "modal" windows are fiction and have always been. Getting rid of nested event loops is cleaner because it forces you to get to grips with the fact that (for the programmer, not the user) everything is asynchronous in an event-driven architecture. Plus these days programming languages have better tools to deal with the asynchronicity.
jandrese 2y ago
GtkDialog also includes code for integrated buttons like OK, Cancel, and/or whatever you want.
- bonzini 2y ago
  So basically GtkDialog's utility boils down to gtk_dialog_new_with_buttons(). That's like five line of code saved per dialog box, or zero if you use Glade to build the UI. The big deal for GtkDialog used to be gtk_dialog_run(), which is a bad idea.

AlienRobot 2y ago

>these days, you want to write the code for modal dialogs as if they were not modal, even if to the user they prevent interaction with other parts of the program I'm never going to use a toolkit that can't guarantee a modal is modal.

bonzini 2y ago
It is modal. https://docs.gtk.org/gtk4/method.Window.set_modal.html https://docs.gtk.org/gtk4/method.Window.set_modal.html The user can't interact with the parent until you close it. The problem with nested event loops is that there can always be timers or idle callbacks that fire while the nested event loop is running. Back in the day where windows were rendered on demand, you could also get expose events just because the user moved another window around. So at the code level, "modal" windows are fiction and have always been. Getting rid of nested event loops is cleaner because it forces you to get to grips with the fact that (for the programmer, not the user) everything is asynchronous in an event-driven architecture. Plus these days programming languages have better tools to deal with the asynchronicity.

jandrese 2y ago

GtkDialog also includes code for integrated buttons like OK, Cancel, and/or whatever you want.

bonzini 2y ago
So basically GtkDialog's utility boils down to gtk_dialog_new_with_buttons(). That's like five line of code saved per dialog box, or zero if you use Glade to build the UI. The big deal for GtkDialog used to be gtk_dialog_run(), which is a bad idea.