Add Telegram plugin
ClosedPublic

Authored by nicolasfella on May 15 2018, 2:42 PM.

Details

Summary

Add a "Share via Telegram plugin". It's a copy of the KDE Connect plugin with name/command substituted. Telegram expects the path without file:// prefix so it is removed when found.

Test Plan

Share from Okular works.
Share from Spectacle does not work since Spectacle does not give an URL but the image data.

Diff Detail

Repository
R495 Purpose Library
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
nicolasfella created this revision.May 15 2018, 2:42 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptMay 15 2018, 2:42 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
nicolasfella requested review of this revision.May 15 2018, 2:42 PM

If it's 99% identical except for the name and command, would it make more sense to create a generic "send to app/service" plugin that you can feed different executables into? Then we could even expose that configuration in the UI somewhere to allow people to easily define their own!

apol added inline comments.May 15 2018, 4:54 PM
src/plugins/telegram/telegramplugin.cpp
54

toUrl().toLocalFile().

Also I would Check if(url.isLocalFile()).

62

Instead of finding the program, we could execute using org.telegram.desktop.desktop, it would allow it to work even if it's installed from appimage/flatpak.

I'm not sure how this would work without bumping the tier.

64

Fix or remove debug message.

  • Use url.toLocalfile()
nicolasfella marked 2 inline comments as done.May 15 2018, 5:33 PM
nicolasfella added inline comments.
src/plugins/telegram/telegramplugin.cpp
62

How would I do that?

Can this even work with Telegram installed as sandboxed Flatpak?

Can this even work with Telegram installed as sandboxed Flatpak?

If we use the desktop file, yes. :)

I've played around with flatpaked Telegram and made it working. However:
My Telegram.desktop file executes this:
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -- @@u %u @@
I can share a file using
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -sendpath @@ /home/nico/test.py @@
But that would require changing the command I get from the desktop file. I can achieve the same goal just by appending something to the command from the desktop file:
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -- @@u %u @@ -sendpath @@ /home/nico/test.py @@
However, appending this to the command does not work with the regular command.
I don't see any way to support all without some special-case handling for flatpak. I didn't even test snap.
Any ideas?

I've played around with flatpaked Telegram and made it working. However:
My Telegram.desktop file executes this:
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -- @@u %u @@
I can share a file using
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -sendpath @@ /home/nico/test.py @@
But that would require changing the command I get from the desktop file. I can achieve the same goal just by appending something to the command from the desktop file:
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -- @@u %u @@ -sendpath @@ /home/nico/test.py @@
However, appending this to the command does not work with the regular command.
I don't see any way to support all without some special-case handling for flatpak. I didn't even test snap.
Any ideas?

Then just read the Exec field and we'll add the sendpath by hand. This is ad-hoc for telegram anyway.

In D12896#266713, @apol wrote:

Then just read the Exec field and we'll add the sendpath by hand. This is ad-hoc for telegram anyway.

I'm not quite sure what to do. Best I came up with is something like

execStr = parseExec()

if (execStr.contains("flatpak"))
    execStr += "-sendpath @@ url @@"
else
    execStr += "-sendpath url"

Is this what you had in mind?

In D12896#266713, @apol wrote:

Then just read the Exec field and we'll add the sendpath by hand. This is ad-hoc for telegram anyway.

I'm not quite sure what to do. Best I came up with is something like

execStr = parseExec()

if (execStr.contains("flatpak"))
    execStr += "-sendpath @@ url @@"
else
    execStr += "-sendpath url"

Is this what you had in mind?

Sure, something along the lines. I'm sure we'll be able to find an elegant solution.

I played around a bit and it turns out more difficult than expected.

  • telegram-desktop-bin from AUR has telegramdesktop.desktop whereas the Flatpak version has org.telegram.desktop.desktop, so we would need to look for at least those desktop files
  • the flatpak command needs @@ around the url, the AUR version not
  • the flatpak command contains "--" which hinders the appending of the -sendpath parameter

This makes parsing the desktop file and building the correct command utterly complex and when we know whether its flatpak or not we know the overall command

My much simpler suggestion would be hardcoding the two commands and try them all until we succeed.
Those would be
telegram-desktop $URL (regular package)
/usr/bin/flatpak run --file-forwarding org.telegram.desktop -sendpath @@ $URL @@ (flatpak)

More commands (e.g. for Snap) could be added, making it more maintainable than complex and error-prone parsing (which would also rely on case-handling and assumptions)

: - Hardcode commands and try until success

apol accepted this revision.May 23 2018, 8:08 PM

Okay, let's land this and I'll try to fix it myself.

This revision is now accepted and ready to land.May 23 2018, 8:08 PM
This revision was automatically updated to reflect the committed changes.