Thanks Mark,
that list shows some serious thought beyond the often limited views of an Inkscape developer/packager and highlights some of the actual issues that need to be tackled if such a splitting should have a chance to be successful!
@Martin: I have *a lot* of reservations on the technical side (maybe I have some time to describe some of them in detail later), most importantly that the whole process you describe for distribution those extensions *might* work on Linux (but even there seem to be different opinions and I doubt it's possible to evaluate all possible distribution channels), while almost every step will break on Windows (there is no package manager, no reliable pip, no reliable virtualenv, ... not even a reliable Python for that matter, so we usually need to bring our own!) and other platforms might be affected similarly.
I have a feeling it will not make packaging easier but will make it actually a lot harder for many platforms and distribution channels. I'm afraid this will quickly result in extensions being "dead" for those platforms, which will a little slower but eventually lead to extensions being "dead" altogether.
Also copying my thoughts from a while back from a bug on launchpad from https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1735363 (not sure they were considered or even read...)
As a reality check:
Regards,
Eduard
I have been slowly working on all of the third party extensions I can find (with help from Brynn and Maren) to bring them into compatibility with 0.91. As the units changed for 0.92 all the work needed to be done again and I lost energy for a while. I have just moved to a new house and that's also taken up a lot of time this last year.
Nevertheless I do intend to help the authors prepare, as many of these extensions as I can, for useful work in Inkscape.
Many have incorporated my pull requests into their code.
I don't know if the proposed mechanism is the best way or what mechanism might be better but IMHO these are the issues that extensions - in their current mechanism) could do with some help with solving:
1. Stable approach to units - many extensions seem to deal with real world dimensions and care about this.
- probably no issue with the installer mechanism so ignore.
- currently in 0.92 it appears all internal numbers (as seen in the xml editor) are in mm. In 0.48 they were in 90dpi px.
- I am unsure of what 0.93 proposes but currently assuming internal mm as in 0.92.2. Many extensions use the supplied code pieces like simplecurve.py etc
- these need to be stable and when updated make new names and not reuse existing function names
- we need some new ones to inherit such things as drawn dimensions and graphs which have been quite nicely worked out in user side only (not in inkscape repo) extensions. Most useful ones of these make new classes which inherit from inkex.
- At least one of which does not work well anymore in 0.92 due to units change. I will help fix.3. Localisation. Many extension writers have tried to work out how to supply translations and have them work. Currently this is too hard (separate package for each language or script that runs and renames files - too dangerous for Windows etc.
4. Adding their own UI. In the cases where the current inx based UI falls down (conditional values, and many more) the users want to able to use, say, Kivy or even tkinter to do dialogs. This is super hard and only one I know that works is the very recent embroidery extension which needs own installer and is so complex I can't follow it.
5. Python versions - In 0.48 the version of python was quite old - now newer but as pointed out, want to move to 3.x. This means rewrite of all user extensions also. but as print is seldom used, not neccessarily a lot of work for each one. I will help them out. Python 3.7 is in beta now.
- even better would be to allow user to choose the python installed on the machine - so deps like numpy which may already be there don't need to be reinstalled. Instead of bundling a specific version of python with inkscape.
- but keeping 2.7 and 3.x at same time would be even more useful.
- e,g, including the line#!/usr/bin/env python2(orpython3) in any script. See PEP 397 which was included in python 3.3 and works on Windows.
- https://python-forum.io/Thread-Install-Python-2-and-3-on-same-Computer6. There's probably a couple more but I can't recall right now.
FYI - The long term issues not expected to be enabled any time soon are:
- calling internal inkscape functions - I.e. an exposed python API
- getting onto the internal UI.
- interactive control of a parameter while adjusting.
Cheers Mark...
On 3/22/2018 7:11 PM, Martin Owens wrote:
On Thu, 2018-03-22 at 00:15 -0500, Ted Gould wrote:I hate to be stop energy on porting the python extensions to Python 3, that clearly needs to happen. But I don't think we're ready to have them shipping and developed out of a different repository. The distribution issues are critical there. I think that we need a test extension that works well in all the repos/stores/etc before we can split out the extensions that we have.I understand reservations, but I don't agree with your conclusions Ted. I'm suggesting standardization on existing technologies that we're already using. Using well worn and supported formats and existing multi-platform code. I'll have to check all the bits will work, sure, and the good thing about having a separate repository is that it's going to let us be more experimental. As for deps. I'll let you make a snap for every extension contributor ��� ��� It's a bloody minded way of making people do lots of work though. Overall the proposed direction is tentative, I'm fishing for better ideas. It's still the best one so far. Best Regards, Martin Owens ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
One thing we'd need to consider is that some more or less basic Inkscape functionality currently relies on Python extensions, e.g.
- Several templates
- Help links
although I already wondered if this was even really necessary -
I assume there are better solutions available to open a link from GTK
- Export/Import extensions
They are not strictly Inkscape core but a lot of users are not aware
they might be running an extension to export to their favorite format.
Second important questions is if this would only affect packaging or if we really want to split out the extension code from the Inkscape source repository into a more or less self sufficient sub-project.
In the latter case I fear that the bundled extensions - which are in a pretty desolate state even now - might bit-rot even faster (less users, less developers having the repo on their radar, less obvious affiliation with the core program).
If we could achieve to make the extensions into a "community project" (that is a lot more user driven, allowing easy contributions and additions of new extensions with well-organized categorization and documentation) that could also improve upon the status-quo but as a start this would require a "core team" of people who would be willing to do the necessary maintenance (not sure we have that right now...).