Hi Ted,

This is great Mark, thanks for writing it up and working on the units conversations. Do you have a list of the extensions that are out there? In the Wiki or something similar?

On 03/22/2018 02:53 AM, Mark Schafer wrote:

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.

How are the extensions typically finding things like inkex.py and simplecurve.py? AFAIK we're not installing them as Python modules so there are some path issues. Are they hardcoding them?

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.

This is going to be hard, and we're gonna have to handle it in Inkscape with loading a translations directory and looking for them there. This is probably towards the top of my list of hard problems.

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.

I think for us doing any kind of installer this would be tricky. This usually requires some amount of the GUI libraries to be installed and/or bindings compiled. We want extension authors to choose their toolkit, but I'm not sure how we can handle all that choice easily.

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 (or python3) 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-Computer

I'm not sure how we'd make everyone happy here. I think the alternate solution would be to allow every extension to bundle its own version of Python (or use the system python) as the author there wanted. Some people are die hard 2.7 folks, some like the latest and greatest, and that doesn't even include the Perl people :-)

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.

When talking about using the internal Inkscape API, do you know much of what people want there? I'm curious if we're not better of pushing people to using lib2geom than thinking how to make Inkscape into a library. I think that most of the use-cases I've seen could be handled by lib2geom.

Ted