Hey all,
First, I'll apologize for my disappearing -- I've been crazy busy, but I hope that it will start to be getting better. I've not read through most of the Inkscape lists, and there seems to be some discussion on extensions, I'm going to try to hit everything I remember in one mega e-mail.
-- It seems that there are problems loading the GIMP gradient plugin. Who is getting those? Is there a consistent set? Is this related to people who are/aren't compiling in the bin relocate code? I'm sure the extensions stuff isn't thread safe. This worries me, as I'd like to move alot more functionality into being plugins in the near future.
-- There seemed to be a few "where are extensions going?" type of e-mails. I guess my 'grand goal' is to have them pretty much everywhere, but in the short term I'd like to get functionality similar to GIMP's filters working. This would involve having a menu item which would cause modifications to the document based on some plugable functionality. I hope this can be done with scripts and plugins, and made to 'just work' for every user of Inkscape. This goal may seem overly ambitious, but there is tons of the infrastructure already in place.
Some solid documentation has been started on this by Bryce. Find it here: (it also explains the terminology that we've been using)
http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/doc/extension_system...
-- Extensions dialog -- I think that this is a really good idea. I'd like to be able to load and unload the extensions from a dialog -- for testing also. If someone could mock up the dialog and take care of all "the GUI stuff" I'd be happy to help with the tying it into the rest of the system part of it. Otherwise, this has lower priority for me to getting effects working happily. One thing that I'd like to see in this dialog is a place to put a textual "Why this extension didn't load" so we can explain missing dependencies to users somewhere.
-- API for extensions, this is still in flux. But, it is something that needs to be figured out. I know at one point we'd discussed using the SVG DOM from the W3C. I don't know how that would work out, or how difficult it would be. Bryce and I outlined some general functions that would be needed for "Command and Control" in the document above, but those ideas are definitely not fleshed out.
-- Now that we're XSLTized -- should we be adding that as an extension type? I could see it working for input/output extensions, perhaps as effects also?
Okay, that is all I can remember right now... tell me more, I should be more responsive now!
--Ted
PS -- If anyone is looking for "bite-sized" extensions task to do over winter break or something similar, ask, I think that I have a few.
Ted Gould wrote:
-- It seems that there are problems loading the GIMP gradient plugin. Who is getting those? Is there a consistent set? Is this related to people who are/aren't compiling in the bin relocate code? I'm sure the extensions stuff isn't thread safe. This worries me, as I'd like to move alot more functionality into being plugins in the near future.
I have had no troubles running the shared object, but compiling/linking seems incredibly hard. For some reason, the link dependencies are cascading into the internals of Inkscape, to the point where it seems that -everything- in Inkscape (and the things it links with) must be made available when linking the object. I have made extensions for other things before (Netscape, Director, Java, etc) and have never seen this linking burden before.
I think that the problem is that we are not linking with interfaces, but actual classes, structs, function, etc. We should be using dependency-free interfaces and hide the actual internals from the extension developer. So I agree with you guys that both extensions and their view into Inkscape should have an API.
-- API for extensions, this is still in flux. But, it is something that needs to be figured out. I know at one point we'd discussed using the SVG DOM from the W3C. I don't know how that would work out, or how difficult it would be. Bryce and I outlined some general functions that would be needed for "Command and Control" in the document above, but those ideas are definitely not fleshed out.
If you look in the /src/xpath dir, you will see the .h's that I made to follow the 5 or 6 IDLs from w3.org necessary for the SVG DOM. I have been stalled on this, but am about ready to start working on this again.
-- Now that we're XSLTized -- should we be adding that as an extension type? I could see it working for input/output extensions, perhaps as effects also?
Maybe tomorrow, I will commit the stream stuff which I have been testing. One of the streams is a wrapper for libxslt stuff, hides the implementation, and makes xslt-ing very easy. I was considering adding it to the imports/exports dialogs, but this does seem to be more of an extension thing, as it needs an extra parameter (stylesheet file) selected with a file selector.
Bob
On Sun, 2004-12-19 at 01:33 -0600, Bob Jamison wrote:
Ted Gould wrote:
-- It seems that there are problems loading the GIMP gradient plugin. Who is getting those? Is there a consistent set? Is this related to people who are/aren't compiling in the bin relocate code? I'm sure the extensions stuff isn't thread safe. This worries me, as I'd like to move alot more functionality into being plugins in the near future.
I have had no troubles running the shared object, but compiling/linking seems incredibly hard. For some reason, the link dependencies are cascading into the internals of Inkscape, to the point where it seems that -everything- in Inkscape (and the things it links with) must be made available when linking the object. I have made extensions for other things before (Netscape, Director, Java, etc) and have never seen this linking burden before.
Uhm, yes. I really didn't consider the GIMP gradient plugin 'final' by in stretch of the imagination. I was more looking at it as a proving ground for the idea of having a loadable library, and working out the kinks with that before we got really advanced. It is currently written using the most internal of internal APIs -- that will have to change for any reasonably separate plug-in.
If you look in the /src/xpath dir, you will see the .h's that I made to follow the 5 or 6 IDLs from w3.org necessary for the SVG DOM. I have been stalled on this, but am about ready to start working on this again.
Very cool -- I think this will definitely help the above problem.
-- Now that we're XSLTized -- should we be adding that as an extension type? I could see it working for input/output extensions, perhaps as effects also?
Maybe tomorrow, I will commit the stream stuff which I have been testing. One of the streams is a wrapper for libxslt stuff, hides the implementation, and makes xslt-ing very easy. I was considering adding it to the imports/exports dialogs, but this does seem to be more of an extension thing, as it needs an extra parameter (stylesheet file) selected with a file selector.
Well, I don't think that is a problem. The name of the stylesheet file would be defined in the inx file, which would describe what it does also. Perhaps writing another extension that used the settings dialog to take a variable XSLT file would be good also, but most users don't care that they're using XSLT or Perl :)
--Ted
On Sat, 18 Dec 2004, Ted Gould wrote:
-- Extensions dialog -- I think that this is a really good idea. I'd like to be able to load and unload the extensions from a dialog -- for testing also. If someone could mock up the dialog and take care of all "the GUI stuff" I'd be happy to help with the tying it into the rest of the system part of it. Otherwise, this has lower priority for me to getting effects working happily. One thing that I'd like to see in this dialog is a place to put a textual "Why this extension didn't load" so we can explain missing dependencies to users somewhere.
What sorts of widgets do you think it should have?
Bryce
On Sat, 2004-12-18 at 23:50 -0800, Bryce Harrington wrote:
On Sat, 18 Dec 2004, Ted Gould wrote:
-- Extensions dialog -- I think that this is a really good idea. I'd like to be able to load and unload the extensions from a dialog -- for testing also. If someone could mock up the dialog and take care of all "the GUI stuff" I'd be happy to help with the tying it into the rest of the system part of it. Otherwise, this has lower priority for me to getting effects working happily. One thing that I'd like to see in this dialog is a place to put a textual "Why this extension didn't load" so we can explain missing dependencies to users somewhere.
What sorts of widgets do you think it should have?
Hmm, not entirely sure. I guess when I think about this dialog I always think of something kinda like the XML editor... but I'm not really sure about what it 'should' be.
Here's what I'm thinking:
- This will probably be an "Advanced user" dialog -- I don't think anyone should have to use this as part of their daily routine, only when debugging a problem.
- I see the most common use as finding out why a dependency failed. The second would be to force an extension to unload.
- I would like to be able to display all the information about a given extension. From it's name and ID, to which implementation it is using and what it's current active state is.
- I'm undecided on how people would want to search for an extension. I'm thinking by functionality (Input/Output/Print/Effect/etc) and then by name? Just by name all the way through?
So, if we had an XML editor type interface, here is kinda what I'd think for the left pane:
Loaded Disabled ** Input * AI Input X * GIMP Gradient X * SVG Input X * SVGZ Input ** Output * PS Output X * SVG Output X * SVGZ Output X
Where the 'X' are active check boxes that can load/unload an extension. And, perhaps, if you uncheck the disabled flag it would rerun dependencies to see if things have gotten better (perhaps you installed ghostscript).
When the extension in the left-hand pane is selected, the right hand pane would show all the information on the extension.
I don't know thought -- if someone has other ideas I'm definitely open to them. That is just a brain dump of what I was thinking.
--Ted
Ted Gould wrote:
-- API for extensions, this is still in flux. But, it is something that needs to be figured out. I know at one point we'd discussed using the SVG DOM from the W3C. I don't know how that would work out, or how difficult it would be. Bryce and I outlined some general functions that would be needed for "Command and Control" in the document above, but those ideas are definitely not fleshed out.
I'd say that at a minimum we'd need to expose our DOM. It goes both to being able to use standard scripts to interact (e.g. those that a content author might copy-n-paste from his XHTML/SVG mixed web page), and to animation.
It also would help us to hit the animation needs of SVG Tiny sooner.
participants (4)
-
Bob Jamison -
Bryce Harrington -
Jon A. Cruz -
Ted Gould