[Enhancement] AppImage native file manager dialogue

[elsandosgrande]

@probonopd So, here we are. One other complaint about the Windows look-alike file manager is that it is a pain to scroll in with a touchpad (sometimes it registers a horizontal scroll when I'm scrolling vertically and happen to move my fingers a bit to the side as well) because it's disruptive.

[itsmattkc]

Running Olive natively (Ubuntu apt build) shows the following dialog:

Running Olive in AppImage, Qt falls back to its own dialog:

[elsandosgrande]

Yeah, that's not Qt's dialog from what I know. Well, either way, it's neither Nautilus on your system nor Dolphin on mine. That is the dialog I am seeing with the AppImage though.

[itsmattkc]

I believe it is Qt's, you can get the same dialog by setting QFileDialog::DontUseNativeDialog on any file dialog (plus it's using the same styling that Olive is using).

[elsandosgrande]

Alright then. Wait, would removing Dont possibly have the reverse effect in the AppImage?

[itsmattkc]

@elsandosgrande Unfortunately there isn't an option for that - QFileDialog is supposed to always use a native dialog if it can find unless otherwise specified. The fact that it doesn't means it can't find one, which is why it falls back to the one you see.

[probonopd]

The "orange" file dialog is from Ubuntu (Gtk), whereas the "blue" one is from Qt. So "something" (most likely a Qt plugin) must be causing the Qt on your system to use the Gtk dialog, while that "something" is not bundled inside the AppImage. To get the AppImage to do the same, the "something" would need to be bundled in the AppImage, too.

Just a wild guess, would this help?

########################################################################
# https://askubuntu.com/a/910143
# https://askubuntu.com/a/748186
# At runtime, export QT_QPA_PLATFORMTHEME=gtk2 (Xfce does it automatically)
########################################################################

apt-get update
apt-get -y install libgtk2.0-dev
git clone http://code.qt.io/qt/qtstyleplugins.git
cd qtstyleplugins
qmake
make -j$(nproc)
make install 
cd -

(...)

linuxdeployqt (...) -extra-plugins=platformthemes/libqgtk2.so,styles/libqgtk2style.so

Reference: https://github.com/probonopd/linuxdeployqt/issues/60#issuecomment-456185392

[elsandosgrande]

Let's hope that will be enough, since the scrolling sensitivity is off the charts.

[probonopd]

After looking at the screenshot above, it seems like we see Gtk 3 there, so it's probably a different Qt plugin. I don't know which one.

[elsandosgrande]

Great...

I still do not understand why an AppImage can't access the native file manager when an AUR version of Olive from December can. Can someone enlighten me?

[capezotte]

@elsandosgrande The native file manager functionality is provided by a Qt plugin that is loaded by the Qt library on your system. The AUR package is compiled with your libraries, so they'll look for the plugin in your system.

On the other hand, the entire point of AppImage is shipping the program with library versions known to work, so they avoid looking for libraries on the system that might not work.

[elsandosgrande]

@oc1024 So, I'll give him a list of my installed packages and he stuffs the libs in the AppImage? I mean, I don't mind, but it doesn't seem like he has that kind of time right now and it seems too easy to work. Here, take it: pakku -Qq.txt

EDIT: This is why I'd like there to be something that the AUR package can sink it's teeth in without the loss/replacement of the hashes.

[itsmattkc]

As I said, my assumption is the AUR package is set to only update tagged commits rather than update all commits (like the AppImage, apt, and I think flatpak do). Preferably it would, but I'm not sure if AUR allows that (and like I said in #461, I didn't set up and don't maintain that repo).

[capezotte]

Looking at the PKGBUILD, it seems the AUR package is setup to look for a hardcoded specific version. While this allows for corruption checks (checksums), it means the maintainer has to manually update both the version and the checksum.

Since it is stuck on the "December Stable" release, maybe the maintainer is waiting for the "January Stable" release.

If I actually knew how to upload a PKGBUILD I'd set up an olive-git package.

[itsmattkc]

@oc1024 Interesting, yeah I assume so. I'll probably hold out for a February stable at this point.

@probonopd That fix doesn't seem to have made a difference on my end.

[itsmattkc]

Adding libqgtk3.so to the AppImage (squashfs-root/usr/plugins/platformthemes) provides the GTK 3 dialog and KDEPlasmaPlatformTheme.so provides KDE's.

Is there a collection of these plugins I can pull from or do they each have to be laboriously pulled and built individually? It's looking like it might have to be the latter since KDEPlasmaPlatformTheme.so (for example) seems to be provided by KDE themselves, not by Qt.

[elsandosgrande]

Umm, does that mean that there is a public commit with them added or?

[itsmattkc]

@elsandosgrande That's what I'm wondering. It seems usually these are provided by the OS itself, but aren't picked up by or included in the AppImage. The only way I know of to include them currently is to build each plugin from source (for libgtk2, libgtk3, KDE, and any others that exist) every time the AppImage is built which seems a little crude. Maybe there's a way to import the plugin from the system (symbolic link maybe?), that feels like a better solution since it's OS-dependent anyway.

[elsandosgrande]

Well, I'd suggest going the symlink route and, if it doesn't work out, going the crude route until a proper solution can be attained at, sadly, a later date.

[probonopd]

Check out linuxdeployqt (...) -extra-plugins=...

[itsmattkc]

Where would the plugins come from? Do I have to pull and compile GTK2, GTK3, KDE, etc. plugins for every single Travis CI build? Is there a way to get the AppImage to look for platform themes already on the host system, since they're specific to (and provided by) the DE the user is using anyway?

[probonopd]

This is not an AppImage related question. It is a Qt question. Think of AppImage just as a container format like a zip, tgz, or iso file. The AppImage just executes whatever you put inside it. Which Qt plugins you want to bundle is up to you.

[elsandosgrande]

@probonopd So, basically, the piece of software required for displaying the native file manager is missing and Olive then goes into fallback mode. Well, @itsmattkc , if my understanding is correct, it's gonna be the rough way.

[itsmattkc]

I feel like implementing every DE's plugins to make them all work natively is unproductive. Maybe we can implement the big 3 (i.e. GTK2, GTK3, KDE) but I think the real solution, in your case, is to create a new AUR repo that's up to date with the Git so that people on Arch who want a more native experience can get it that way.

[elsandosgrande]

I think it would be best to go with the big three in App+AUR that goes by hash instead of tag. I think that this new package should be called something like Olive-prerelease-git.

[itsmattkc]

From what others have said, the AUR isn't even locked to tags, it's literally just locked to the December build. If so I guess the intention would be to update it manually once another tagged release comes out?

[elsandosgrande]

Sadly, that information is beyond the scope of my knowledge.

[itsmattkc]

AUR now has a Git repository up to date, which should fix the core of this issue. See https://aur.archlinux.org/packages/olive-git/