Joshua A. Andler wrote:

Bryce Harrington wrote:

...

On Fri, Feb 03, 2006 at 01:26:54PM -0400, bulia byak wrote:

...

Developers,

please find time to browse http://wiki.inkscape.org/wiki/index.php/ReleaseNotes and fill in (or remove) the placeholders. If you don't do it now you will forget the relevant details by the time of the release!

Speaking of release, is it time for us to start thinking about 0.44?

Personally, I don't think it should be discussed quite yet (there are many things that people have started that should be further along before even discussing). Just my .02 at least.

-Josh

Yes, let's wait a bit. I made some considerable progress toward .odg input and output in the last week. It would really be nice to see at least an initial minimal capability in 0.44. A lot of peoples' file format needs might be temporarily met by the workaround of loading into OpenOffice, then using one of its many exports.

Since this will be in DOM, this is forcing me to work on DOM, too.

OT: Speaking of new features.. Now that Python scripts are enabled on Win32 by default, I have a question. Would it be possible in any way to label the extensions on the Effects menu as being Perl or Python, or being enabled or disabled or something, so that people have some idea of the functionality of the extensions on their platform? Is the startup loading of extensions discovering from them somehow if they are functional or not? IMHO, extensions need to be handled in a visually obviously different matter because of this, and also to let the user know that these are beyond the border of "core" Inkscape responsibility. Trying to make them appear to be part of the Inkscape C++ code would be silly, I think, and unscalable.

bob (ishmal)

On Sat, 2006-02-04 at 10:53 -0600, Bob Jamison wrote:

Speaking of new features.. Now that Python scripts are enabled on Win32 by default, I have a question. Would it be possible in any way to label the extensions on the Effects menu as being Perl or Python, or being enabled or disabled or something, so that people have some idea of the functionality of the extensions on their platform? Is the startup loading of extensions discovering from them somehow if they are functional or not? IMHO, extensions need to be handled in a visually obviously different matter because of this, and also to let the user know that these are beyond the border of "core" Inkscape responsibility. Trying to make them appear to be part of the Inkscape C++ code would be silly, I think, and unscalable.

Extensions currently check a list of dependencies on startup, to make sure that they run. This has had some trouble on Windows, but I think that things are getting better... So, the extension should not appear if it doesn't have it's dependencies. (Not the effects menu, or not listed as a filetype for save/open/import)

The goal of an extension dialog (not really done) was to have a way for people to discover why an extension failed to load, or what would be available if they "just installed perl". This is on my todo list, but I'm not sure when I'll get to it. It is still a few entries down.

One of the goals of extensions was to create "first class" extensions, so that you wouldn't know if they were implemented in C++ or any other language. This way developers would be encouraged to move things out of the core, and thus we could have a fast 'kernel' with RAD for other features in other languages.

All that being said, I'm not sure that we've accomplished that, but that's been the stated goal from the start of Inkscape.

--Ted