How should I replace a gtk_dialog_run() in GTK 4?

Platform
1

Dear GTK developers,
I am one of the gtk-fortran developer (https://github.com/vmagnin/gtk-fortran/wiki), which is a GTK / Fortran binding. We are now porting gtk-fortran to GTK 4. More than 50% of the examples are now running with GTK 3.98.4 on Fedora 32. But we may need some help to port some of the remaining ones.

For example, I am now working on a GtkDialog example hl_dialog.f90 based on our high level library:
https://github.com/vmagnin/gtk-fortran/blob/gtk3/src/gtk-hl-dialog.f90

In GTK 3, we had that kind of code to manage a dialog window:

       call gtk_widget_show_all (dialog)
       resp = gtk_dialog_run(dialog)
       call gtk_widget_destroy(dialog)

But in GTK 4, gtk_dialog_run() was removed. In GTK 4, what is the recommended way to run a GtkDialog and get its response ? Should I write a callback function for the “response” event ?

1 Like
2

Exactly: https://developer.gnome.org/gtk4/stable/ch32s02.html#id-1.7.4.4.70

1 Like
3

Thank you @baedert,
I missed that advice. I will try in the next days.

4

I have written a callback function for the “response” signal. It works.
But I was obliged to create a new GMainLoop to obtain a blocking behavior:

       dialog_gmainloop = g_main_loop_new(c_null_ptr, FALSE)
       call g_main_loop_run(dialog_gmainloop)

because in my library the dialog window is managed by a function hl_gtk_message_dialog_show() which must show the dialog window then return its response. Therefore I need that blocking behavior.
There is of course a call g_main_loop_quit(dialog_gmainloop) in the callback function.

But it seems to contradict https://developer.gnome.org/gtk4/stable/ch40s02.html#id-1.7.4.4.72
What is your opinion on my solution ?

5

Remove the function that blocks.

Blocking functions contradict the nature of event driven programming that has been the model of GTK since its inception; the introduction of gtk_dialog_run() was, in retrospect, a mistake in and of itself, as it used a model more in line with terminal user interfaces/console scripting than GUIs. The main reason for blocking is to prevent interacting with the rest of the application while the dialog is in effect; that is perfectly achievable with modality—that’s what modality is for, after all. If you’re blocking in the middle of a synchronous signal emission, you should strongly reconsider the approach you are using, and avoid the message dialog altogether.

You are, of course, free to create a nested main loop in your own library/code, but you also must be aware of the potential issues that nested loops bring—especially when paired with threaded code that neither you or the toolkit have no control over.

2 Likes
6

Thank you @ebassi for your clear answer.
I will think about it. In our high level library, our goal was to allow the user to open easily a dialog box and obtain a response by typing just one line of code, without having to care about writing callback functions… I have not yet figured out how I could do without adding a nested loop.

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.