`but gui` fails to launch GUI on KDE / Fedora

[rocketraman]

Version

0.19.6

Operating System

Linux

Distribution Method

rpm (Linux)

Describe the issue

When running but gui on KDE (Fedora 43) I get the following error:

kf.kio.core: "/usr/share/applications/GitButler.desktop" contains supported protocols but doesn't use %u or %U in its Exec line! This is inconsistent.

And the following logs:

Apr 01 09:15:08 edison kio-fuse[553264]: couldn't create worker: "Unknown protocol 'but'."
Apr 01 09:15:08 edison systemd[2575]: Started app-GitButler@14aaddcfdc3a41869d6b44f0c5aae432.service - GitButler.
Apr 01 09:15:08 edison kioexec[576553]: Protocol Class of url QUrl("but://open?path=/path/to/my/project&t=1775049308432") , isn't ':local', cancelling job.
Apr 01 09:15:08 edison kioexec[576553]: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: App info not found for 'org.kde.kioexec'")
Apr 01 09:15:08 edison kioexec[576553]: couldn't create worker: "Unknown protocol 'but'."

Naiively adding %U to the .desktop file Exec line does not work, results in the following errors in the journal instead:

Apr 01 09:09:03 edison systemd[2575]: Started app-GitButler@bf723d9651fa4d2fafbf2bc5892015ce.service - GitButler.
Apr 01 09:09:03 edison gitbutler-tauri[573243]: Error: "but but://open?path=/path/to/my/project&t=1775048942920" is not a command. Type "but --help" to see all available commands.

OS and DE details:

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
Kernel Version: 6.19.8-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland

How to reproduce (Optional)

On Fedora KDE, do:

but .

Expected behavior (Optional)

GitButler UI opens at the current project.

[slarse]

Hi,

Sorry you ran into this, it's a known issue that but gui (or, as shorthand, but <path>) does not work on Linux at the moment. I've explained the root cause over here: #12847 (comment)

I'm moving this up my priority list and aim to tackle it today or early next week.

[rocketraman]

Thanks for the link. Note there seems to be another related issue as well which I documented above -- even if GitButler.desktop is manually configured in ~/.config/mimeapps.list, the desktop file appears invalid for the purpose:

Manually configured verification:

$ xdg-mime query default x-scheme-handler/but                                                                                                                                                                                   
GitButler.desktop

and then:

$ but .
kf.kio.core: "/usr/share/applications/GitButler.desktop" contains supported protocols but doesn't use %u or %U in its Exec line! This is inconsistent.

$ xdg-open but://open?path=/path/to/my/project&t=1775218064128
kf.kio.core: "/usr/share/applications/GitButler.desktop" contains supported protocols but doesn't use %u or %U in its Exec line! This is inconsistent.

and there is also a popup about but being an unknown protocol.

[slarse]

Note there seems to be another related issue as well which I documented above -- even if GitButler.desktop is manually configured in ~/.config/mimeapps.list, the desktop file appears invalid for the purpose

@rocketraman Thanks for pointing that out. I think KDE is stricter in interpreting the spec for the Exec key. It appears many implementations (including xdg-utils on Arch, which is what I daily drive) just append the URL to the Exec line, but that doesn't appear to be entirely compliant with the spec. The correct format would be to append %u to the desktop entry.

The entry is generated by Tauri, and it doesn't appear as if we have any direct control over the Exec key at present. It's just set to the (potentially quoted) main binary name.

However, for the purpose of fixing but gui, I'd prefer to just sidestep the problem and not rely on a registered scheme handler. At least on Linux systems, it just complicates things. The executable referred to in the Exec (gitbutler-tauri) will be looked up via PATH anyway, so we might as well just call that executable directly with some explicit arguments as opposed to sidestepping through a custom-scheme URL. I think that's a much more robust fix and will be much more reliable across distros than relying on the desktop entry which may or may not be recognized by the user's desktop environment (if they even have a DE as such).

[slarse]

This should be resolved and will be shipped with the next release (already out in nightly). Instead of relying on the roundabout trip through the custom scheme to just end up invoking gitbutler-tauri, but gui now simply invokes gitbutler-tauri directly on Linux.

This is still inferior to how it operates on e.g. macOS as there, it's possible to differentiate between e.g. nightly and release by way of different schemes. That was never possible on Linux as the exec line is gitbutler-tauri regardless. I don't think that's a feature worth putting effort into given that so few users are on nightly.

Note that there's still a bug where if you do a cold start with but gui the GUI may not open in the correct directory. There is a race between the initial navigation to the last opened project and the deep link passed with but gui. Running but gui when the GUI is already running works as expected, though. I'm looking to fix this as well but I don't speak fluent Svelte so I'll need to enlist some aid :)

[rocketraman]

Thank you!

[rocketraman]

Confirmed it works with 0.19.8.