So this change bundles the gtk platform plugin for Qt and then enforces it's use with the gtk launcher? It also maintains the look and feel by enforcing the fusion style? Seems like a win win to me!

Yes that is the end effect of this. But let me explain a bit what and why it is done.
Qt used to have great GTK theme integration via a custom Qt style plugin called QGtkStyle, which was based on GTK2 themes though. Now with GTK3 there's no style integration that is officially supported by Qt.

However there this official gtk3 platform theme, which despite its name, does not affect the style directly. It just improves a little bit the integration with GTK based desktop environments by using the native GTK3 based file chooser dialogs and the font settings. The default snap Qt file chooser dialog is wird and not user friendly because it lacks bookmarks and opens a default directory inside the snap tree which most users are not interested in and have difficulties to navigate to the real home folder.

Now, because of some unknown changes done by snapcraft or core18 base, that caused the issue #2966 in the first place, we have to manually force the fusion style now with -style fusion. This affects only snap versions, it's a workaround to force the correct style when using GTK integrations.

And lastly, to make this even more hacky, Qt enables platform themes or style plugins though the QT_QPA_PLATFORMTHEME environment variable. So we could just set that inside the snapcraft.yaml file alongside the DISABLE_WAYLAND env variable. But that would be too easy. Snapcraft and the Qt5 desktop helpers (ie. the desktop-launch command) sets a custom QT_QPA_PLATFORMTHEME variable and overwrites previous values. So to work around this, we ship a custom launch script called gtk3-env-launch which is executed after the classic desktop-launch allowing use to set QT_QPA_PLATFORMTHEME=gtk3 correctly.

Added commit to fix database locking, see #3027

desktop must be a new plug because I would have added it in the past. This is probably functionality that was provided by core at some point and migrated into the desktop plug. I am also probably talking out my butt, but when it comes to snaps anything is possible™!

Hmmm, just looked it up, it was released in snapd 2.28 back in Oct 2017. I am ready to merge this into 2.4.2 for testing.

Actually I tested your build on Ubuntu 18.04 and found that the icons shown in the application are totally wrong. The password generator icon is not used and the lock database icon isn't either. I think we need to restrict this solution a little further, its almost like a shotgun blast when we need a sniper.

Could you fix the trailing space just for the sake of consistency? Thanks!

Oh no, I might have to close this PR because you didn't create it off a branch. Do not submit a PR against develop. And definitely don't merge in develop.

Please resubmit with your changes in a branch that is based off of release/2.4.2

Sure, did a couple of mistakes.
I'll propose a separate PR to fix the screen locking and then another one for the snap theming fix.

About the theming. I guess the icons are the result of the gtk3 qt platform theme plugin, so not sure what we can do about it. At this point I'm questioning this approach as it causes a lot of troubles.

I could re-propose this PR again against the 2.4.2 branch.
Or if you prefer, since you expressed some concerns and the icon issue, we could go back to using the default approach, by undoing recent theming tweaks by a new PR, just let me know.

Eventually snap, once mature enough, will hopefully fix the mouse cursor and other theming/integration issues.

I think we can just block some of the gtk icon themes from being staged and prevent overwriting our desired theming

Was checking out the flatpak version, which appears using the QGnomePlatform plugin. Icons are also broken.

It's community based and not an official package. Interesting though.

After trying to selectively disable the icon theme only, without affecting the other integration, I have to say it's not possible because KeepassXC uses icons directly from the theme like:
m_ui->actionDatabaseNew->setIcon(filePath()->icon("actions", "document-new"));
Which on linux, is like saying: "give me the default icon for the new document action from theme".
Compare that to the use of custom shipped icons done with, for example, m_newRecordAction->setIcon(QIcon(":/images/icons/newrecord.png"));

It could be possible to hack a custom icon theme and then specify the standard path like documented by Qt, but too much of a hassle IMHO: https://doc.qt.io/qt-5/qicon.html#fromTheme

BTW this affects all linux builds of keepassxc, so it's a much bigger issue, for example the appimage is using the default adwaita icon theme, which for example is missing the lock database icon:

It makes sense to use standard icons for common actions that are supported by all icon themes like, new, edit delete and then to ship and specify custom icons for specific actions like database locking and password generation.

This doesn't affect Windows and macOS because this icon theme integration is only available on Linux.
The most simple solution would be to just always use and ship custom icons, since it's already done for Windows/macOS anyway.

So to conclude, the snap-gtk3 integration would work well, but because of the way keepassxc loads icons from theme it will always have unexpected results on Linux based environments (Mint, flatpak, snap, deepin, fedora, etc), because each theme is different with different supported actions.

Maybe this could be considered for future work when refreshing the app icon set.

Progress:

QIcon::setThemeSearchPaths(QStringList() << ":/icons"); did the trick, this way Qt is forced to use the fallback (custom shipped) icon theme, just like on Windows and macOS.

Preparing a new PR :D

Oh yeah, duh 😀 please do wrap it with the build type snap ifdef