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

Dear GTK developers,
I am one of the gtk-fortran developer (, 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:

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


1 Like

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

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
What is your opinion on my solution ?

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.


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.

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