<div dir="ltr">I think Python shouldn't be a hard dependency... maybe you can make it<br>optional? At least in compile time: use OPTIONAL in CMake and disable<br>the plugin if it's not there. Most Linux distros ship Python, but in<br>Windows or other O.S. it might be a different story. Other than that I<br>like the idea, specially if you integrate it with HotNewStuff :)<br><br>Another important factor for it's inclusion, though, is if you would<br>be willing to maintain the plugin: I don't know much about calling<br>Python from C++ so I won't be able to work on the bug reports, or<br>extend its functionality.<br><br>Albert<br><br>On Wed, Aug 31, 2016 at 11:12 AM, Srivatsan Iyer<br><<a href="mailto:supersaiyanmode.rox@gmail.com">supersaiyanmode.rox@gmail.com</a>> wrote:<br>> Run Command might seem similar but in reality this is a bit different. Run<br>> Command plugin is one of the many things that this proposal allows<br>> implementing. The list below summarizes how this is different from Run<br>> Command Plugin:<br>><br>> 1) With this proposal, we would not execute scripts in a sub-shell. Instead,<br>> we will embed a python interpreter and call specific functions within the<br>> external python package within them main process. (One child process per<br>> plugin may be a lot better; but I haven't been able to implement it).<br>><br>> 2) The scripts can be auto-triggered under specific circumstances (events),<br>> or manually triggered (like Run Command). Only those scripts that listen to<br>> event named "main" will be listed in the Android UI for manual triggering.<br>> All other scripts will be auto-invoked when the paired device creates and<br>> sends events. What functions to call in response to which events -- this<br>> information is found in metadata.json within each python plugin directory.<br>> (I have gone into more details in my previous emails)<br>><br>> 3) I see these external python scripts maintaining states between different<br>> invocations. One example where this is necessary is interacting with the<br>> desktop -- sending notifications and then responding to user response,<br>> watching and responding to various other user activities/events.<br>><br>> 4) Ability to share scripts.<br>><br>><br>><br>><br>> On 31 August 2016 at 03:22, Albert Vaca <<a href="mailto:albertvaka@gmail.com">albertvaka@gmail.com</a>> wrote:<br>>><br>>> How is this different than using the Run Command plugin to trigger a<br>>> Python script?<br>>><br>>> On Tue, Aug 30, 2016 at 1:41 AM, Srivatsan Iyer<br>>> <<a href="mailto:supersaiyanmode.rox@gmail.com">supersaiyanmode.rox@gmail.com</a>> wrote:<br>>>><br>>>> Hello,<br>>>><br>>>> Just checking in to see if the community has a strong opinions on this<br>>>> topic.<br>>>><br>>>> Thanks,<br>>>> Srivatsan<br>>>><br>>>><br>>>> On Aug 18, 2016 8:56 PM, "Srivatsan Iyer" <<a href="mailto:supersaiyanmode.rox@gmail.com">supersaiyanmode.rox@gmail.com</a>><br>>>> wrote:<br>>>>><br>>>>><br>>>>><br>>>>> On Thu, 18 Aug 2016 at 17:23 Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br>>>>>><br>>>>>> On Fri, Aug 19, 2016 at 1:58 AM, Srivatsan Iyer<br>>>>>> <<a href="mailto:supersaiyanmode.rox@gmail.com">supersaiyanmode.rox@gmail.com</a>> wrote:<br>>>>>> > Hi Aleix,<br>>>>>> ><br>>>>>> > Unlock/lock is just a sample. The main idea is to embed python<br>>>>>> > interpreter<br>>>>>> > with custom modules, so that anyone can easily write their own<br>>>>>> > plugins. All<br>>>>>> > it would take is a few lines of python as opposed to a shared object.<br>>>>>> > Further, the Android activity corresponding to this plugin can<br>>>>>> > potentially<br>>>>>> > be made generic enough to dynamically show elements corresponding to<br>>>>>> > each<br>>>>>> > plugin. Currently the ListView gets automatically populated with<br>>>>>> > plugins<br>>>>>> > information (specifically ones that have expressed an intent to<br>>>>>> > listen to<br>>>>>> > "MAIN" event  -- akin to android.intent.action.MAIN).<br>>>>>> ><br>>>>>> > May be providing a different example might help what I'm trying to<br>>>>>> > explain.<br>>>>>> > Assuming the android device is able to listen to an event "battery<br>>>>>> > fully<br>>>>>> > charged", any one can quickly write up a script that listens to that<br>>>>>> > event,<br>>>>>> > and sends a desktop notification to unplug the charger. All you'd<br>>>>>> > need to do<br>>>>>> > is drop the script (and metadata.json) in a specific folder. That's<br>>>>>> > it. No<br>>>>>> > change on the android side at all (assumption of being able to listen<br>>>>>> > to the<br>>>>>> > event still holds but this is just a one time business).<br>>>>>> ><br>>>>>> > Srivatsan<br>>>>>> ><br>>>>>> ><br>>>>>> ><br>>>>>> > On Thu, 18 Aug 2016 at 16:24 Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br>>>>>> >><br>>>>>> >> On Tue, Aug 16, 2016 at 10:50 AM, Srivatsan Iyer<br>>>>>> >> <<a href="mailto:supersaiyanmode.rox@gmail.com">supersaiyanmode.rox@gmail.com</a>> wrote:<br>>>>>> >> > Hello,<br>>>>>> >> ><br>>>>>> >> > I have been writing a kdeconnectd plugin that embeds a python<br>>>>>> >> > interpreter<br>>>>>> >> > allowing scripts to be written to extend functionality. These<br>>>>>> >> > scripts<br>>>>>> >> > can<br>>>>>> >> > respond to android system events (such as phone unlock) or be<br>>>>>> >> > manually<br>>>>>> >> > invoked via the Android App.<br>>>>>> >> ><br>>>>>> >> > There's a bare-bones implementation in my Github repository (links<br>>>>>> >> > below),<br>>>>>> >> > that is able to load two scripts: one that locks the KDE session<br>>>>>> >> > from<br>>>>>> >> > the<br>>>>>> >> > android device, and the other that listens to android device<br>>>>>> >> > unlock<br>>>>>> >> > event<br>>>>>> >> > and also unlocks KDE. (Link to a gif below).<br>>>>>> >> ><br>>>>>> >> > I have a few questions and I'd really appreciate you guys'<br>>>>>> >> > response.<br>>>>>> >> ><br>>>>>> >> > 1) Although I do not see it within the repository here:<br>>>>>> >> > <a href="http://github.com/KDE/kdeconnect-kde">github.com/KDE/kdeconnect-kde</a>, is this something someone else is<br>>>>>> >> > working<br>>>>>> >> > on<br>>>>>> >> > locally? If so, I'd love to collaborate and contribute.<br>>>>>> >> ><br>>>>>> >> > 2) This point is valid provided the plugin sounds like a good<br>>>>>> >> > idea. The<br>>>>>> >> > current implementation is really not that robust and has a lot of<br>>>>>> >> > rough<br>>>>>> >> > edges. I have about 10-15 non-trivial todos before I can even<br>>>>>> >> > think of a<br>>>>>> >> > PR.<br>>>>>> >> > Eventually, this plugin will expose basic desktop functionalities<br>>>>>> >> > of KDE<br>>>>>> >> > (like notifications), and the android device (like other calls,<br>>>>>> >> > texts,<br>>>>>> >> > or<br>>>>>> >> > notification access). Additionally I am also thinking about<br>>>>>> >> > virtualenvs<br>>>>>> >> > and<br>>>>>> >> > ability to install 3rd party packages for these python scripts.<br>>>>>> >> > This,<br>>>>>> >> > surely, is too ambitious for me. But in the short term, I feel I<br>>>>>> >> > am done<br>>>>>> >> > with a basic skeleton and would like others taking a look. What<br>>>>>> >> > would be<br>>>>>> >> > the<br>>>>>> >> > best process? I can surely submit a review at<br>>>>>> >> > <a href="http://git.reviewboard.kde.org">git.reviewboard.kde.org</a>,<br>>>>>> >> > but<br>>>>>> >> > it might take me a few months to fully finish this and submit for<br>>>>>> >> > review. Or<br>>>>>> >> > is it okay submit work that is (somewhat) complete but not ready<br>>>>>> >> > to be<br>>>>>> >> > merged? I am looking for something that allows for a lot of going<br>>>>>> >> > back<br>>>>>> >> > and<br>>>>>> >> > forth.<br>>>>>> >> ><br>>>>>> >> > Links:<br>>>>>> >> > - kdeconnect-kde diff:<br>>>>>> >> ><br>>>>>> >> ><br>>>>>> >> > <a href="https://github.com/KDE/kdeconnect-kde/compare/master...supersaiyanmode:master">https://github.com/KDE/kdeconnect-kde/compare/master...supersaiyanmode:master</a><br>>>>>> >> > - kdeconnect-android diff:<br>>>>>> >> ><br>>>>>> >> ><br>>>>>> >> > <a href="https://github.com/KDE/kdeconnect-android/compare/master...supersaiyanmode:master">https://github.com/KDE/kdeconnect-android/compare/master...supersaiyanmode:master</a><br>>>>>> >> > - Remote KDE Unlock demo:<br>>>>>> >> > <a href="https://twitter.com/supersaiyan_9/status/765440342023745536">https://twitter.com/supersaiyan_9/status/765440342023745536</a><br>>>>>> >> ><br>>>>>> >> > Thanks,<br>>>>>> >> > Srivatsan<br>>>>>> >> > --<br>>>>>> >> ><br>>>>>> >> > Srivatsan Iyer<br>>>>>> >><br>>>>>> >> There's already a plugin for un/locking in plugins/lockdevice, we<br>>>>>> >> didn't enable it by default because we don't have UI for Android.<br>>>>>> >> I'd<br>>>>>> >> suggest making your Android patch work with this one, so it's not<br>>>>>> >> duplicated in the KDE side.<br>>>>>> >><br>>>>>> >> HTH,<br>>>>>> >> Aleix<br>>>>>> ><br>>>>>> > --<br>>>>>> ><br>>>>>> > Srivatsan Iyer<br>>>>>><br>>>>>> Hi,<br>>>>>> Sorry, I didn't understand you.<br>>>>>><br>>>>>> Personally, I'm not interested in having plugins in Python at this<br>>>>>> point, and it would also be a rather big dependency to add. I'd be<br>>>>>> happy to know others' opinions.<br>>>>>><br>>>>>> Aleix<br>>>>><br>>>>><br>>>>> Hi, I totally understand your hesitation to add this dependency. I'd<br>>>>> probably hesitate too. However:<br>>>>><br>>>>> 1) We can put this plugin under experimental section, and continue<br>>>>> development until it matures.<br>>>>><br>>>>> 2) I always wanted to extend KDEConnect with additional features. Most<br>>>>> of the features are tiny but writing independent plugins would be an<br>>>>> overkill. Also, the lazy in me could never find time to sit down to read,<br>>>>> understand, and extend C++/Java code. This would be one solution -- Write up<br>>>>> a few lines of script, drop in a specific folder, and things would just<br>>>>> work. No need of recompiling server or android. It would just work :)<br>>>>><br>>>>> 3) Once this matures, I imagine we can have a little community of<br>>>>> scripts that people might be able to use. (I might be too ambitious but<br>>>>> maybe KDE's "Get Hot New Stuff" :) )<br>>>>><br>>>>> -Srivatsan<br>>>>> --<br>>>>><br>>>>> Srivatsan Iyer<br>>><br>>><br>><br>><br>><br>> --<br>>  - Srivatsan Iyer<br></div>