Hi Douglas,
Thanks for the info, I'm passing it along to the list.
One of the differences between Inkscape and commercial applications like Quark and Adobe Illustrator is that many of our extensions come from external contributors, and thus there can be some implementational variability from one to the next. For instance, we allow them to be written in a variety of different scripting languages. This is a strength from the standpoint of allowing us to incorporate a lot of creative new features, but of course also has the weakness that we cannot enforce the same level of standardization that commercial development companies can.
However, we have recognized that we definitely need to work in improving the way extensions work, and are hoping to focus on making them better and easier to add in over the next several months, so your input here is quite relevant, thanks!
Bryce
----- Forwarded message from Douglas Neale <dneale@...936...> -----
Date: Thu, 28 Jul 2005 14:32:45 +0100 From: Douglas Neale <dneale@...936...> To: bryce@...1... Subject: Inkscape
Hi Bryce,
As there isn't a 'suggestions' link on the site and you are top of the 'hero' list, you are getting this email.
First of all, congratulations on what seems to be an awesome product.
I picked up a reference to it this morning on the Adobe forum posting and immediately downloaded it and checked it out under XP. Will do the Mac OSX check tomorrow.
I have a small suggestion for you to pass on (or ignore if you wish) which relates to the discussion on extension architecture. Firstly, let me explain that I write Quark Xtensions and that Quark provide a fairly robust procedure when starting up so that Xtensions are handled properly.
From the perspective of the Xtension code you first try to login with a
unique code (normally the developer ID+ a fourth letter) and if you get back an error code you shut down the Xtension, after displaying an optional error message quoting the error code received.
From the perspective of the user, there is a Xtension Manager item on
the Utilities Menu which lists all Xtensions, loaded or not, which can be individually 'examined' to show some detail of each.
Each Xtension is written in C and compiled as a DLL and is just dropped into the Xtension folder alongside all its fellow Xtensions. Any other installation requirements do not concern Quark and can be handled any way you choose.
Quark supply a header file and a library file of all their internal functions which are visible to the Xtension developer. Needless to say, there are several thousand functions in that library.
Adobe do an almost identical thing, except that their Plugins are written in C++.
I am not advocating that you adopt the Quark/Adobe solution in toto, I am just pointing out that the management of plugins is important and can thus influence the choice of architecture. The clashing of mutually incompatible plugins trying to use the same resources can be a real pain. Regards, Douglas Neale
----- End forwarded message -----
From: Douglas Neale <dneale@...936...>
I am not advocating that you adopt the Quark/Adobe solution in toto, I am just pointing out that the management of plugins is important and can thus influence the choice of architecture. The clashing of mutually incompatible plugins trying to use the same resources can be a real pain.
Douglas,
You can rest assured that we looked at these systems before designing our own -- but our's definitely isn't as mature. For instance, the only ways that you can build extensions for Inkscape is to compile them in or to use an external scripting language. The external scripting language doesn't tie into Inkscape directly, rather it processes an SVG document. We would like to get more powerful with this.
One way that we're doing this is Ishmal is implementing an interface to the SVG DOM in Inkscape. This should be an easily publishable interface that is standard and defined by the SVG specification. At that point we'll start doing loadable libraries as extensions.
Most of the other infrastructure required is already in place, although not tested that much. If you get a chance, I would love if you looked through it -- it would be nice getting some comments from someone who has worked with plug-ins in other programs.
--Ted
On Friday 29 July 2005 00:18, Ted Gould wrote:
One way that we're doing this is Ishmal is implementing an interface to the SVG DOM in Inkscape. This should be an easily publishable interface that is standard and defined by the SVG specification. At that point we'll start doing loadable libraries as extensions.
Are bindings for scripting languages still planned?
On Fri, Jul 29, 2005 at 09:23:18AM +0100, Lee Braiden wrote:
On Friday 29 July 2005 00:18, Ted Gould wrote:
One way that we're doing this is Ishmal is implementing an interface to the SVG DOM in Inkscape. This should be an easily publishable interface that is standard and defined by the SVG specification. At that point we'll start doing loadable libraries as extensions.
Are bindings for scripting languages still planned?
Yes, however this is dependent on the DOM work being in place, so it's probably going to take some time before this is available for use. If you'd like to help work on it, ishmal might have some tasks he could use help with on it.
Bryce
participants (3)
-
Bryce Harrington -
Lee Braiden -
Ted Gould