Replace deprecated GtkAction / GtkActionGroup with XfceGtkActionEntry

Like done for thunar. Check xfce-gtk-extensions.h in libxfce4ui for details.

To be ckecked if the current accelerator management should be used, or if it makes sense to first switch to GAction, because the currently used GtkAccelMap will not be available any more in gtk4.

Hope I will have time to work on it sooner or later !

I've been dreading this, it's going to be such a pain and super invasive. Another victim of the mass GTK+ deprecations in 2013.

Related: xfce/thunar!10 (merged)

What are the deadlines for processing all these deprecation warnings? (related to GtkAction in particular, but not only)
Should this be considered a priority?

Also, is the migration to GTK4 to be considered now, or not at all?
Should the warnings be processed with a view to upgrading to GTK 4 (thus preferring such and such a solution over another, or without spending too much energy on something rather temporary), or with a view to stay long enough with GTK 3.24?

What are the deadlines for processing all these deprecation warnings?

I guess once they're removed from the GTK+ version we need to use.

Should this be considered a priority?

Personally I gave up caring about GTK+ deprecation warnings after they deprecated so many things and started warning all of the place. I usually build with those warnings disabled so I can see important warnings.

But it will have to be done eventually...

Also, is the migration to GTK4 to be considered now, or not at all?
Should the warnings be processed with a view to upgrading to GTK 4 (thus preferring such and such a solution over another, or without spending too much energy on something rather temporary)...

IMO, it doesn't make much sense to do it twice, so any work should try to be made future-proof for Gtk4. I haven't looked closely at the referenced changes to Thunar, but the idea of having a shim/abstraction in a common Xfce library seems like a good idea to aid in porting.

I usually build with those warnings disabled so I can see important warnings.

Sounds like a good idea. You have a script for it ? .. Possibly worth to put it to the "by component" section in https://wiki.xfce.org

IMO, it doesn't make much sense to do it twice, so any work should try to be made future-proof for Gtk4.

Makes sense .. so probably better to first check how to get rid of "GtkAccelMap" before starting work on this issue.

Mouspad currently uses the deprecated GtkUIManager. For thunar I completely dumped it, since loading the icon-order from xml file only brought disadvantages there. To be checked if it makes sense to replace GtkUIManager with GtkBuilder for mousepad, or if GtkUIManager as well should be dropped, like for thunar.

Sounds like a good idea. You have a script for it ?

I just configure the build system like this:

$ CFLAGS="-Wall -Wextra -Wno-deprecated-declarations" \
    CPPFLAGS="-DGLIB_DISABLE_DEPRECATION_WARNINGS" \
    ./configure [options here]

Thanks ! Hope you are ok with having it in the Wiki? I added that info here: https://wiki.xfce.org/mousepad/dev

mentioned in merge request !21 (merged)

@alexxcons, have you already started working on this?
Because with !21 (merged), !23 (merged) and an upcoming MR for GtkStock, I've finished dealing with most of the deprecation warnings unrelated to GtkAction and GtkUIManager, so if the way is clear, I think I'll give it a try now.

I did not start working, so from my POV you are free to go for it.

(Though like said above, expect changes for the accelerator part in the direction of GAction sooner or later)

mentioned in merge request !24 (merged)

mentioned in merge request !25 (merged)

I finally took a good first step to solve this issue: see !25 (merged).
Comments and criticism are welcome.
Thanks!

closed via merge request !25 (merged)

changed milestone to %0.4.90