bulia byak wrote:

On 4/17/05, aaron@...749... <aaron@...749...> wrote:

...

There are, however, probably a few reasons to hold off. I haven't figured out how to write an inx file that works on Windows and Linux. So as they are the effects only work on Linux. I'm not sure exactly what is required for the scripts to run, at least Python and PyXML. If extensions are by definition optional, you might not want to include them directly.

So what is the status of extensions on Windows? Does anyone know?

If the problem is only the requirement to have Python, maybe we can ship a Python interpreter with Inkscape windows package?

For more information on using effects under windows read this recent thread. http://sourceforge.net/mailarchive/forum.php?thread_id=7026534&forum_id=... http://sourceforge.net/mailarchive/forum.php?thread_id=7034538&forum_id=...

Ted suggested that the INX files should supply the name of the appropriate interpreter. I think the Extension and Dependency classes need to be made aware of the path in which the associated extension was found. Both of these things probably need to happen before things will be really smooth and crossplatform. This is not to say that extensions built with scripts don't work well on Windows. It all works excellently. It is just a little more work to make Inkscape call a script properly on Windows.

I don't think it should be necessary to ship an interpreter. Python is terribly simple to install on Windows.

Aaron Spike

On 4/18/05, Ted Gould <ted@...11...> wrote:

I believe the remaining autogui work that is left is the "pixel tuning" type of work. I'm not going to focus on that short term, if someone else wants to make it all look a little bit prettier that would be great.

Excellent. I will now test this and report my impressions.

Meanwhile, could you and Aaron please flesh out the Extensions section in

http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes

with a detailed description of your changes. Thanks!

First comments:

- I enabled the Effects menu in preferences.xml and copied the inx and py files from Aaron's tarball into ~/.inkscape/extensions. The new commands are in the menu but don't work. Is this supposed to work? If not why it picks them up for the menu?

- Then I copied them to /usr/local/share/inkscape/extensions/. Now the commands in the menu work, i.e. at least say something in the console. At first I got:

File "/usr/local/share/inkscape/extensions/inkex.py", line 23, in ? import xml.dom.ext ImportError: No module named ext

I installed PyXML. Now I get instead:

File "/usr/local/share/inkscape/extensions/inkex.py", line 25, in ? import xml.xpath ImportError: No module named xpath

What do I need to install now? I see nothing appropriate in the Mandrake repository.

I haven't yet tested on Windows but I still think we must ship Python and all needed Python libs with the Windows package. (Or maybe make two packages, one with extensions and the other without.) This will save a LOT of trouble both to the users and developers. We have a tradition of shipping with "everything included" and it worked out extremely well, so let's stick to that. I think the python interpreter with the minimum of libs can be made quite small.

Alexandre Prokoudine wrote:

On 4/18/05, bulia byak <buliabyak@...400...> wrote:

...

What do I need to install now? I see nothing appropriate in the Mandrake repository.

4Suite?

I don't think so. PyXML should take care of that.

Required python modules: sys, optparse, re, math, copy, cPickle, tempfile, random these are standard modules xml.dom.ext xml.dom.ext.reader.Sax2 there come from PyXML xml.xpath I thought this came with PyXML too but it must not.

I'll check that out.

Aaron Spike

On Mon, 18 Apr 2005 11:14:21 -0300, bulia byak wrote:

I haven't yet tested on Windows but I still think we must ship Python and all needed Python libs with the Windows package.

If somebody wants to add support for these effects to the autopackage version as well, please let me know. We can do dep checking and resolution there, so it'd be nice to have the effects enabled only if Python+PyXML+whatever else is installed.

thanks -mike

Mike Hearn wrote:

On Mon, 18 Apr 2005 11:14:21 -0300, bulia byak wrote:

...

I haven't yet tested on Windows but I still think we must ship Python and all needed Python libs with the Windows package.

If somebody wants to add support for these effects to the autopackage version as well, please let me know. We can do dep checking and resolution there, so it'd be nice to have the effects enabled only if Python+PyXML+whatever else is installed.

We can check for Python in the path with the INX file. (And probably should.) I don't know how to check for a Python module like PyXML. But if it is possible it would be nice to check for the XML::XQL::DOM perl module for dropshadow too. I don't know how to best deal with this. I suggested displaying stderr in a gui window, but this isn't really user freindly, just helpful for script developers.

Aaron Spike

OK, I downloaded and installed PyXML 0.8.4 from python.org and now it works. For some reason Mandrake's PyXML didn't have xpath.

Here are my thoughts on the extensions now that I tried them:

All extensions open a new window for the result. I understand it may be difficult to implement it differently, but it's really clumsy this way. Is the author supposed to close the original and save the new window overwriting the original file? This is a messy and dangerous operation. I think more sensible is to treat the new window as a "preview" and to copy/paste the result from it to the original window, if it is satisfactory. I think that's what most people will do anyway.

So, in order to make this easier:

- if an extension works with selection, the output should contain only that selection with the selection applied and nothing else;

- if the extension creates a new object, it should not copy anything from the original at all, just create a new document with that new object;

- on load, the new document should at least be centered, and ideally zoomed into, the object it has;

- it may also have some sort of text saying "Use copy and paste to move this to the original window".

What do you think?

On Mon, 2005-04-18 at 16:48 -0500, aaron@...749... wrote:

bulia byak wrote:

...

So, in order to make this easier:

• if an extension works with selection, the output should contain only

that selection with the selection applied and nothing else;

• if the extension creates a new object, it should not copy anything

from the original at all, just create a new document with that new object;

• on load, the new document should at least be centered, and ideally

zoomed into, the object it has;

• it may also have some sort of text saying "Use copy and paste to

move this to the original window".

What do you think?

I personally would much rather wait for effects to be implemented properly. By that I mean that they affect the document in the user's window preserving the name and undo, etc. Anything else will be clumsy. I think your suggestion is workable but only temporarily. Implementing it would be too much of a burden both on you inkscape developers and script authors. And in the end I don't think it will make users very happy. I think that time would be better spent learning how to keep the document in the same window. Ted, Bryce or someone else who is aquainted with the code should comment.

I agree with Aaron 100% here. I think that there are a few things to be done before enabling effects (removing it from an obscure option in the preferences)

- Add user extensions. Being able to correctly use ~/.inkscape/extensions to put extensions in.

- Fix the double window, make effects work like all the other entries in the menu. I think this is what we meant when we started with "first class extensions"

- Grouping. There needs to be some way to organize the effects so that they start to collect in submenus, in an orderly fashion. This functionality should also be extended to input/output extensions to make the open/close/import dialogs a little more orderly.

- Fix undo/redo. Currently effects don't work with undo/redo. The effect subsystem should protect these from any extension -- they're very important to end users trying out functionality. If they loose work, they'll forever be scared of the Effects menu.

That's the order that I plan on tackling these in (though undo/redo may end up being second as I start playing with XML). Anyone who'd like to work ahead is welcome :)

--Ted

Lee Braiden wrote:

Off the top of my head, and thinking very long-term (I realise it's a bit of work to implement), I'd want a python scripting interface something like this:

• Probably most important: direct access to the DOM, or better yet, an

object-oriented abstraction of it that, which allows you to use the subclasses in the next points.

Exposing a DOM is the current long-term goal. I'm not sure how much arbitrary subclassing we can facilitate, but we'll do what we can.

• Ability to subclass existing objects

Not sure.

• Ability to subclass and add existing tools, and to define event handlers in

this tool class for only what is needed beyond the default handler. For example, a slice would act very much like a rectangle, except for:

My current thinking is that since we're exposing the SVG as a DOM tree, we can expose the UI through a DOM also. This would allow extension writers to access things in a consistent manner, and have a unified approach.

Much dynamic behavior would be tied into DOM Events.

My current bent is towards following XForms to do this, since it's pretty close to what we want, and uses DOM and DOM Events, etc.

• Ability to add menus, submenus, and menu items, including toggles, mutually

exclusive items, and items that are disabled unless certain conditions are met. For example, I imagine I'd want menu items that are ghosted unless a particular kind of object is selected.

This is exactly the kind of "forms-ish" behavior that XForms is good at.

• Some way of offering extended options for export, that's uniform and appears

when expected rather than when a simpler architecture allows.

Yes. Some of the autogui work extended with an XForms interface should give you exactly this.

With those, you would have a very complete and powerful plugin system, imho. With one more, which requires a more fundamental change to Inkscape, I'd be both very happy, and very optimistic about Inkscape's success:

• Eventually, the ability to define "property panels", such as those in 3DS

Max etc, which scroll and collapse in a side bar. This is probably the most extensible, powerful, and usable plugin interface I know of. It's great for building complex apps with lots of add-ons in a without things getting messy :)

Oooohhhh....

That's much of why I'm doing the Panel/Dockable stuff now. The plugins should only have to define a bare data oriented view, and the plugin system should manage that in a pretty way for the users.

Agreed. I think it would be better to define a good framework, and move toward that slowly, implementing the most crucial features first, rather than

Good. It appears that what you're asking for falls in line with what we're trying to do long term. Among other things, that validates our assessments of what users are going to need.

Once infrastructure is coming together, I'll be able to start gluing some of the work Ishmal, Ted and others are doing together. After that, things will start to become clearer and I think the pace will pick up as they see where this can be taken. So keep an eye out for progress, and keep in the loop so that we can be sure to get the most robust system possible.

Ted Gould wrote:

• Add user extensions. Being able to correctly use

~/.inkscape/extensions to put extensions in.

• Fix the double window, make effects work like all the other entries in

the menu. I think this is what we meant when we started with "first class extensions"

• Grouping. There needs to be some way to organize the effects so that

they start to collect in submenus, in an orderly fashion. This functionality should also be extended to input/output extensions to make the open/close/import dialogs a little more orderly.

• Fix undo/redo. Currently effects don't work with undo/redo. The

effect subsystem should protect these from any extension -- they're very important to end users trying out functionality. If they loose work, they'll forever be scared of the Effects menu.

That's the order that I plan on tackling these in (though undo/redo may end up being second as I start playing with XML). Anyone who'd like to work ahead is welcome :)

Ted or anyone else who is willing-

I would like to make a plea that you rearrange these priorities just slightly. I think the number one priority at the moment should be making interpreted extensions run similarly on Windows and Linux using a single *.inx file.

Adding a property for interpreter and calling scripts by their full path should accomplish this.

In my mind this would make extensions distributable and ready for inclusion in CVS.

Aaron Spike