XApp progress bar support for Qt applications

[damonlynch]

Hi, I read with interest the discussion on application launcher progress bars here: https://blog.linuxmint.com/?p=3329

My application, Rapid Photo Downloader, currently implements application launcher progress bars (and badge counts) using libunity. It now works out of the box in any distro with KDE (e.g. openSUSE 15.2), Ubuntu (Gnome), Pop!_OS (Gnome with dash to panel), Fedora (Gnome with dash to panel), etc. For example, on openSUSE and Pop!_OS respectively:

Where it does not work is with Linux Mint. I looked into your API as described in the blog post, and it only works with GTK windows, not Qt windows.

I see a couple of possibilities for Xapp progress bars:

• integrate with libunity so calls to libunity automatically get sent to Xapp too, or
• extend XApp to include Qt windows

Will you consider one of these options?

Thank you.

[collinss]

That would actually be outside the scope of the xapp library. XAppGtkWindow is basically just a subclass of a GtkWindow with some convenience methods for setting window hints which will be read by the window manager. Cinnamon then looks for those window hints and if it finds one of them, it displays a progress in the window list applet. I suppose it's possible that libunity support could be added to the cinnamon applet, but I'm not sure it's even worth it since libunity is basically a dead project afaict.

That being said, if you would like to display a status bar in the Cinnamon window list, you can just set the window hints manually using XChangeProperty(), (or remove them with XDeleteProperty()). Here's a description of what that function does: https://tronche.com/gui/x/xlib/window-information/XChangeProperty.html. I would assume that function should work in qt as well (as long as you're in x11 and not Wayland) The property names are "_NET_WM_XAPP_PROGRESS", and "_NET_WM_XAPP_PROGRESS_PULSE". You will probably also need to include X11/Xlib.h.

You can also check https://github.com/linuxmint/xapps/blob/master/libxapp/xapp-gtk-window.c for more information on how it was done in XAppGtkWindow.

[damonlynch]

Thank you for your reply. I understand Linux Mint has a tight focus and that many things would be outside its scope.

But I do want to clear up a misconception. Libunity is not dead. OpenSUSE recently added libunity support. From a developer's perspective, libunity is very easy to use, and cross-platform, working both KDE and Gnome. Since XApps were introduced, libunity has seen an increase in use. Can the same be said of the XApp approach to application launcher progress bars?

My program is written in Python, and uses the Qt toolkit, but is not tied to any desktop. I have no idea how to call XChangeProperty() from Python because as a developer I never had to think about it. It's much easier to call a library that has gobject introspection support.

From my perspective, given Mint's tight focus, and like all of us, limited resources, working with the Linux community to focus on one solution used by all developers is the way to go. As for 2020, that solution is libunity. And yes, it would be better if libunity were packaged in Debian. It's weird that it's in Fedora and openSUSE, but not Debian.

[collinss]

OpenSUSE recently added libunity support.

Oh, did they fork it? I did a quick search and it looked like the last change was almost 2 years ago. That coupled with Ubuntu ditching Unity in favor of Gnome Shell, suggested that it was dead, but if someone else has taken up the mantle, we could probably add support. I was just worried that we'd be wasting effort on supporting a dead api.

Since XApps were introduced, libunity has seen an increase in use. Can the same be said of the XApp approach to application launcher progress bars?

Whenever we introduce a new standard like this, the point is never to push for universal adoption. Rather, we simply aim to make it work well for Mint itself. Our point is really to make Mint feel like more than just a collection of packages, and a big part of that is making all of our stuff feel more integrated. If someone else does find these things useful, that's great, and we'll do our best to support that, but we don't do what we do because we're trying to change what everyone else does - just to do what we do better.

My program is written in Python

Ah, yes, that would complicate things a bit.

As for how we do this, I can see basically 2 options:

1. Implement a toolkit-agnostic way of setting those window properties in libxapp.
2. Add support to the Cinnamon Window list applets for libunity's way of doing it.

If as you say, libunity is still under development, and is growing in popularity, then the second option would probably be the better option as it wouldn't require additional work for application developers, but I'm not familiar with how libunity handles the progress bars, so I can't say what kind of technical limitations (if any) would complicate or prohibit such an implementation.

@clefebvre @mtwebster @JosephMcc ^^ thoughts?

[damonlynch]

Although libunity first emerged with the desktop Unity, it is now independent of it. I can see how the name might confuse developers. It is confusing. Perhaps that just goes to show the importance of getting the name correct right from the birth of a project.

I'm not aware what changes to libunity openSUSE may have had to make to get it working in their distro. Perhaps none? I'm unsure.