New Plugin: Python extension (and Remote KDE unlock)

Srivatsan Iyer supersaiyanmode.rox at gmail.com
Wed Aug 31 09:12:08 UTC 2016


Run Command might seem similar but in reality this is a bit different. Run
Command plugin is one of the many things that this proposal allows
implementing. The list below summarizes how this is different from Run
Command Plugin:

1) With this proposal, we would not execute scripts in a sub-shell.
Instead, we will embed a python interpreter and call specific functions
within the external python package within them main process. (One child
process per plugin may be a lot better; but I haven't been able to
implement it).

2) The scripts can be auto-triggered under specific circumstances (events),
or manually triggered (like Run Command). Only those scripts that listen to
event named "main" will be listed in the Android UI for manual triggering.
All other scripts will be auto-invoked when the paired device creates and
sends events. What functions to call in response to which events -- this
information is found in metadata.json within each python plugin
directory. (I have gone into more details in my previous emails)

3) I see these external python scripts maintaining states between different
invocations. One example where this is necessary is interacting with the
desktop -- sending notifications and then responding to user response,
watching and responding to various other user activities/events.

4) Ability to share scripts.




On 31 August 2016 at 03:22, Albert Vaca <albertvaka at gmail.com> wrote:

> How is this different than using the Run Command plugin to trigger a
> Python script?
>
> On Tue, Aug 30, 2016 at 1:41 AM, Srivatsan Iyer <
> supersaiyanmode.rox at gmail.com> wrote:
>
>> Hello,
>>
>> Just checking in to see if the community has a strong opinions on this
>> topic.
>>
>> Thanks,
>> Srivatsan
>>
>> On Aug 18, 2016 8:56 PM, "Srivatsan Iyer" <supersaiyanmode.rox at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, 18 Aug 2016 at 17:23 Aleix Pol <aleixpol at kde.org> wrote:
>>>
>>>> On Fri, Aug 19, 2016 at 1:58 AM, Srivatsan Iyer
>>>> <supersaiyanmode.rox at gmail.com> wrote:
>>>> > Hi Aleix,
>>>> >
>>>> > Unlock/lock is just a sample. The main idea is to embed python
>>>> interpreter
>>>> > with custom modules, so that anyone can easily write their own
>>>> plugins. All
>>>> > it would take is a few lines of python as opposed to a shared object.
>>>> > Further, the Android activity corresponding to this plugin can
>>>> potentially
>>>> > be made generic enough to dynamically show elements corresponding to
>>>> each
>>>> > plugin. Currently the ListView gets automatically populated with
>>>> plugins
>>>> > information (specifically ones that have expressed an intent to
>>>> listen to
>>>> > "MAIN" event  -- akin to android.intent.action.MAIN).
>>>> >
>>>> > May be providing a different example might help what I'm trying to
>>>> explain.
>>>> > Assuming the android device is able to listen to an event "battery
>>>> fully
>>>> > charged", any one can quickly write up a script that listens to that
>>>> event,
>>>> > and sends a desktop notification to unplug the charger. All you'd
>>>> need to do
>>>> > is drop the script (and metadata.json) in a specific folder. That's
>>>> it. No
>>>> > change on the android side at all (assumption of being able to listen
>>>> to the
>>>> > event still holds but this is just a one time business).
>>>> >
>>>> > Srivatsan
>>>> >
>>>> >
>>>> >
>>>> > On Thu, 18 Aug 2016 at 16:24 Aleix Pol <aleixpol at kde.org> wrote:
>>>> >>
>>>> >> On Tue, Aug 16, 2016 at 10:50 AM, Srivatsan Iyer
>>>> >> <supersaiyanmode.rox at gmail.com> wrote:
>>>> >> > Hello,
>>>> >> >
>>>> >> > I have been writing a kdeconnectd plugin that embeds a python
>>>> >> > interpreter
>>>> >> > allowing scripts to be written to extend functionality. These
>>>> scripts
>>>> >> > can
>>>> >> > respond to android system events (such as phone unlock) or be
>>>> manually
>>>> >> > invoked via the Android App.
>>>> >> >
>>>> >> > There's a bare-bones implementation in my Github repository (links
>>>> >> > below),
>>>> >> > that is able to load two scripts: one that locks the KDE session
>>>> from
>>>> >> > the
>>>> >> > android device, and the other that listens to android device unlock
>>>> >> > event
>>>> >> > and also unlocks KDE. (Link to a gif below).
>>>> >> >
>>>> >> > I have a few questions and I'd really appreciate you guys'
>>>> response.
>>>> >> >
>>>> >> > 1) Although I do not see it within the repository here:
>>>> >> > github.com/KDE/kdeconnect-kde, is this something someone else is
>>>> working
>>>> >> > on
>>>> >> > locally? If so, I'd love to collaborate and contribute.
>>>> >> >
>>>> >> > 2) This point is valid provided the plugin sounds like a good
>>>> idea. The
>>>> >> > current implementation is really not that robust and has a lot of
>>>> rough
>>>> >> > edges. I have about 10-15 non-trivial todos before I can even
>>>> think of a
>>>> >> > PR.
>>>> >> > Eventually, this plugin will expose basic desktop functionalities
>>>> of KDE
>>>> >> > (like notifications), and the android device (like other calls,
>>>> texts,
>>>> >> > or
>>>> >> > notification access). Additionally I am also thinking about
>>>> virtualenvs
>>>> >> > and
>>>> >> > ability to install 3rd party packages for these python scripts.
>>>> This,
>>>> >> > surely, is too ambitious for me. But in the short term, I feel I
>>>> am done
>>>> >> > with a basic skeleton and would like others taking a look. What
>>>> would be
>>>> >> > the
>>>> >> > best process? I can surely submit a review at
>>>> git.reviewboard.kde.org,
>>>> >> > but
>>>> >> > it might take me a few months to fully finish this and submit for
>>>> >> > review. Or
>>>> >> > is it okay submit work that is (somewhat) complete but not ready
>>>> to be
>>>> >> > merged? I am looking for something that allows for a lot of going
>>>> back
>>>> >> > and
>>>> >> > forth.
>>>> >> >
>>>> >> > Links:
>>>> >> > - kdeconnect-kde diff:
>>>> >> >
>>>> >> > https://github.com/KDE/kdeconnect-kde/compare/master...super
>>>> saiyanmode:master
>>>> >> > - kdeconnect-android diff:
>>>> >> >
>>>> >> > https://github.com/KDE/kdeconnect-android/compare/master...s
>>>> upersaiyanmode:master
>>>> >> > - Remote KDE Unlock demo:
>>>> >> > https://twitter.com/supersaiyan_9/status/765440342023745536
>>>> >> >
>>>> >> > Thanks,
>>>> >> > Srivatsan
>>>> >> > --
>>>> >> >
>>>> >> > Srivatsan Iyer
>>>> >>
>>>> >> There's already a plugin for un/locking in plugins/lockdevice, we
>>>> >> didn't enable it by default because we don't have UI for Android. I'd
>>>> >> suggest making your Android patch work with this one, so it's not
>>>> >> duplicated in the KDE side.
>>>> >>
>>>> >> HTH,
>>>> >> Aleix
>>>> >
>>>> > --
>>>> >
>>>> > Srivatsan Iyer
>>>>
>>>> Hi,
>>>> Sorry, I didn't understand you.
>>>>
>>>> Personally, I'm not interested in having plugins in Python at this
>>>> point, and it would also be a rather big dependency to add. I'd be
>>>> happy to know others' opinions.
>>>>
>>>> Aleix
>>>>
>>>
>>> Hi, I totally understand your hesitation to add this dependency. I'd
>>> probably hesitate too. However:
>>>
>>> 1) We can put this plugin under experimental section, and continue
>>> development until it matures.
>>>
>>> 2) I always wanted to extend KDEConnect with additional features. Most
>>> of the features are tiny but writing independent plugins would be an
>>> overkill. Also, the lazy in me could never find time to sit down to read,
>>> understand, and extend C++/Java code. This would be one solution -- Write
>>> up a few lines of script, drop in a specific folder, and things would just
>>> work. No need of recompiling server or android. It would just work :)
>>>
>>> 3) Once this matures, I imagine we can have a little community of
>>> scripts that people might be able to use. (I might be too ambitious but
>>> maybe KDE's "Get Hot New Stuff" :) )
>>>
>>> -Srivatsan
>>> --
>>>
>>> Srivatsan Iyer
>>>
>>
>


-- 
 - Srivatsan Iyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20160831/d9fa0c01/attachment-0001.html>


More information about the KDEConnect mailing list