New Plugin: Python extension (and Remote KDE unlock)

Wed Aug 31 11:46:46 UTC 2016

I think Python shouldn't be a hard dependency... maybe you can make it
optional? At least in compile time: use OPTIONAL in CMake and disable
the plugin if it's not there. Most Linux distros ship Python, but in
Windows or other O.S. it might be a different story. Other than that I
like the idea, specially if you integrate it with HotNewStuff :)

Another important factor for it's inclusion, though, is if you would
be willing to maintain the plugin: I don't know much about calling
Python from C++ so I won't be able to work on the bug reports, or
extend its functionality.

Albert

On Wed, Aug 31, 2016 at 11:12 AM, Srivatsan Iyer
<supersaiyanmode.rox at gmail.com> wrote:
> 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...supersaiyanmode:master
>>>>> >> > - kdeconnect-android diff:
>>>>> >> >
>>>>> >> >
>>>>> >> >
https://github.com/KDE/kdeconnect-android/compare/master...supersaiyanmode: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/16ad38ac/attachment.html>