feat: support logos4 and libronixdls URL schemes #401
Conversation
Open questions: - snap - probably just needs a new .desktop file - flatpak - maybe it's own desktop file - What should be done if registering fails? Fail the entire install? Tested (debian 12 only): - built binary - copied binary into clean VM - installed Logos 40.1 - Launched Logos - Hit "sign in" on Logos wine window - Browser opened a window where I was asked wo "Authorize" Logos Bible Study (I was already signed in) - Accepted the firefox prompt: "Allow this site to open the logos4 link with Logos URL Handler"? - After saying yes, Logos said "Getting ready" and showed first run dialog as it did in 40.0 and below after logging in. - After resources were downloaded went to a website in firefox that has a libronixdls URL (https://house.daviddgtnt.xyz/) and clicked the link - Accepted the firefox prompt: "Allow this site to open the libronixdls link with Logos URL Handler"? - Logos opened Ps 150:6 (which the link showed)! Testing needed: - SteamOS - Manjaro - Alpine (already verified package name online) - Fedora (already verified package name online) - Archlinux (already verified package name online) Fixes: FaithLife-Community#264 FaithLife-Community#400
|
It looks like snap support for this could be tricky (i.e. maybe not possible): https://forum.snapcraft.io/t/allow-snaps-to-register-new-mime-types/6467
It seems like they're the same programming problem, but just with two different MIME Types, right? In both cases they rely on the Ou Dedetai installer to register the relevant MIME Type at the system level so that when the URL is activated in the browser it knows to redirect to the app, right? |
|
After reading some more about this and re-examining this PR, I'm now thinking this will be doable in the snap package. I don't think I see anything that involves registering a new MIME type at a system level, only doing so at the user level. And it looks like the command |
|
Test on Manjaro. In general this works, but I had to click the extra buttons to return to Logos after the install and was not automatically redirected. Otherwise everything went well. Test 2: I deleted I cannot test the URL handler in the browser. But this shouldn't prevent the browser→login panel… |
ou_dedetai/installer.py
Outdated
| filename=url_handler_desktop_filename, | ||
| app_name=f"{flproduct} URL Handler", | ||
| comment="Handles logos4: and libronixdls: URL Schemes", | ||
| exec_cmd=f"{oudedetai_executable} --wine '{app.conf.logos_exe_windows_path}' '%u'", |
There was a problem hiding this comment.
Testing shows the backslashes in the app.conf.logos_exe_window_path need an extra backslash, otherwise the command string is broken on running xdg-open.
For some unknown reason spawning the mime type from within firefox with using the appimage fails to actually launch logos, however if the aforementioned mime type launches a terminal which then spawns logos, the window opens fix works for unknown reasons, perhaps due to permissions in the process tree relating to fuse mounting the appimage. Thankfully the terminal window today only shows up for a second, and then closes. slightly sub-optimal UX, however acceptable considering it actual functions on all configurations Tested: - clean install (using default appimage) on Debian 12 with Firefox ESR 128.13.0 - logged in - the "Download your Logos Library" dialog appeared - on the same system as above, uninstalled logos, pkilled wine and Logos, then re-installed using system wine 10.13 staging on Debian 12 with Firefox ESR 128.13.0 - logged in - the "Download your Logos Library" dialog appeared
3 participants
Open questions:
Tested (debian 12 only):
libronixdls:keylink|ref=[en]bible:Ps150.6)Testing needed:
Fixes: #264 #400