Is is possible to use the native Qt file chooser instead of the GTK one, on KDE

[adrfantini]

As per title. On KDE, the native Qt file chooser (e.g. when uploading files) is much better than the GTK one, both in terms of looks and functionality. It'd be great if one could use that file chooser instead of the GTK one.

[squalou]

I have absolutely no idea how electron is deciding what file chooser to use, I'll have a look. Best way to learn something new :)

[adrfantini]

Awesome thanks!

[squalou]

Reading this is interesting

https://tristan.partin.io/blog/2021/04/01/electron-linux-and-your-file-chooser/

From what I understand and to sum up things :

• electron is based on chromium (we knew that)
• chromium implements GTK only
• there are things in GTK since 3.20 to allow a "use native file chooser"
• ... but for ascendant compatibility reason electron will rely on GTK 3.18
• and the auhtor of the article commited a fix to electron

All in all ... we need to wait for the electron release that will support it !

[adrfantini]

Uhm, my chrome on both Arch and Ubuntu uses the native Qt file picker (via Kdialog, I think). I'm not sure if this is due to distribution-side patching, but I doubt it since Arch tends to ship vanilla software.

[squalou]

Hm, I may have read too fast.

check xdg-desktop-portal-kde is installed on your system

then export GTK_USE_PORTAL=1

and then gtk apps should open native file chooser (qt in your case)

so, from a terminal, export GTK_USE_PORTAL=1; /opt/google-chat-linux/google-chat-linux

finger crossed it will maybe work ?

[adrfantini]

I'll test this on Monday and let you know!

[adrfantini]

Sorry for the delay! Tested, but alas no workie :(

[squalou]

after reading quickly here : electron/electron#19159
looks like it could be supported this way in electron 14, at best.

That doesn't explain how it works in other electron-based apps that work correctly though.

strange, really.

maybe you could try with a local build, using electron@beta ? That is, if you wanna play with npm and node and such :)

edit package.json : replace existing electon 12 by 14,

       "devDependencies": {
-        "electron": "=12.0.2",
+        "electron": "=14.0.0",
         "electron-builder": ">=22.6.0"
       }
     },

follow readme build instruction

npm install
 export GTK_USE_PORTAL=1
./google-chat-linux.sh

[squalou]

good news is : electron 14 has just been released today !

https://www.electronjs.org/releases/stable#14.0.0

I did a quick check, it's promising. (ugly but promising)

On my system with xfce, without setting any variable, it does work. Buttons display "gtk-cancel" and "gtk-open" which is ugly.

Then, setting the variable : file chooser fail entirely with error :

 Can't open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files

which tends to prove that it has an effect. I probably simply miss the required portal package.

I may add a dependency in arch aur package (or at least a optional dependency), still doing some tests first.

[adrfantini]

Thanks! I'll check it out. Even though I'm not sure when electron 14 will be available for my work laptop running Ubuntu.

[squalou]

I've just built a .deb for a quick test, you can try it, get it there :

https://github.com/squalou/google-chat-linux/releases/download/test-e14/google-chat-linux_5.14.1-1_amd64.deb

[adrfantini]

Unfortunately I still have the GTK file picker on Kubuntu 20.04 LTS.

[vchernin]

Then, setting the variable : file chooser fail entirely with error :

 Can't open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files

which tends to prove that it has an effect. I probably simply miss the required portal package.

I may add a dependency in arch aur package (or at least a optional dependency), still doing some tests first.

Random user stopping by, do you have xdg-desktop-portal installed? That is a completely necessary dependency for the portal to work.

[adrfantini]

Then, setting the variable : file chooser fail entirely with error :

 Can't open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files

which tends to prove that it has an effect. I probably simply miss the required portal package.
I may add a dependency in arch aur package (or at least a optional dependency), still doing some tests first.

Random user stopping by, do you have xdg-desktop-portal installed? That is a completely necessary dependency for the portal to work.

I do, 1.6.0-1. Still nothing. And no logs on console specific to when I open the file picker, I would say.
(thanks for stopping by!)

[squalou]

too bad my other computers running ubuntu are using gnome.
I may try a VM quickly, that's weird it really should work once you have set GTK_USE_PORTAL=1

[squalou]

From Kubuntu LTS, vanilla liveCD (not even installed), then just installed the .deb : looks like it works.
(even without GTK_USE_PORTAL apparently)

Here's what appears when I click the "upload file" button in a room

[adrfantini]

Wait, no, maybe then it's not clear what I mean.
This is the correct Qt file picker that pops up from Chrome on Kubuntu:

[squalou]

Ah, damn !
never used Plasma before, I thought the one I saw had non-gtk look enough to be convinced it worked :)

Do you have the same as in my screenshot at least ? with whatever version ?

[adrfantini]

Do you have the same as in my screenshot at least ? with whatever version ?

Yes, I do. As far as I understand that is the qt-fyied version of the GTK file picker using the native plasma translation layer between the two that tries to integrate GTK apps into the Qt environment.

(my bad, I should have provided screenshots)

[squalou]

I've tried to remove xdg-desktop-portal on the kubuntu VM, set the env variable, or any combination of the two : I see the same thing as you. No error on console, and no native picker displayed. (but yet, a picker displayed, no error)

So there's something different from what happens on my arch laptop. ... really but no idea what.

[squalou]

also tried kde neon distrib, latest plasma DE on ubuntu LTS => same result. There's something I don't get.
Arch gives xdg-desktop-portal 1.8 whereas ubuntu lts gives 1.6 but ... considering early development of electron patch dates back to 2019 I don't see how it would make any difference.
Will have to try another distrib, maybe kubuntu 21.04

[squalou]

same result with kunbuntu 21.04 and xdg-desktop-portal 1.8 ... I'm totally clueless

[squalou]

final test using Anarchy installer in a VM, with KDE and xdg-desktop-portal

git clone, npm install, run : looks better. (I mean : looks like there's an effect)

BUT not satisfying yet, as it apparently still launches a gtk-thing (from the button labels)

[squalou]

@vchernin if you ever happen to step by again, any further idea will be welcome ;-)

[squalou]

@adrfantini you may want to try this

https://forum.manjaro.org/t/change-firefox-file-manager/54760

and check if it works fine with firefox.

If so ... it would mean that somehow electron is still having issues.

I did the test in a Kubuntu VM : looks fine for firefox. ...

as for Chromium working :

As I understand it Chromium might be moving in a direction where they always use the ChromiumOS file chooser and not native toolkits also. So Electron probably wants to retain that native integration. (I pointed them in the direction of the file chooser portal but I don't really follow Chromium much)

[vchernin]

git clone, npm install, run : looks better. (I mean : looks like there's an effect)

BUT not satisfying yet, as it apparently still launches a gtk-thing (from the button labels)
final test using Anarchy installer in a VM, with KDE and xdg-desktop-portal

As far as I can what you saw here looks correct. It looks extremely close to the Chrome example above.

I don't think the gtk-open is anything to be worried about, maybe it's a bug though that can be improved. It even says xdg-desktop-portal-kde above.

The question is then what is Ubuntu doing wrong here.

What version of xdg-desktop-portal and associated backend packages (xdg-desktop-portal-kde, maybe xdg-desktop-portal-gtk, etc.) were installed when you did this test? Which ones did you have when you tried on Ubuntu? Maybe try installing the same packages from here on Ubuntu?

xdg-desktop-portal-gtk for one shouln't really be necessary on KDE for this. But maybe it's involved I'm not sure.

I would have offered to help more directly but my internet is currently not suitable to download a bunch of ISOs :(

[vchernin]

I managed to install this on a Fedora 34 KDE vm I forgot I had...

git clone https://github.com/squalou/google-chat-linux
cd google-chat-linux
git checkout e14
sudo dnf install nodejs
npm install
./google-chat-linux.sh

I didn't work with whatever I had out of the box with xdg-desktop-portal 1.8.1 and xdg-desktop-portal-kde 5.22.4 installed.

Time to play around with things...

Edit: I was on the wrong branch...

Edit 2: I still can't get things to work after trying various combinations.

[vchernin]

Firefox works reliably with GTK_USE_PORTAL=1, but that variable seems to have no effect here.

Having xdg-desktop-portal-gtk also present doesn't change anything either.

I did notice something somewhat suspicious in the log when starting the app:

useXdgOpen: false

Could that be the cause?

Edit: no doesn't look like it changes anything :(

[tristan957]

Chromium shows you the KDE dialog because it shells out to an external kdialog process.

[tristan957]

@squalou so were you able to get it to work?

[tristan957]

The gtk-open is a stupid issue that I don't really know how to fix. In fact, I am surprised Electron released with this issue. electron/electron#30247

[vchernin]

Ok I am really stumped, just installing xdg-desktop-portal and xdg-desktop-portal-kde is enough to get it working in Arch KDE. No env variable or xdg-desktop-portal-gtk required.

Are we running into some strange unsandboxed app portal bug?

[squalou]

Hmm, now that you mention 'sandbox', I don't even remember how often I had to disable / enable sandboxing for some reasons.

After a quick check I still have sandbox : false
and nodeIntegration: true which is also something maybe unusual.

Will try again and edit this. (have to reinstall VM quickly)

[Edit] same result with sandbox: false (was on kubuntu 21.04 this time, with portal 1.8) . Same thing with nodeIntegration:false.

[squalou]

@vchernin @tristan957 finally read all your comments, and thank you all for the investigation effort.

Indeed on Arch it is fine. I was mislead because of the 'gtk-' on the button but it's really using a kde looking thing.

Still, no way to have it work on another distrib. And ... I really can't figure out why. Electron itself is the same, kde probably too, KDE Neon reference distribution should be as close to what I get on Arch ... but still fail.

Total Mystery.

[tristan957]

This whole portal conundrum is so confusing... It is obvious no one within Electron tests on Linux.

[vchernin]

Hmm, now that you mention 'sandbox', I don't even remember how often I had to disable / enable sandboxing for some reasons.

What I meant by sandbox was not about Electron's sandbox, but the nature of the portal itself.

For some background, this feature works by the use of XDG Desktop Portals. They offer a standardized Linux ways of communicating between apps and host. Originally portals was meant for sandboxed Flatpak apps, but since then it has expanded its role to include non sandboxed apps. That's all I meant by sandbox, the app format, not really about Electron itself.

To implement the use of the portal GTKFileChooserNative had to implemented in Electron. This being implemented means Electron should seamlessly call the FileChooser Portal and use it as required.

But all that doesn't really help us much, I still have no clue why it behaves differently across distros.

I'd really like to see what happens with a Flatpak app with Electron 14 as maybe it works more consistently there.

[squalou]

small try with manjaro out of the box live ISO. Looks good.

Tried with the .deb, extracted manually and run. (to make sure it was not due to github build system)

I really don't get it and I feel there's nothing I can do about it.

Being short on ideas, I think I'm gonna release this as is, with a warning somewhere in the readme maybe.
if after all it is a distrib-specific thing, hopefully it will be solvable without changing anything in the app.

Does it sound like a sane decision ?

[tristan957]

I don't really understand why the name of the window is what it is.

[squalou]

for the records, some other small details, seen with XFCE (which is gtk-based if it matters).

With or without GTK_USE_PORTAL, the window is called "Untitled window" in the windows list.
But gtk being gtk, the title is not displayed.

Also, without GTK_USE_PORTAL : the window icon inherits the app's one.
With GTK_USE_PORTAL : the icon is the default one. It looks like on KDE it's the same with the "Xorg" icon in the window corner.

Finally as already seen, without GTK_USE_PORTAL I can see gtk-open / gtk-cancel on the buttons.

[Edit] afterthought : maybe the fact that the window has no title defined explains de title displayed on kde.

[vchernin]

I don't think there's a big issue with releasing it now, it doesn't really regress anything important in my view. Unless you consider the "gtk-open" and window title to be blocking here.

At least it uses the right file picker in some places...

In the meantime I'll watch what happens with other Electron apps on various distros. I tried building Jitsi Meet Electron with 14 but I got stuck most likely because I didn't know what I was doing (something about Node ABI version being wrong...)

[tristan957]

Here is the line where the title is set. It is the first argument: https://github.com/electron/electron/blob/main/shell/browser/ui/file_dialog_gtk.cc#L147. I am not sure how that gets translated to the window title via the portal. Does the title change whether GTK_USE_PORTAL=1 or not?

[squalou]

No, same thing with or without GTK_USE_PORTAL
(at least on my system, a bit bored at the idea of trying all of them :) )

[vchernin]

Ok, so I managed to build Electron's quick start with Electron 14 on Fedora 34. I eventually found a add file button under the network menu in the inspector.

I'll confirm what happens on Fedora KDE...

[vchernin]

Ok so there's definitely an issue with Electron that isn't just to do with this app.

On Fedora 34 KDE even the hello world can't do it. I activate the file picker by opening inspect element and then opening the network tab and clicking the upload file button (up arrow).
(I had to install libgm-devel gtk3-devel on Fedora to get npm to work)

On the same system Firefox and other apps are perfectly fine...

[tristan957]

I appreciate the effort you are putting into this. I am not sure what could be the problem though assuming your environment variable is set correctly.

[vchernin]

I appreciate the effort you are putting into this. I am not sure what could be the problem though assuming your environment variable is set correctly.

So for electron quick start... if I use GTK_USE_PORTAL=1 npm start on Arch then it works. otherwise it doesn't. Same thing on Fedora. So the issue was I wasn't exporting the variable correctly facepalm.

So if you do export GTK_USE_PORTAL=1 and then run npm start it works...

And now for whatever reason I can't get this app (google chat linux) to not work correctly on Fedora 34 KDE. I am a bit unsure what happened there as I have started new terminal sessions and rebooted, and it insists on working despite it not before. It doesn't matter what I do with the variable. I really don't know what has changed but I won't complain.

Edit: What might have caused the above paragraph's confusion is using node from different sources? Above (when Fedora never worked with google chat linux), I had installed nodejs from the Fedora repos. But later (when Fedora always works with google chat linux) I had installed node from nvm...
Oh... I had node 12 on Fedora on 14 on Ubuntu... could that be it?
Nvm, changing that didn't do anything.

Next I'll try the .deb on kubuntu package, maybe in a few hours as I need a new VM then...

[vchernin]

Ok so Kubuntu 21.04 doesn't work for either with electron quick start or google chat linux out of the box. I tried playing with the variable as above and still nothing.

I also tried the latest impish (21.10) kubuntu build and that still didn't work.

I am really at a loss what's wrong with Ubuntu here. For the record I think Fedora and Arch are fine though so that's something (as long as you've passed the variable correctly).

If anyone has any ideas we should really open a bug at launchpad for Ubuntu as hopefully this issue has a workaround or proper fix in Ubuntu.

[squalou]

Note,
I've forcibly set the variable at startup of the app. (in index.js), it should work, in the sense electron process should consider the variable to be set before anything else is initialized.

"Works for me" but I'm honestly I'm never sure.

On the other hand it may add perturbations when doing tests.

[vchernin]

I’ve opened: electron/electron#31258 for the remaining issues which are likely in Electron.