5 ms·

Wait, GtkDialog is considered a GNOME thing and is now depricated? They article claims "These aforementioned widgets only benefited GNOME apps, as they were st

Wait, GtkDialog is considered a GNOME thing and is now depricated? They article claims "These aforementioned widgets only benefited GNOME apps, as they were strictly designed to provide widgets that conformed to the GNOME HIG.", but GtkDialog is the primary way to provide a modal dialog in GTK. That seems like a fairly general problem.

the_biot 2y ago
It's entirely logical for the Gnome folks to do this. They've been removing features and widgets from all kinds of programs for literally decades; Gnome is fundamentally a destructive project. Outright sabotaging GTK (which predates and inspired Gnome) is just the logical way forward on this multi-decade orgy of destruction.
- crashdancer 2y ago
  It's odd you say those things because I've been enjoying GNOME for years and I find they make great additions all the time. For me GTK4 has been a massive improvement over GTK3. There aren't actually any GNOME developers who enjoy removing things just to annoy users -- human beings have limited time and sometimes tough decisions have to be made about what's going to make it in and what isn't.
  - rleigh 2y ago
    Yeah. It really does take more effort to leave perfectly working functionality in place than to do the work to remove it. Come on. Many of the decisions made by the GTK+ developers are utterly unjustifiable. Take the removal of GtkHBox and GtkVBox in place of GtkBox. A couple of shims for backward compatibility would have taken just a few lines of code and would have avoided a hard compatibility break. Did that happen? No. So a huge burden to update every GTK+ application (incompatibly!) was imposed upon every developer on the planet. Was that a productive use of resources? No. It was an utterly illogical change which had zero real-world benefit to anyone. And that's just one of many, many bad decisions. There are very valid complaints to be made about GTK+, and you can't handwave them all away with some PR comments.
    - crashdancer 2y ago
      Sorry but that's a really poor example and IMO not a valid complaint. I don't think they made the wrong decision there. There are quite a lot of other API changes in GTK4 so some tiny shims for only a couple APIs wouldn't help in porting at all. It would only create confusion because there would be two APIs for the same thing but now it's even more unclear when the old API is going to be removed. The argument you're essentially making here is "keep deprecated APIs around forever" which isn't realistic. They're deprecated for a reason, if you never remove them then deprecation isn't meaningful anymore. Also you're incorrect that it would be "just a few lines of code." Those things are GObject classes which can be referred to in various ways through the runtime system or by language bindings, it's not just a matter of creating some aliases for C symbols. If you only use those in such limited ways that a tiny shim would do the job, then it would be just as easy and more beneficial to create a small script that does search and replace on your entire project. It would be entirely possible to create a larger shim to ease porting, and keep it outside the main project so it doesn't cause confusion. But for it to be truly useful, someone would have to put a lot of thought and effort into making it work for a good portion of the APIs that changed. Then it would have to be tested thoroughly with all the language bindings. It's a way bigger project than just shipping a couple of #defines in a header. And if it did exist, it too would get deprecated and obsolete at some point when all the apps finish their ports to the new version. None of this is a new idea -- all this I'm taking about is exactly what Qt already did with Qt5Compat. It could be done in GTK as well but some interested party needs to make it happen. So far, no one has cared enough to put their money where their mouth is and actually do it. BTW even the Linux kernel does a thing now where they don't use deprecation attributes in the code at all anymore. If a kernel developer intends to remove an API then they just delete it and fix the build. Because in practice it's actually much worse to keep an API around for long past its expiration date and annoy everyone with deprecation warnings.
      - the_biot 2y ago
        The Linux kernel changes internal APIs, and whoever changes it gets to fix the kernel code that relies on it. The end user of the kernel -- user space -- never sees any of this, and the userspace API never breaks. You're implying this is equivalent to GTK and Gnome intentionally breaking API with every major release for every applicaton that uses those libs. It is not. Frankly it's a bad faith argument.
bonzini 2y ago
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.
tristan957 2y ago
GtkDialog is just a GtkWindow with a slightly different API.

the_biot 2y ago

It's entirely logical for the Gnome folks to do this. They've been removing features and widgets from all kinds of programs for literally decades; Gnome is fundamentally a destructive project. Outright sabotaging GTK (which predates and inspired Gnome) is just the logical way forward on this multi-decade orgy of destruction.

crashdancer 2y ago
It's odd you say those things because I've been enjoying GNOME for years and I find they make great additions all the time. For me GTK4 has been a massive improvement over GTK3. There aren't actually any GNOME developers who enjoy removing things just to annoy users -- human beings have limited time and sometimes tough decisions have to be made about what's going to make it in and what isn't.
- rleigh 2y ago
  Yeah. It really does take more effort to leave perfectly working functionality in place than to do the work to remove it. Come on. Many of the decisions made by the GTK+ developers are utterly unjustifiable. Take the removal of GtkHBox and GtkVBox in place of GtkBox. A couple of shims for backward compatibility would have taken just a few lines of code and would have avoided a hard compatibility break. Did that happen? No. So a huge burden to update every GTK+ application (incompatibly!) was imposed upon every developer on the planet. Was that a productive use of resources? No. It was an utterly illogical change which had zero real-world benefit to anyone. And that's just one of many, many bad decisions. There are very valid complaints to be made about GTK+, and you can't handwave them all away with some PR comments.
  - crashdancer 2y ago
    Sorry but that's a really poor example and IMO not a valid complaint. I don't think they made the wrong decision there. There are quite a lot of other API changes in GTK4 so some tiny shims for only a couple APIs wouldn't help in porting at all. It would only create confusion because there would be two APIs for the same thing but now it's even more unclear when the old API is going to be removed. The argument you're essentially making here is "keep deprecated APIs around forever" which isn't realistic. They're deprecated for a reason, if you never remove them then deprecation isn't meaningful anymore. Also you're incorrect that it would be "just a few lines of code." Those things are GObject classes which can be referred to in various ways through the runtime system or by language bindings, it's not just a matter of creating some aliases for C symbols. If you only use those in such limited ways that a tiny shim would do the job, then it would be just as easy and more beneficial to create a small script that does search and replace on your entire project. It would be entirely possible to create a larger shim to ease porting, and keep it outside the main project so it doesn't cause confusion. But for it to be truly useful, someone would have to put a lot of thought and effort into making it work for a good portion of the APIs that changed. Then it would have to be tested thoroughly with all the language bindings. It's a way bigger project than just shipping a couple of #defines in a header. And if it did exist, it too would get deprecated and obsolete at some point when all the apps finish their ports to the new version. None of this is a new idea -- all this I'm taking about is exactly what Qt already did with Qt5Compat. It could be done in GTK as well but some interested party needs to make it happen. So far, no one has cared enough to put their money where their mouth is and actually do it. BTW even the Linux kernel does a thing now where they don't use deprecation attributes in the code at all anymore. If a kernel developer intends to remove an API then they just delete it and fix the build. Because in practice it's actually much worse to keep an API around for long past its expiration date and annoy everyone with deprecation warnings.
    - the_biot 2y ago
      The Linux kernel changes internal APIs, and whoever changes it gets to fix the kernel code that relies on it. The end user of the kernel -- user space -- never sees any of this, and the userspace API never breaks. You're implying this is equivalent to GTK and Gnome intentionally breaking API with every major release for every applicaton that uses those libs. It is not. Frankly it's a bad faith argument.

bonzini 2y ago

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.

tristan957 2y ago

GtkDialog is just a GtkWindow with a slightly different API.