Create Task
Maniphest T13138

Consider adopting unmaintained libdbusmenu-qt
Open, LowPublic
Actions

Description

libdbusmenu-qt, one of our dependencies for the global menu feature, is effectively unmaintained. As one can see from its formal upstream at https://code.launchpad.net/libdbusmenu-qt, there's been no commits since 2016 and no commits of substance since 2014.

Moreover it is the only dependency in the kdesrc-build sample configuration that requires the Bazaar VCS to build. This isn't a problem for kdesrc-build itself, however Bazaar is also effectively unmaintained and some distributions (e.g. Gentoo) have started to remove it.

I mention this on the Plasma workboard because one of the Gentoo devs (asturm on our IRC) has looked into what's needed to move libdbusmenu-qt to Git (see https://github.com/a17r/libdbusmenuqt, which works but no longer passes tests). He noticed that plasma-workspace has already developed an internal fork for libdbusmenu-qt to apply fixes.

I think my question is simply, if we've already forked it (internally), shouldn't we take over release handling for it as well and put it on some kind of more stable footing? We still rely on it working well, we're its primary user, and its lead developer Aurélien Gâteau is also a Plasma dev so I think he'd be OK with it going back to KDE.

This isn't a Plasma 'bug' so I didn't put it on Bugzilla but I didn't want it to get lost in IRC either. If there's a better place to ask (or if this has already been discussed in the team) just let me know.

Related Objects

mpyne created this task.May 10 2020, 8:06 PM
mpyne triaged this task as Low priority.
heikobecker added a subscriber: heikobecker.May 10 2020, 8:09 PM

Maybe worth adding that knotifications also depends on it.

fvogt added a subscriber: fvogt.Jun 22 2020, 1:40 PM
davidedmundson added a subscriber: davidedmundson.EditedJun 22 2020, 11:47 PM

. He noticed that plasma-workspace has already developed an internal fork for libdbusmenu-qt to apply fixes.

That's only partly true and a bit misleading.

Effectively there are two sides to that upstream repo. An import side and an export side:

  • Plasma-workspace contains a fork of only the import side.
  • KNotification requires only the export part.

So it's not a fork of anything relevant.

Qt also effectively has an export implementation.
I believe for KF6 we want to drop KStatusNotifier from KDE and rely on a perfect QSystemTrayIcon which would in turn use Qt's version of the export library.
Plasma-integration would also use Qt's implementation..somehow :)

IMHO at that point it's not worth putting any time into moving what we have in plasma-workspace.
Hosting dbusmenu-qt as-is and not changing it would still be viable, or even copy pasting the relevant files into KNotification and dropping the dependency.

kmaterka added a subscriber: gateau.Jun 23 2020, 7:38 AM

CC @gateau

In Ubuntu/Debian, libdbusmenu-qt5-2 package is used not only by Plasma, but also by LXQt and Quassel.

gateau added a comment.Jun 23 2020, 8:45 AM

I created dbusmenu-qt as part of my work for Canonical, so I do not consider it to be a product I "own". This is one of the subtle consequences of contributing code because you are paid to do so, and not because this is something you are genuinely interested in working on.

I do not have any contact with any potential maintainer of dbusmenu-qt on Canonical side, but looking at the commit history it is clear that it is effectively unmaintained. As such, if the library is still relevant and having it hosted on Launchpad is a pain, it makes sense to fork it within KDE infrastructure and simplify building Plasma for everyone. I trust @davidedmundson to have much more up-to-date information on this topic to decide it if makes more sense to fork it or if the problem will "solve itself" with KF6.

mpyne added a comment.Jul 5 2020, 10:16 PM

I wanted to thank you all for your feedback. It sounds to me that, based on that feedback:

  • Long term, the right answer is for Qt 6 to natively take on the functions we'd needed separately from libdbusmenu-qt and its users in KF5 and Plasma 5. So in the future the dependency here will go away entirely.
  • Short term, it's possible to remove the dependency on the upstream libdbusmenu-qt by duplicating for KNotifications what we've already done for plasma-workspace, or to adopt libdbusmenu-qt as-is, or both.
    • Even if Plasma can shed the external dependency by updating KNotifications, it might still be helpful to adopt it to avoid fragmentation due to non-Plasma users like Quassel and LXQt.
    • On the other hand, even if hosted here it would still be maintained only enough to make it to Qt6. If getting rid of bzr is the only problem, there's no reason we couldn't just have users install it as an existing distribution package to meet the dependency, and that might avoid confusing the issue for non-Plasma users.

I'll leave it to @davidedmundson and the rest of the Plasma team what makes the most sense. If we don't manage to land it here then I'll see if I can make it an external dependency for kdesrc-build without breaking things.

yenchihsuan added a subscriber: yenchihsuan.EditedJan 3 2022, 11:17 AM

FWIW, Telegram devs have a patch to make dbusmenu-qt code to build with Qt 6 [1], and Arch Linux added CMake patch [2]. From the perspective of an LXQt dev (me), it will be great if those efforts are consolidated.

This may be related, too: T15127: Change the build system to enable building with Qt5 or Qt6

[1] https://github.com/desktop-app/libdbusmenu-qt/pull/1
[2] https://github.com/archlinux/svntogit-packages/commit/ee7106fc688937bfbe51eccb0eadca5eefd71637