<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 January 2016 at 04:50, David Narvaez <span dir="ltr"><<a href="mailto:david.narvaez@computer.org" target="_blank">david.narvaez@computer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>> wrote:<br>
> Short answer, not many commits for that, even dedicated maintainer probably<br>
> welcome, no special interest resulting in real coding, and especially,<br>
> organized design.<br>
><br>
> Longer answer require showing more context.<br>
><br>
> I can first mention atmosphere around Python and scripting in general closer<br>
> to the Kexi circles.<br>
><br>
> But I believe since the intent is to have consistent scripting in the<br>
> future, it somehow helps to see some relation to Sheets, being in the same<br>
> class of apps.<br>
><br>
> As some people may know I like Python for its purposes. KDE even started (in<br>
> Calligra) projects such as Kross to support more languages honestly. This<br>
> support was were means for not too deep bindings, not language-specific,<br>
> rather calling methods of objects without much regard to integration with<br>
> data types or language specifics.<br>
><br>
> As a part of general 'cleanup' Kexi 3 removes Kross usage and moves towards<br>
> a single language-solution that happens to be JavaScript, using QtQml. The<br>
> main reason is that sandbox works there and not in Python.[1] By default<br>
> QtQml gives no tiny chance to access filesystem for example or run unwanted<br>
> scripts.<br>
><br>
> There are no declared lovers of JavaScript among us, C++ hackers I think.<br>
> But the specifics of JavaScript is less of a problem than inherent<br>
> insecurity of Python's execution environment. Insecurity would manifest once<br>
> apps that use scripts get popular. The result I'd expect is very much like<br>
> perfect cross-platforms viruses.<br>
> This is possible if scripts are accessible with documents, which is<br>
> assumption of Kexi (files are meant to be user-defined apps) and in the<br>
> future, I believe, also Sheet's documents, if we want competitiveness.<br>
><br>
> For that matter, also ruby and bash and perl, would be all better rejected<br>
> for the same reason.<br>
> Sure, there were ideas of digital signing of scripts but 1. Even tech people<br>
> do not use that (and even for emails) in general, 2. Except for Krita<br>
> "official" builds we're not controlling the deployment process, distros do<br>
> that, and I imagine all sort of critical issues can sooner happen e.g.<br>
> because of mixes responsibility. It seems that distros are able to act more<br>
> "reactionary", not as  "owners" of the software as a product. Which does not<br>
> surprise me and there's nothing to criticize.<br>
><br>
> For Kexi <=2 (no matter what language is picked) scripting is marked as<br>
> having experimental status. I am not sure whether this is the case for<br>
> Sheets too but for Kexi there's because of such honest status we can assume<br>
> there's no disservice to users. With Kexi 3 we have ability to start fresh<br>
> and with knowledge/experience gathered in the past. Also about knowledge<br>
> about the user base.<br>
><br>
> For some other contexts the choice scripting can depend on external<br>
> requirements. Like "industry" standards -- for Krita Python is perceived as<br>
> some kind of standard for extending graphical features. Similar opinion<br>
> applies for Krita itself - generic calligra-wide scripting never have been<br>
> too actively maintained and was Kross is too simple, see [2]. For the<br>
> record, Krita has a proof-of-concept implementation of scripting in a<br>
> separate repo.<br>
><br>
> [1] Google for "Python sandbox" for detailed discussion from Python hackers<br>
> on why this is not possible and dropped idea.<br>
> [2] <a href="https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html</a><br>
<br>
</div></div>Ditching Python because of sandboxing issues makes sense. That being<br>
said, I would use Python to access the file system from my<br>
spreadsheets all the time. I don't really remember what made me to<br>
look into scripting support in Sheets but I vaguely remember something<br>
merging several CSVs into a single spreadsheet.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Yes, data integration is one of the most useful use cases.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In any case, if the current plan is to remove Python support, I guess<br>
I am better off working on removing that instead of fixing it,<br>
correct?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​I give no definitive ​</div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​answer here stating that common organized approach in Calligra is a valuable thing. Especially that resources are always limited and better to have one effort than multiple. Sheets maintainer​ decides for Sheets and it can be assumed that who codes largely decides too. <br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Assuming that removal of unused/unmaintained code will be decided, yes it's better to drop such things from Calligra 3 codebase, than just disabling the build. The code will still sit in the history anyway. After agreement feel free to submit patches to Phabricator Calligra.git repo and/or tasks for Calligra 3.0 Phabricator's project. <br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​PS: I would be interested in understanding how more or less you perform the integration/access​ the filesystem: do you implement routines to read custom file formats or so? I am collecting such information for Kexi 3 scripting features.<br></div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
David E. Narvaez<br>
<div class=""><div class="h5">_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>