Call for testing: communitheme + Qt

We found a solid way to provide communitheme gtk2 theming for Qt and KDE applications. We need you to test it on 18.04 and/or 18.10.

This is what you need to do:

  1. run in terminal: sudo snap install communitheme
  2. run in terminal: reboot
  3. Log into communitheme session
  4. run in terminal: sudo apt install qt5-style-plugins
  5. run in terminal: sudo apt purge libgtk2.0-0 ((( this might deinstall thunderbird )))
  6. run in terminal: export QT_QPA_PLATFORMTHEME=gtk2
  7. Start a Qt app from within the terminal like for example “vlc” or “dropbox”

Step 6. + 7. need to be made every time you test a new app.
And then come to github and report all issues with Qt/KDE apps. The best would be if you try as many different of those apps as possible.

4 Likes

Are you sure you meant apt purge libgtk2.0-0 ?? This will remove Gtk2, and hence QGtkStyle will not work - and Qt apps will not use the Gtk theme.

Using your instructions above, which removed the gtk2 styling, vlc uses the Fusion style (Qt5 default) - but has Gtk file dialogs.

If the removing of gtk2 is a mistake, and Qt apps are supposed to use the gtk2 style, then the gtk2 Communitheme needs to be updated to provide arrows for scrollbars. Gtk2 itself will ignore these, as its configured to not have scrollbar buttons. But, QGtkStyle ignores this setting, and always assumes scrollbars have buttons - and so if the theme does not provide the arrows, an empty space is drawn where these should be. This just looks odd. Adding these to gtkrc works-around the issue.

Why use the gtk2 platform as opposed to QGnomePlatform (which is used by Fedora) ?? QGnomePlatform allows Qt apps to use Gtk dialogs, sets the Qt font to the Gtk one, and will also try to match the user’s Gtk theme to a Qt one - such as Adwaita-Qt (again, used in Fedora), or Kvantum (if it has a matching style).

Has it been decided to not use QGnomePlatform + Kvantum?

1 Like

Don’t purge libgtk2.0-0!

This is not required and might break a bunch of stuff.

Option 1: QGtkStyle

What these instructions do is install the deprecated GTK2 platform theme and force QT to use that instead of the new GTK3 platform theme. The GTK2 platform theme uses the GTK2 theme to style the QT components.

Good

  • We don’t have to maintain a QT theme; QT applications use the GTK2 theme.
  • Everything we need is in the Ubuntu archives.
  • It works right now.

Bad

  • This functionality is not part of core QT anymore.
  • It relies on the depricated GTK2. (default install of Ubuntu desktop will require GTK2 if we choose this. Many people were hoping to be able to drop it from the iso from 18.10 onwards)
  • This doesn’t integrate with GTK3 and all QT applications will use GTK2 file choosers instead of GTK3 file choosers.

Note that it is still used in other distro’s, for example Manjaro: https://github.com/manjaro/release-plan/issues/73

Option 2: QGnomePlatform + Kvantum

good

bad

  • We need to maintain an additional theme and keep parity with the rest of communitheme (how willing is tsujan to keep up with us?).
  • Neither Kvantum nor QGnomePlatform are packaged for Ubuntu.
  • This includes two additional c++ codebases which needs to be audited etc… before we can include them in the default install. (I’m not familiar with this process, what needs to happen and how does it work?)

More info:

3 Likes

@merlijn-sebrechts , The way you put it, is not so clear. Are you talking about a solution that will be part of the Ubuntu out of the box? I hope it will. The way you describe it sounds like choosing between the devil and the deep blue sea. We, as users, using those and some other methods to solve it for years now.

Those who trying to kill gtk2 ,eventually will. that’ll make the first solution temporary .

One of the prominent reliable and friendly developers is Tsujan . as far as I l know, is more then ready to help us with it. His tool, Kvantum manager is the best . The work he did so far with communitheme is impressive.
If it’s up to me, I’ll without a doubt choose the Kvantum out of the two.

My intention is to support Qt by default in Communitheme. That means that whatever solution we choose will be shipped with Ubuntu by default from 18.10 and onwards.

My preference also goes out to Kvantum. 18.10 is a good cycle to test out new stuff. If anyone is willing to package it, please do so, it would help a lot.

1 Like

@CraigD is your man regarding to the subject. He is doing a great work, hand in hand with Tsujan, fine tuning the theme to pefection.
I have no knowledge about packaging. sorry…

Just to give you a glance of the ongoing awesome work they both doing :
KvCommunitheme

Someone needs to package KvCommunitheme, look at the dependencies, get that into the distro (preferablly, debian, and then synced into ubuntu), do security reviews of the code (and dependencies) and finally, once in distro, open a Main Inclusion Request ensuring that it follows those criterias. (https://wiki.ubuntu.com/MainInclusionProcess)

At the same time, the theme would need IMHO to be included officially in the communitheme realm, meaning git repo being moved, and being kept in sync with discussions for parity.

Anyone volunteering for all the above ? :slight_smile:

As stated QGnomePlatform is already used (and developed by) Fedora - so its codebase is quite small, so should be fairly easy to audit.

Kvantum’s codebase is larger, but not a great deal - and (IMHO) it has less bugs than QGtkStyle

Tsujan is very passionate about his work, and is very active in keeping his code base clean and functional. If there are concerns about KvCommunitheme not keeping track with the Gtk variant, the KvCommunitheme files (one SVG file and one config file) can be imported into Ubuntu’s own github and packaged separately from Kvantum. For Kvantum to use a particular theme, it needs a user config file to be updated with the theme name. Kvantum will then look in (e.g.) /usr/share/themes/NAME for Kvantum/NAME.kvconfig (e.g. /usr/share/themes/Communitheme/Kvantum/Communitheme.kvconfig) This setting of the user’s Kvantum config is done automatically by QGnomePlatform (if it can find a matching Kvantum theme).

Kvantum currently has Qt counterparts for; Adapta, Ambiance, Arc, and Communitheme.

1 Like

I had a quick look at licensing. For your confirmation, the license isn’t suitable if what is under style/ is running within the application process. It’s currently GPL3, and it should be LGPL*
Changing the license require a written acknowledgement by all contributors (so, I mean by all of https://github.com/tsujan/Kvantum/graphs/contributors)

Seeing as I’m the one who keeps moaning about this, I guess I should volunteer :slight_smile: However, I have no experience of creating a debian package, or getting a package into debian. Any pointers?

3 Likes

http://packaging.ubuntu.com/ is probably the best to get started. You should also get some inspiration from some other theme packages to get some help.

I guess you meant rather that Kvantum is respecting XDG_DATA_DIRS and not a hardcoded path? (or it’s already a first point that the code really has to be closely reviewed)

Edit: it seems that it’s been hardcoded and not respecting standard specs: https://github.com/tsujan/Kvantum/blob/master/Kvantum/style/Kvantum.cpp#L765
(and 18000 lines in a single file isn’t what I would call maintainable code, is there any effort to make that better?)

→ this is typically what a review of code quality is like, and something we (for ubuntu main) are closed to, as it’s code we’ll have to maintain for security issues and bugs…

I’ve created 2 new issues to cover these; Re-license to LGPL, Use XDG_DATA_DIRS

What about QGnomePlatform ?

Thanks! Another one as well to split files in something more maintainable?

For QGnomePlatform, the code looks simpler. However, this part worries me:

Please note this library uses private Qt headers. It’s most likely won’t be forward nor backward compatible. This means you’ll have to recompile it with every Qt update.

Having gone in the past for QtDesigner using the private Qt headers, we saw those are changing a lot and is a lot of extra work. Fedora as some functionalities to rebuild every reverse dependencies that Debian/Ubuntu doesn’t have, and it’s way more work…

But yeah, someone needs to pacakge it as well. While doing the packaging for both, those 2 projects shouldn’t pull Qt by default (only be there to be ready to link against once an application requiring Qt is installed). We don’t want to pull Qt on the iso just for that (I can help with this).

/!\ this is what I spotting with a 5 minutes check, and as you saw, it’s already quite some criticals issues. A real security and maintainability audits need to be performed for installing this by default.

1 Like

New issue created for splitting code - however, splitting the file up just for the sake of it would not be a high priority for me. There will still be the same number of lines, just across files.

I think most platform theme plugins require usage of private headers - they are intrinsically linked to the version of Qt they were built with, and need to be rebuilt each time Qt is.

Why have these 2 packages installed without Qt? That makes no sense - they will link to Qt libraries.

1 Like

Indeed, but in general, code is organized by area and topic, via files (and folders) in packages (or namespaces, depending on the language used). This separation of concerns enables better testing (when the code has tests, which isn’t the case here), ensuring functionalities are grouped in logical places and ensure we avoid abstraction leaking ending up in spaghetti code.

Not the case for GTK, but that’s fair enough, we’ll have to see how much they are moving between releases.

We don’t want that installing the theme support by default pulls Qt on the ISO. This would mean a hundreds of MB of download for every ubuntu user and 200-300 additional MB on the installed system, for nothing using it on the system by default! This is why the package has to be hacked to remove the Qt dependencies (fine for build-time, only talking about runtime here).
Then, when someone installs the first application using Qt, this application will pull the needed Qt parts via the package dependency system and the inactive theme module will find the Qt libraries. Making sense?

1 Like

Ah, I think we have our lines crossed. I think Kvantum + QGnomPlatform should pull in Qt5. But the Kvantum theme for Communitheme should not. This would imply 3 packages - QGnomePlatform (C++), Kvantum (C++), and Communitheme (SVG + config file). Perhaps KvCommunitheme.kvconfig & KvCommuniotheme.svg should be copied (with permission from Tsujan) into (e.g.) https://github.com/Ubuntu/qt-communitheme ?

I know, I’m a software engineer. I agree the 18000 lines is excessive (never noticed the line count). I’ll see what I can do about splitting this up, and create a pull request.

1 Like

No, I meant the whole Kvantum + QGnomePlatform shouldn’t depend on Qt4 or Qt5 as well or it would mean we can’t install by default, which we need for theme support. The same idea than before: if we do that, it means every ubuntu user will have Qt installed, when they don’t need it. We are already trying to reduce the iso size and base installed fingerprint, this would be detremendous.
We already did this in the past: appindicator support for unity was a Qt module where we stripped in the debian package the Qt dependency. That way, it was installed by default, but inactive until the first Qt app is installed.

I don’t see any other way to have those at least looked at for possible default inclusion.

Agreed, and we can ship it as part of the communitheme snap.

Thanks! :slight_smile:

3 Likes

A bit more context on this: You currently can’t create a dependency that says “if BOTH Communitheme an Qt are installed, then install Kvantum + QGnomePlatform”. Thus, if we want to support Qt theming by default, we need to make Kvantum + QGnomePlatform either a dependency of Communitheme or a dependency of Qt4/5.

The Qt4/5 option isn’t ideal because that would mean for example that each Kubuntu and LXQT installation pulls in Kvantum + QGnomePlatform (and thus probably Gnome/GTK).

2 Likes

Why not “if GNOME shell is installed, install Kvantum+QGnomePlatorm, but not Qt” ? I think that is what @didrocks was implying? Then when a Qt5 app is installed, it pulls in Qt5, and uses Kvantum+QGnomePlatorm

Kvantum has a matching Ambiance theme, so I think it should be used for the regular Ubuntu session as well. For the pure-GNOME session, I think we should also package Adwaita-Qt (then use Adwaita-Qt + QGnomePlatform)

3 Likes

This would be actually “in ubuntu” (ubuntu desktop), "install Kvantum+QGnomePlatorm, without Qt” (hence the removal of Qt deps from those 2 packages). The rest is correct :slight_smile:

Have you tested with Qt4 apps? Is Qt4 still relevant given the number of years Qt5 is out now.

There will be no more Ambiance theme, so it won’t be installed once we switch to Communitheme.

Good note for the vanilla GNOME session! I think you meant using Adwaita-Qt + Kvantum + QGnomePlatform or Adwaita-Qt isn’t a Kvantum’s theme?