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.
One tool that seems to be aimed at this problem is Movable Python ( http://www.voidspace.org.uk/python/movpy/). Its a python distribution that requires no installation; it doesn't come with pyxml, but adding it wouldn't be difficult. The minimal package, which is the one you'd probably want to use, is 4.0 mb (as compared to 10.4 for the regular win32 python installer). I'm not advocating for or against python's inclusion, but if others want to do that, this is one solution that should be considered. Greg
On 8/29/05, bulia byak <buliabyak@...400...> 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.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
You've said several times "not as convenient as native solutions", what do you mean by this? Performance issues? The goal would be that it shouldn't matter how the feature is implemented. That way more of the codebase can be driven out of the core, making it smaller/faster.
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 think that enabling Effects wouldn't be a bad thing (extensions are already enabled). I think that one thing that we need to do is audit the .inx file format. Probably some thoughts here, now, will pay off. I don't remember who wrote the DTD for it (Aaron?), could you send that back to the list?
I also need to get the menu reorganized, but I can do that the "quick hack" way instead of the "good fix" way if the agreement is that we'd like to get Effects displayed more quickly.
--Ted
On 8/29/05, Ted Gould <ted@...11...> wrote:
You've said several times "not as convenient as native solutions", what do you mean by this? Performance issues?
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.
I think that enabling Effects wouldn't be a bad thing (extensions are already enabled).
Oh, sorry for confusing the terminology again :) Of course I referred to the Python effects.
I also need to get the menu reorganized, but I can do that the "quick hack" way instead of the "good fix" way if the agreement is that we'd like to get Effects displayed more quickly.
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?
bulia byak wrote:
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.
Well, new object types would definitely require DOM, do you think that running the scripts as you change parameters would be useful? I thought it would be too slow. But, I guess my machine is on the lower end of the performance spectrum instead of the higher. Of course, it would have to be configurable for people like me :)
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?
Hmm, probably not. I lost a couple weeks of development this cycle to a new hard drive and Subversion problems. So, I'm behind where I wanted to be :(
--Ted
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
do you think that running the scripts as you change parameters would be useful? I thought it would be too slow.
This is one possibility for those effects that do not require new object types. With scripts it will probably be too slow, but with DOM it might be acceptable.
bulia byak wrote:
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
I was thinking of two things, speed and on canvas handles. It seems that most tools use on canvas handles. I can't imagine calling an entirely external script as a user moves a handle. But yeah, I do agree on the fact that it could be done.
--Ted
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.
Hi, Bulia!
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.
Bob
Bob Jamison wrote:
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".
:)
Aaron Spike
On Mon, 2005-08-29 at 16:56 -0500, aaron@...749... wrote:
Bob Jamison wrote:
<snip />
I just want the DOM stuff to get finished so that I can rewrite everything I've written to be "internal".
Yeah, how far along is this task? That will be major when done...or usable...maybe it is, but there just isn't instructions...Bob, you are doing this right...no pressure, just curious :)
Jon
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.
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.
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. ;)
-Josh
Joshua A. Andler wrote:
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. ;)
Oooh. I always wanted to be a rock star. But I don't think Bulia has enough time to participate in the kind of hand holding necessary to get me through live blends. :)
As long as you brought it up, my node adding and curve dragging patches are both broken in the case of objects with transforms. I started looking for the missing piece of the transform chain this weekend but haven't had time to finish. So if someone just happens to know the magical functions that will fix this, drop me a note. :)
Aaron Spike
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.
--Ted
Ted Gould wrote:
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.
Wow. I guess I never thought something like that could be reality.
Tell me if I've got the wrong idea, but I've been looking forward to internal extensions cause I want extensions to have access to the same sorts of things users have access to in the gui. like boolean ops, simplfy, etc. And having access to some of inkscapes powerful internal path structures would be amazing too.
Aaron Spike
On Tue, 2005-08-30 at 21:38 -0500, aaron@...749... wrote:
Tell me if I've got the wrong idea, but I've been looking forward to internal extensions cause I want extensions to have access to the same sorts of things users have access to in the gui. like boolean ops, simplfy, etc. And having access to some of inkscapes powerful internal path structures would be amazing too.
Well, I think you have the wrong idea :) At least for now.
What DOM will provide first is just an access into the SVG Document Object Model. This is roughly the same as taking the SVG and loading into a DOM based implementation in Python (or any other language). The improvement here will be that the serialize, expand, serialize, expand steps into the different models won't exist like they are today with scripts.
Now, that isn't to say that other internal Inkscape functions won't be available, it is just not something that is available by just having DOM. I think I can say for sure that a script will be able to activate any verb, that's pretty easy and would be an easy to support API. The problem is that when we add more stuff, we have to support it, ideally for a long time. So, I'm sure there will be lots of flames on this list about what should go into the API and what shouldn't, but that hasn't happened yet (and doesn't need to happen yet either).
--Ted
participants (7)
-
unknown＠example.com -
Bob Jamison -
bulia byak -
Greg Steffensen -
Jon Phillips -
Joshua A. Andler -
Ted Gould