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?
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.
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.
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.
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?)
@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.
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.
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.
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)
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.
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?
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.
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.
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).
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)