New Plugin: Python extension (and Remote KDE unlock)

Thu Sep 1 06:55:32 UTC 2016

Hey Albert,

That sounds great! I'll continue pushing to my personal repository on
GitHub, and raise a review request when I am done with a basic skeleton. :-)

See inline for my response to specific concerns you raised.

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

> 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 :)
>
> I started thinking something along the same line when Aleix raised a
similar concern. I'll make sure the plugin gets built if and only if
python-dev package is present. (Most linux distros don't have the
python-dev package, just the binaries.)

> 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.
>

Even I haven't worked with embedded Python before. I have only been playing
around with it for a few weeks. As for maintaining it, sure! I'll be more
than happy..

> 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
>

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