[FFe] Bring Unity appmenu / HUD integration to Qt5

Bug #1126205 reported by Timo Jyrinki on 2013-02-15
70
This bug affects 14 people
Affects Status Importance Assigned to Milestone
appmenu-qt
Fix Committed
Undecided
Łukasz Zemczak
libdbusmenu-qt
Fix Committed
Undecided
Łukasz Zemczak
appmenu-qt (Ubuntu)
Undecided
Łukasz Zemczak
indicator-appmenu (Ubuntu)
Undecided
Łukasz Zemczak
libdbusmenu-qt (Ubuntu)
Undecided
Łukasz Zemczak
qtbase-opensource-src (Ubuntu)
Wishlist
Łukasz Zemczak

Bug Description

We're currently lacking patches in Qt5 that would enable appmenu / HUD support in Qt5.

== CHANGE ==

https://code.launchpad.net/~sil2100/ubuntu/raring/qtbase-opensource-src/enable-appmenu <- the added patch debian/patches/enable_appmenu_support.diff

The patch re-adds appmenu support as it was in Qt4 - it's based on the approved Qt4 upstream changes we had landed. It's a direct port of the same changes.

== TESTS ==

The packages (and Qt5 with the patch) builds and works, as tested on the ppa:sil2100/qt PPA by some users.

== WHY? ==

Since the release of the Ubuntu SDK, our distro started directly depending on Qt5. In the current form, Qt5 has no global menu support - all Qt5 compiled applications have menus in windows. HUD support for those applications is also non-existent. We think this is unacceptable, especially that we're advertising development using our Ubuntu SDK (Qt5).

Note that this also blocks fix for bug 1126210 (see https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1126210/comments/9).

As mentioned in the comments, this is a distro-only fix for now, as upstream support does require more time to be done (see bug LP: #1157213). This distro patch would be essentially removed and replaced by the QPA support upstream.

Related branches

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qtbase-opensource-src (Ubuntu):
status: New → Confirmed
Changed in appmenu-qt (Ubuntu):
status: New → Confirmed
Changed in appmenu-qt (Ubuntu):
assignee: nobody → Łukasz Zemczak (sil2100)
Changed in libdbusmenu-qt (Ubuntu):
status: New → Confirmed
Changed in libdbusmenu-qt (Ubuntu):
assignee: nobody → Łukasz Zemczak (sil2100)
Changed in appmenu-qt (Ubuntu):
status: Confirmed → In Progress
Changed in libdbusmenu-qt (Ubuntu):
status: Confirmed → In Progress
Changed in qtbase-opensource-src (Ubuntu):
assignee: nobody → Łukasz Zemczak (sil2100)
status: Confirmed → In Progress
Akiva (akiva) wrote :

Just an fyi to anyone who is confused:
It is only the ubuntu SDK version from which does not have unity integration. It comes from this ppa which is found from the app tutorial on ubuntu's website:
http://ppa.launchpad.net/ubuntu-sdk-team/ppa/ubuntu

Install the package "Ubuntu-sdk", and qtcreator is forced to upgrade to the version which does not integrate into unity, lacking the hud support etc...

So, if you are just developing for QT4, I believe you can simply for the time being, simply take out the sdk ppa and reinstall.
I am going to bother the qt guys about this.

Łukasz Zemczak (sil2100) wrote :

Yes, Qt4 apps work correctly and no change is needed. The problem this bug is accessing is the lack of appmenu support for Qt5 applications (the Ubuntu SDK uses Qt5, so therefore it's affected). A fix for this is ready, now only the formalities remain.

summary: - Bring Unity appmenu / HUD integration to Qt5
+ [FFe] Bring Unity appmenu / HUD integration to Qt5
description: updated
description: updated
Dmitry Shachnev (mitya57) wrote :

Looks like the FFe request is ready, subscribing ~ubuntu-release.

description: updated
Scott Kitterman (kitterman) wrote :

First, you are wrong. qtbase-opensource-src is in Main:

qtbase-opensource-src | 5.0.1+dfsg-0ubuntu3b1 | raring | source

Even if it weren't, it wouldn't matter. It being in Universe would not give Canonical license to arbitrarily introduce divergence from upstream. I will ask again: What's the status of this upstream?

Changed in qtbase-opensource-src (Ubuntu):
importance: Undecided → Wishlist
status: In Progress → Incomplete
description: updated
Łukasz Zemczak (sil2100) wrote :

Thanks for clearing it up! The new description indeed wasn't too accurate. I missed the earlier comment so, let me try to answer the upstream question now.

What's the status of this upstream? There's currently no real status upstream.
For Qt4, we had appmenu support committed upstream. In Qt5, our all work we had committed upstream got trashed and QPA got introduced. QPA is the 'right upstream way to go' for appmenu support, as platforms can use QPA themeing to add things like global menu bars etc. The problem is, QPA got introduced with MacOS menu's in mind, which are realised completely different from how we originally designed appmenu-qt. Since our previous framework got removed from upstream, to get official upstream support for Ubuntu appmenu would require basically re-writing appmenu-qt from scratch to fit the new QPA framework. There is a bug for that (LP: #1157213) - I started work on this basically, but it's still in the beginning stages of development.

Since raring is nearing its release, the idea was to just back-port the previous framework as a distro patch to Qt5 so that we have something that is tested and working. The code pieces related to QMenuBar didn't change in a big way, so the back-port was relatively safe to do. Same for appmenu-qt and libdbusmenu-qt - changes were minimal, just enabling a Qt5 build alongside Qt4 is required.
Since we would have this 'backported' appmenu support for now, it would give us chance to work on the 'real solution' (QPA) in the meantime with less heavy deadlines. We could test the new functionality and submit our solution for upstream approval.

I apologise for the late reply.

description: updated
Łukasz Zemczak (sil2100) wrote :

Actually, the formal FFe wasn't even yet prepared, I am only now formalizing everything properly. ~ubuntu-release has been assigned a bit too early I think, but the formal modifications I am now performing should not really change the overall state of the problem - just trying to clean up here and there.

description: updated
Scott Kitterman (kitterman) wrote :

$ reverse-depends appmenu-qt
Reverse-Recommends
==================
* indicator-appmenu

Reverse-Depends
===============
* plasma-widget-menubar

$ reverse-depends plasma-widget-menubar
Reverse-Recommends
==================
* kubuntu-desktop
* kubuntu-full

Appmenu-qt is used in it's Qt4 version in the Kubuntu default install. How do you intend to support both Qt4 and Qt5?

Łukasz Zemczak (sil2100) wrote :

The appmenu-qt source package will now also build a Qt5 version alongside of the Qt4 version. So, from appmenu-qt both the appmenu-qt (Qt4) and appmenu-qt5 (Qt5) packages will be built. Same for libdbusmenu-qt - the packaging will be made to generate respective -qt5 versions of every relevant package in the suite.

Therefore the existing Qt4 support will work in the same way as before. Only Qt5 support will be available by installing the additional -qt5 versions of the packages.

Scott Kitterman (kitterman) wrote :

This is all starting to sound rather complex and late in the process to be adding it, particularly since it is just a workaround for the fact that proper Qt5 support in appmenu-qt and libdbusmenu-qt packages hasn't been developed. I've very reluctant to hack the Qt4 functionality into Qt5. Qt is supposed to be ABI compatible through the life of a major version, so adding and then removing such functionality does not seem like a good idea.

Akiva (akiva) wrote :

Tested, well done Mr Zemczak.
For what it is worth, I personally see no issue in having dual libraries; That is just the migration process when updating libraries.

Sebastien Bacher (seb128) wrote :

is that patch really changing the ABI? or is it an implementation detail which should be transparent for applications/qt users?

Scott Kitterman (kitterman) wrote :

@Akive: I don't find the appmenu/libdbusmenu changes particularly controversial. It's the changes to Qt5 itself that I find concerning.

Łukasz Zemczak (sil2100) wrote :

I can understand your worries, but I'm sure it shouldn't cause any problems. The API that we would essentially add 'temporarily' to Qt5 (the old framework) is anyway only used by us, and therefore we don't really expect anyone else use or miss the functionality once it's removed. Same for the *-qt5 versions of appmenu and libdbusmenu - once the proper support is added, we will simply release separate source package for those two. So the migration, in this scheme, should be smooth.

I could, of course, quickly try working on the QPA approach, but with the release so close by we won't have time to test the new functionality. As it would be completely rewritten, it's probably much error prone at the first stages.

Scott Kitterman (kitterman) wrote :

Right, but the no one is using it argument works for appmenu/libdbusmenu for
Qt5 as well. If there's a shot at that, I'd rather take the risk at that
level rather than in Qt5.

Łukasz Zemczak (sil2100) wrote :

The thing is... from what I saw in how QPA is done, we might need to have some code upstreamed in Qt5 as well, since we would have to either modify an existing platform (like xcb) to add our themeing there (since no themeing is coded) or write a completely separate platform basing on xcb which we use. Sadly it's not possible to tell Qt5 to 'load all things from the xcb platform just use this plugin here for QPlatformTheme' - it seems to be either all or nothing.
Probably there is a way of accessing the xcb theme classes and objects outside of the Qt5 build tree, but I didn't see it right away as all those are theoretically internal.

So, I'm worried that anyway even using the 'right' way to get things implemented, we would need to add things to the Qt5 source. Just in case of the 'right' way, this change could get upstreamed sooner or later...

That's actually why in the meantime I decided to backport the Qt4 solution. Since it's a completely new area to discover, plan and implement. I have some things started, but it's still just the first bricks.

Akiva (akiva) wrote :

For pragmatic reasons, if ubuntu is to expect a surge in its sdk downloads for raring, it would be advisable to ship something for sure, rather than nothing at all. As pointed out, it is very tacky to have a software development kit that fails to meet its own standards of ui implimentation.

Scott Kitterman (kitterman) wrote :

@Akiva: Getting something new right is a lower priority than not breaking existing things at this stage in the release cycle.

Scott Kitterman (kitterman) wrote :

OK. I'd rather not do this as I think it's too late, but I'm willing to lean forward a bit. Approved on the following conditions:

Before upload:

Test that the updated libdbusmenu-qt and appmenu-qt packages for Qt4 still work properly with their reverse dependencies:

* appmenu-qt
* kde-workspace-bin
* libdbusmenu-qt-dev
* libkdeui5
* plasma-dataengines-workspace
* plasma-widget-menubar
* plasma-widget-message-indicator
* plasma-widgets-addons
* quassel (just testing one quassel is fine)
* quassel-client
* quassel-client-qt4
* quassel-qt4
* sni-qt

Find an archive admin who is willing to do the binary New for the new Qt5 variant binaries.

After "S" opens:

The Qt5 patch is dropped immediately regardless of regression impacts. This forward port of the non-upstream (for Qt5) solution is a one time only.

If you think you need Qt5 changes for the appmenu-qt/libdbusmen-qt Qt5 ports to QPA, then start working on them now as they should not going into "S" without upstream agreement about the changes.

Changed in qtbase-opensource-src (Ubuntu):
status: Incomplete → Triaged
Changed in appmenu-qt (Ubuntu):
status: In Progress → Triaged
Changed in libdbusmenu-qt (Ubuntu):
status: In Progress → Triaged
Łukasz Zemczak (sil2100) wrote :

Thank you! We will make sure that all the mentioned packages are tested thoroughly!

I will also resume the work on QPA appmenu support as soon as we get everything ready for releasing the 'temporary backport appmenu' - i.e. the testing, and such. I will ask some of my colleagues to help me out here, so that we can have a working real appmenu solution as promised.

Again big big thanks! We will do everything in our might not to blow this chance.

Changed in libdbusmenu-qt:
assignee: nobody → Łukasz Zemczak (sil2100)
Changed in appmenu-qt:
assignee: nobody → Łukasz Zemczak (sil2100)
status: New → In Progress
Changed in libdbusmenu-qt:
status: New → In Progress
Changed in indicator-appmenu (Ubuntu):
status: New → In Progress
assignee: nobody → Łukasz Zemczak (sil2100)
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:libdbusmenu-qt at revision 240, scheduled for release in libdbusmenu-qt, milestone 0.1.0

Changed in libdbusmenu-qt:
status: In Progress → Fix Committed
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:libdbusmenu-qt at revision 241, scheduled for release in libdbusmenu-qt, milestone 0.1.0

Łukasz Zemczak (sil2100) wrote :

Tested the latest packages of appmenu-qt and libdbusmenu-qt:

- quassel - works properly on both KDE and Unity with appmenu-qt
- kde-workspace-bin - plasma KDE works with no problems
- plasma-widget-menubar - the KDE widget for appmenu menubars works ok for both Qt4 (quassel) and Qt5 (qtcreator)
- plasma-widget-message-indicator - this widget seems broken on my system all the time, no matter which dbusmenu and appmenu-qt versions are used, so cannot test it properly
- KDE - in overall, no visible regression

PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:appmenu-qt at revision 55, scheduled for release in appmenu-qt, milestone 0.1.0

Changed in appmenu-qt:
status: In Progress → Fix Committed
Scott Kitterman (kitterman) wrote :

I'm using the message indicator on quantal with quassel and kopete and it's working fine.

Łukasz Zemczak (sil2100) wrote :

My versions are:

appmenu-qt:
 *** 0.2.7daily13.01.18-0ubuntu1 0
libdbusmenu-qt:
 *** 0.9.2-0ubuntu4 0
(so old packages from archives on raring)

And I only get a broken GUI... see attached screenshot. I think I have something broken.

Scott Kitterman (kitterman) wrote :

Add it to the systray.

Łukasz Zemczak (sil2100) wrote :

Ah, ok, sorry then, never used this widget before. Now it works - both on the new and old appmenu!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtbase-opensource-src - 5.0.1+dfsg-0ubuntu4

---------------
qtbase-opensource-src (5.0.1+dfsg-0ubuntu4) raring; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * debian/patches/enable_appmenu_support.diff:
    - Add base-ported support for the Ubuntu global appmenu (LP: #1126205)
  * debian/rules:
    - Enable appmenu support when building the package

  [ Timo Jyrinki ]
  * Add build dependency on libgtk2.0-dev (and libatk1.0-dev) for
    gtkstyle support (LP: #1126210)
  * Add Vcs-Bzr for ~kubuntu-packagers
  * Because qt5.conf was moved to qtbase5-dev, depend on it from
    qt5-default. This means standalone development binaries like
    qmlscene cannot be used from the default path without installing
    development headers. Use deep paths instead.
  * Fix qmake-qt5 package description (LP: #1133196)
 -- Timo Jyrinki <email address hidden> Tue, 19 Mar 2013 12:47:57 +0000

Changed in qtbase-opensource-src (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libdbusmenu-qt - 0.9.2daily13.03.28-0ubuntu1

---------------
libdbusmenu-qt (0.9.2daily13.03.28-0ubuntu1) raring; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * Add inline packaging metadata.
  * debian/control,
    debian/libdbusmenu-qt5.install,
    debian/libdbusmenu-qt5-dev.install,
    debian/libdbusmenu-qt5-doc.install:
    - Add the -qt5 package versions of all libdbusmenu packages
  * debian/rules:
    - Enable a double build - first build a Qt4 version of libdbusmenu for
      libdbusmenu-qt2 and then a Qt5 version for libdbusmenu-qt5

  [ Mathieu Trudel-Lapierre ]
  * debian/copyright: fix copyright stanza for LGPL 2.
  * debian/control: bump debhelper Build-Depends to 9.
  * debian/source.lintian-overrides: drop the override.
  * debian/watch: dropped; no longer needed with inline packaging.
  * debian/control:
    - bump Standards-Version to 3.9.4.
    - add Vcs-Bzr/Vcs-Browser.
    - add comments for developers.
  * Automatic snapshot from revision 240 (bootstrap). (LP: #1126205)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 241
 -- Ubuntu daily release <email address hidden> Thu, 28 Mar 2013 20:27:01 +0000

Changed in libdbusmenu-qt (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package appmenu-qt - 0.2.7daily13.03.28-0ubuntu1

---------------
appmenu-qt (0.2.7daily13.03.28-0ubuntu1) raring; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * debian/control:
    - Add the appmenu-qt5 package for Qt5 appmenu support
  * debian/rules:
    - Enable a double build - first build a Qt4 version of appmenu for
      appmenu-qt and then a Qt5 version for appmenu-qt5
  * [FFe] Bring Unity appmenu / HUD integration to Qt5 (LP: #1126205)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 55
 -- Ubuntu daily release <email address hidden> Thu, 28 Mar 2013 20:39:16 +0000

Changed in appmenu-qt (Ubuntu):
status: Triaged → Fix Released
Akiva (akiva) wrote :

Successfully built https://code.launchpad.net/~sil2100/ubuntu/raring/qtbase-opensource-src/enable-appmenu

From synaptic, installed:
qtcreator 2.7.0 RC1
ubuntu-qtcreator-plugins 2.7.0 RC1

Testing:
HUD worked from startup. For example [alt + "About QTCreator" + Enter].
Menus were properly displayed in the titlebar.
HUD functionality worked in Fullscreen mode [ctrl + shift + f11], BUT, the unity overlay did not display. I could type commands blindly and have them work.

Other notes:
Installing ubuntu-qtcreator-qt5libs 2.7.0 RC1 broke HUD functionality and titlebar integration. Uninstalling it was easy enough.
http://imagebin.org/252344 << Screenshot of an oversized ubuntu plugin introduction page. I am not sure if this was broken due to the branch. It is something I just noticed now. I will file a bug for this.

For what it is worth; I am satisfied by the work Mr Zemczak and company did. The fullscreen mode is but a minor caveat, and is not surprising. I would expect the same to be true in qtcreator4, but I have not tested it.

Akiva (akiva) wrote :

^
Bug reported:
https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1162570
Please confirm it if you experience it too.

Scott Kitterman (kitterman) wrote :

This part of the report to kde-devel about the freedesktop summit seemed like it might be germane:

1) Standardized and implemented fdo.Application spec for "unique"
applications.

This is a standard DBus interface which replaces the KUniqueApplication
"newInstance" method (and adds a few additional features). I already
implemented it in the KDE-Frameworks-5 replacement for KUniqueApplication,
called KDBusService. The whole point of standardizing it is that it becomes
possible to start (unique) applications by just making a dbus call (which will
either use DBus activation to launch the application, or will ask the running
app to "activate", e.g. create a new window or a new tab).

This is really nice because it removes the need for a daemon like klauncher
for that particular purpose (launching an app and waiting for it to register
to DBus before talking DBus to it). The dbus server itself does the job for
us. This doesn't work for non-unique apps though (e.g. konqueror and its
multiple processes), but the suggestion for that use case was to write a
unique-app frontend (= dbus service) which delegates the task to a separate
(non-unique) process. This requires support from the apps though, unlike the
current `kstart --service foo.desktop` that any script can use to start an
app, wait for it to register to dbus, and then talk dbus to it. But maybe I'm
the only one using that :)

Implementation status:
* KDBusService now supports this dbus interface (see 608bccad0744 in kdelibs-
frameworks), but support for startup notification is missing.
* This led me to first re-implement startup notification support in Qt 5 (it
got lost with the rewrite to QPA) :
https://codereview.qt-project.org/53865

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-appmenu (Ubuntu Raring):
status: New → Confirmed
Adolfo Jayme (fitojb) on 2014-02-18
no longer affects: indicator-appmenu (Ubuntu Raring)
Changed in indicator-appmenu (Ubuntu):
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers