Gtk+ 4 action items

[infirit]

This issue will track all the things we will need to address when eventually moving to Gtk+4. It is still in development though so this list is incomplete. Also we will likely not need to worry about this for a few years so no rush 😄.

migration guide: https://gnome.pages.gitlab.gnome.org/gtk/gtk/gtk-migrating-3-to-4.html

• [ ] GtkImageMenu item has been removed. (see https://github.com/blueman-project/blueman/pull/749#issue-250163751)
• [ ] GtkStatusIcon has been removed (Use Appindicator see #637)

[andreldm]

With regards to GtkImageMenu, please see my comment at SO: https://stackoverflow.com/a/57422036/3109776

[cschramm]

Thanks for digging this up, @andreldm. An own implementation for a GtkImageMenuItem should be easy to get into our code as https://github.com/blueman-project/blueman/blob/3228b31a455a948ebfe8a53e82a3854f2f5a6aeb/blueman/Functions.py#L210 is the only location left where we use it and we do not use any of the GtkImageMenuItem's additional properties apart from passing an image in the constructor.

Regarding GtkStatusIcon - as this tracking issue is three years old already :sweat_smile: - things improved and we can just get rid of it by just dropping blueman/main/indicators/GtkStatusIcon.py and changing the default indicator implementation to AppIndicator. AppIndicator (GI bindings) gets a mandatory requirement (*) then, of course, and we're losing the left-click operation. I'm not quite sure what depending on AppIndicator means for desktop support. I guess in some systems the user will have to add a certain notification area / plugin (in addition to the standard one) to see it.

(*) The Debian package uses Ayatana Indicators instead with a simple patch that flips the name, as some people are putting some effort into replacing the old "Ubuntu Indicators" with it, see #1217.

-gi.require_version('AppIndicator3', '0.1')
-from gi.repository import AppIndicator3
+gi.require_version('AyatanaAppIndicator3', '0.1')
+from gi.repository import AyatanaAppIndicator3 as AppIndicator3

There seems to be a lot more on that migration page that we need to care about, though, both in "Preparation in GTK 3.x" and in "Changes that need to be done at the time of the switch", e.g. "Stop using GtkWidget event signals" or " Stop using GdkScreen".

[cschramm]

I just went through the preparations section and found the following:

Stop using direct access to GdkEvent structs Might conflict with accessing the event's type as a property in ManagerDeviceList.on_event_clicked, depending on how PyGobject translates that.

Stop using GtkBox padding, fill and expand child properties There's a padding in services-network.ui and fill and expand are basically used in all ui files. expand also appears in code.

Stop using gdk_pixbuf_get_from_window() and gdk_cairo_set_source_surface() There are two or three calls to the latter.

Stop using GtkButton’s image-related API Used in MessageArea and StandardItems for the "More" and "Plugins" buttons (I think the latter can just use icon-name instead).

Stop using GtkWidget event signals We do connect to multiple of those signals: button-press-event, delete-event, enter-notify-events, leave-notify-events, configure-event, drag-motion, drag_data_received (does that actually work with underscores? :thinking:)

Stop using gtk_main() and related APIs A little hard to track, but at least Gtk.main_quit seems to violate it.

Reduce the use of gtk_widget_destroy() Need to check all calls to destroy.

Reduce the use of generic container APIs There are at least some GtkBoxes that we call add() on.

[infirit]

Stop using GtkBox padding, fill and expand child properties There's a padding in services-network.ui and fill and expand are basically used in all ui files. expand also appears in code.

If I remember properly we already moved to the GtkWidget properties, so h/vexpand, margin* etc.

Stop using gdk_pixbuf_get_from_window() and gdk_cairo_set_source_surface() There are two or three calls to the latter.

This relates specifically to the GdkCairo api, we don't use it. We use cairo directly, https://cairographics.org/documentation/pycairo/2/reference/context.html#cairo.Context.set_source_surface

Stop using GtkWidget event signals We do connect to multiple of those signals: button-press-event, delete-event, enter-notify-events, leave-notify-events, configure-event, drag-motion, drag_data_received (does that actually work with underscores? 🤔)

I love it when they tell you don't do X, don't tell you what to do instead and when one points out their documentations sucks, get flamed 🙄 .

Stop using gtk_main() and related APIs A little hard to track, but at least Gtk.main_quit seems to violate it.

It is the applications I skipped when porting to GtkApplication, wizard and sendto basically. They can easily be ported when the time comes.

Reduce the use of gtk_widget_destroy() Need to check all calls to destroy.

Generally we should not be using this under python anyway so good to chase these down and review.

Reduce the use of generic container APIs There are at least some GtkBoxes that we call add() on.

We can replace these with append as that is how we actually use it.

[andreldm]

@cschramm no problem, I don't mean to lure you into preparing for gtk4 right now, I think no one out of Gnome is already porting apps. The only downside of using that deprecated widget is that users get a ugly left padding that could be avoided with the trick I demonstrated at SO, if you're interested I can send a pull request.

[cschramm]

Sure, a solid replacement would of course be welcome. 👍

[infirit]

The only downside of using that deprecated widget is that users get a ugly left padding that could be avoided with the trick I demonstrated at SO, if you're interested I can send a pull request.

That is on libappindicator, it used to work fine but somehow they broke it.

edit: What you see is a result of a parsed widget tree we presented to libappindicator. Then the indicator applet/status notifiers builds a new menu from the parsed result. How the parsed result is shown is mostly out of out control.