bulia byak wrote:
On 4/17/05, bulia byak <buliabyak@...400...> wrote:
On 4/17/05, aaron@...749... <aaron@...749...> wrote:
That's quite impressive. Do these extensions have GUIs of their own? If so can you include one of them into the screenshot as well?
Oh, and by the way, shouldn't we put these extensions into CVS so that they are available to all? Can you send me an archive of all the files? Or do you want to do this when you are finished with them?
Thanks. These effects all use Ted's autogui functionality. Autogui isn't fully functional yet, so I don't know if it should be put in a screenshot.
If you want to put these effects into CVS it is fine by me. I will continue tweaking these and adding more effects as ideas come to me. As long as CVS gets a fresh copy occasionlly, I think it would be great. Here is a direct link to the archive on my website.
http://www.ekips.org/comp/inkscape/inx/inkex_latest.tar.gz
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.
Aaron Spike
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?
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 Sun, 2005-04-17 at 17:14 -0500, aaron@...749... wrote:
Thanks. These effects all use Ted's autogui functionality. Autogui isn't fully functional yet, so I don't know if it should be put in a screenshot.
I think that, with tonight's checkins, that everything should be in the autogui functionality. It now supports the "boolean" and "string" parameters. And both "int" and "float" have attributes for "max" and "min" which will set the spinbuttons appropriately. Also, there is a "gui-text" which allows you to change the text to something a little more friendly.
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.
I think there is enough to start showing off Aaron's effects though, you can change the function in Wavy now :)
--Ted
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!
Ted Gould wrote:
On Sun, 2005-04-17 at 17:14 -0500, aaron@...749... wrote:
Thanks. These effects all use Ted's autogui functionality. Autogui isn't fully functional yet, so I don't know if it should be put in a screenshot.
I think that, with tonight's checkins, that everything should be in the autogui functionality. It now supports the "boolean" and "string" parameters. And both "int" and "float" have attributes for "max" and "min" which will set the spinbuttons appropriately. Also, there is a "gui-text" which allows you to change the text to something a little more friendly.
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.
I think there is enough to start showing off Aaron's effects though, you can change the function in Wavy now :)
Awesome. I can't wait to check this out and flesh out the inx files to match.
Aaron Spike
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
Inkscape Devel List wrote:
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
On Mon, 18 Apr 2005 10:34:09 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
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
Just try to import them, then catch the exception.
I don't have time to add the effects into the autopackage myself. I just keep it running at the moment (and track down various C++ related issues it shows up from time to time). I'm really looking for someone to take it over ;)
bulia byak wrote:
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.
I believe Ted is currently working on this problem. The implementation of the user directories (./inkscape/extensions) is not yet finished. After that is complete there may still be a problem on Windows until the interpreter attribute is added to the inx files.
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.
It will be difficult for me to weed out the appropriate packages since I have everything installed already.
In debian xpath comes from the python-xml package the files are found here for python 2.3: /usr/lib/python2.3/site-packages/_xmlplus/xpath You might look for the package which provides "pyxpath.py"
On Windows things should be a bit more simple. I believe I only needed to install the python package from python.org and PyXML. Though I did have pygame and numeric installed also, I don't think they helped much.
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.
I agree with the "batteries included" approach. Things will be best for all parties if it "just works." Then again stripping it down to the bare essentials might limit what industrius new extension author are able to accomplish. I think someone should see how difficult it is to get them working on windows with a virgin install of python. If it only requires two packages,(as I think it does) it will be pretty simple to do anyway. I would probably consider that easier, since I don't know what is required to package python.
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?
bulia byak wrote:
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.
Good. I thought it might be a bad sign that xpath was in the xmlplus directory.
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?
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.
Aaron Spike
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
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
On Fri, 2005-04-22 at 08:06 -0500, aaron@...749... wrote:
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.
Okay, I'll try to get this done.
--Ted
On Monday 18 Apr 2005 22:48, aaron@...749... wrote:
bulia byak wrote:
- 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;
I was hoping to add "Create slices layer", "Remove Slices layer", "Toggle slices", etc., and perhaps an actual tool that draws slices as opposed to normal rectangles too. For this, a much more sophisticated system would be required, I think: something like exposing the DOM, along with some helper functions and the existing objects defined by tools etc.
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.
* Ability to subclass existing objects
* 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:
- forced colour and transparency (at least, forced in individual objects, but settable on a global basis, or overridable on an individual basis), set during creation of the rectangle
- snapping while moving/scaling: to other slices, to the edge of the page, and perhaps to the edges of underlying objects
- the ability to hide/unhide objects when a tool is selected (so that the slices layer would only appear when you click the slices tool)
* 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.
* Some way of offering extended options for export, that's uniform and appears when expected rather than when a simpler architecture allows.
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 :)
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.
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
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.
On 4/19/05, Jon A. Cruz <jon@...18...> wrote:
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.
btw, is it possible to add a "_" to "Effects" (e.g. "E_ffects") so that this menu was selectable from keyboard at once?
Alexandre
participants (9)
-
unknown＠example.com -
aaron＠...749... -
Alexandre Prokoudine -
bulia byak -
Inkscape Devel List -
Jon A. Cruz -
Lee Braiden -
Mike Hearn -
Ted Gould