New Plugin: Python extension (and Remote KDE unlock)

Albert Vaca albertvaka at gmail.com
Wed Aug 31 07:22:40 UTC 2016


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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20160831/9b8c111d/attachment.html>


More information about the KDEConnect mailing list