I'd like to revisit the issue of shipping Windows package with their own Python/PyXML. By now I use Aaron's python extensions all the time, they are immensely useful. Not as convenient as native solutions would be, but still a lot of fun and an important part of my design work.

So, what do you think about including a minimum Python/PyXML into the Windows installer and enabling extensions by default? I think the file size increase won't be intolerably big.

No, just that it's not tweakable. You can only undo it and try again. With a native solution, you should be able to tweak parameters interactively, numerically or even by dragging. That requires, in some cases (e.g. blends), creating new object types, while in others, just a dialog with live preview might be sufficient.

By the way, what's the status of verb sensitivity? Do you plan to finish the callbacks to check availability of a menu item before 0.43?

On 8/29/05, Ted Gould <ted@...11...> wrote: >Well, new object types would definitely require DOM No, why? It would require new inkscape: attributes for metadata, new SPSomething class, and probably a new tool. I don't see how DOM can be useful here - via DOM you get approximately the same information as by parsing SVG in a script, except that you get it much faster. Yet a script can still create such an object in an SVG file, if necessary

bulia byak wrote: > I'd like to revisit the issue of shipping Windows package with their > own Python/PyXML. By now I use Aaron's python extensions all the time, > they are immensely useful. Not as convenient as native solutions would > be, but still a lot of fun and an important part of my design work. > The current instructions page for Windows: > > http://wiki.inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking/Windows > > is way too scary for an average user. Python alone might be OK, but > PyXML on top of that is certainly too much. I think very few dedicated > users would venture into this. > > So, what do you think about including a minimum Python/PyXML into the > Windows installer and enabling extensions by default? I think the file > size increase won't be intolerably big. > I've mentioned this before. In our gtk2.8 library bundle, we have complete Python and Perl packages. Currently, we only copy in the Inkscape distro directory the DLL's necessary for Inkscape to run. All we need is for someone to investigate what is necessary to be copied into that directory for perl and python to run correctly. So we have the ability already, but we just have not implemented it. This would be a really cool thing to provide.

I just want the DOM stuff to get finished so that I can rewrite everything I've written to be "internal".

I didn't want to say it, but since it was brought up... Aaron, a real blend tool would totally rock my world (twice even!). With all of your extension work, your recent addition of adding nodes anywhere on a path, and the bezier dragging you're working on... you're well on your way to "Rock Star" status in my book. ;)

bulia byak wrote: > On 8/29/05, aaron@...749... <aaron@...749...> wrote: > >> I just want the DOM stuff to get finished so that I can rewrite >> everything I've written to be "internal". > > > Not to say that this isn't needed, but to make e.g. blends truly > internal, much more is needed (new object type, new tool etc). DOM, as > I understand it, will have the same capabilities as external scripts, > except that it will be faster. Well, it is my intention to extend the abilities of extensions when the DOM becomes available. So something like the star tool could be rewritten in Python is someone so desired (don't know why, but in theory). The reason I haven't done that to date is that it would be impractical without the speed of DOM. So, yes, today if we instantly had DOM that would be impossible. But, it is my intention to make that only part of the changes that happen.