Bug 342267 - Send files from Android to computer for instant printing.
Summary: Send files from Android to computer for instant printing.
Status: REPORTED
Alias: None
Product: kdeconnect
Classification: Applications
Component: common (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Albert Vaca Cintora
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-28 05:58 UTC by mikevl
Modified: 2015-01-03 06:42 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
perposed dialog 1 (19.72 KB, image/png)
2014-12-31 21:29 UTC, mikevl
Details
Android dialog proposal (28.25 KB, image/png)
2014-12-31 21:34 UTC, mikevl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mikevl 2014-12-28 05:58:00 UTC
Printing from an Android device is currently lacking. But since KDE Connect interfaces with a computer and has its own file transfer protocols, it shouldn't be too difficult to exicute a default application with print command.

For example, if I wanted to print a pdf file from my device to my computer's printer, the file could be transferred to the computer and then okular could be called to print it using this command:
okular --print foo.pdf

Or say a spreadsheet:
libreoffice -p foo.ods

In above examples Libreoffice is preferred as it prints directly, were as Okular only opens the print dialog.

There currently is an Android to Windows app available on Fdroid that accomplishes this. But nothing for a Linux 'print server'. The app is called MobilePrint located at: https://f-droid.org/repository/browse/?fdfilter=print&fdid=com.gs.mobileprint

Reproducible: Always
Comment 1 Albert Vaca Cintora 2014-12-29 03:51:37 UTC
It would be easy to transfer the file and then execute something to print it, the problem is this "something". There is no standard command to print something in Linux, would be nice an "xdg-print" command, like the "print" command in Windows, but there is nothing like that. LibreOffice will only print formats that it can open, and will also add a huge dependency for KDE Connect, so it doesn't seem like a good choice.

I will contact the maintainer of Okular to see if we can find a solution using Okular, but I'm not sure it will be able to print every format, and still we will need to add a way to skip the print dialog (shouldn't be a big deal, though).
Comment 2 mikevl 2014-12-31 19:38:59 UTC
Maybe what is needed is simply some way for the end user to select shell sript that the user creates sending the name and location of the sent file as a parameter.

The would prevent adding any software package as a dependency, and allow user customization to suit their own system.  Users will quickly develope and share their scripts so others can learn how to customize it for themselves.

This could also quickly expand beyond simply printing.  If the user would say have the option to select which script on their computer executes, this could be used for a whole host of applications.
Comment 3 mikevl 2014-12-31 21:29:55 UTC
Created attachment 90186 [details]
perposed dialog 1

Concept of a possible dialog that would allow users to select scripts to be allowed to run from an Android device. Dialog would be opened by clicking on the config button for the new plugin.
Comment 4 mikevl 2014-12-31 21:34:08 UTC
Created attachment 90187 [details]
Android dialog proposal

Proposed modification to the KDE Connect's 'send to' dialog to support the new plugin concept.
Comment 5 mikevl 2014-12-31 21:46:25 UTC
The above two attachments is a mockup of the proposed plugin I'm suggesting.

Thanks for looking into this Albert.  KDE Connect has made integrating Android into my home and work networks so much easier. Hopefully this concept can become a reality without too much work, so we all can benefit from even KDE Connect even more.

Mike
Comment 6 Albert Vaca Cintora 2015-01-03 06:42:31 UTC
After some investigation I found no way to implement the generic printing in Linux. I'm sure there are hackish solutions that could work, but I would prefer to focus on developing other features that can be implemented in a more robust way. I will leave this open, though, in case somebody wants to give it a try.