Extensions (inx) files
Hi!
I was playing with some extensions recently and started wondering that it would be nice if the extension files (inx) could be made into properly formatted XML documents with their own namespace and an XSD to come with it. This should make creating new ones easier as well as validating them. I should be able to carry out all necessary work but wanted to know if you guys think it is sensible...
Thanks, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Tue, 2008-04-15 at 15:12 +0200, Marcin Floryan wrote:
I was playing with some extensions recently and started wondering that it would be nice if the extension files (inx) could be made into properly formatted XML documents with their own namespace and an XSD to come with it. This should make creating new ones easier as well as validating them. I should be able to carry out all necessary work but wanted to know if you guys think it is sensible...
YES!!! PLEASE!!!
Here is as far as I got with the XSD when I was doing it. It has been sitting on my Desktop taunting me... It should give you a little bit of a head start, but feel free to change it.
I would also love it if someone could set up a "make check" test to verify all the INX files in the build. That way we could be sure that we're not shipping any bad files, but also that we keep the XSD up-to-date.
--Ted
On Tue, Apr 15, 2008 at 04:32:49PM +0000, Ted Gould wrote:
On Tue, 2008-04-15 at 15:12 +0200, Marcin Floryan wrote:
I was playing with some extensions recently and started wondering that it would be nice if the extension files (inx) could be made into properly formatted XML documents with their own namespace and an XSD to come with it. This should make creating new ones easier as well as validating them. I should be able to carry out all necessary work but wanted to know if you guys think it is sensible...
YES!!! PLEASE!!!
Perfect - then I'm on it.
Here is as far as I got with the XSD when I was doing it. It has been sitting on my Desktop taunting me... It should give you a little bit of a head start, but feel free to change it.
OK. Thanks - I have already started on a draft XSD but any other clues much appreciated - in particular how to best handle i18n underscores ;-) Perhaps we should enforce (where it makes sense) to use underscores since I suppose we always want GUI text translatable.
I would also love it if someone could set up a "make check" test to verify all the INX files in the build. That way we could be sure that we're not shipping any bad files, but also that we keep the XSD up-to-date.
If pointed in the right direction I should be able to do that as well. I suppose writing a simple script/app should be simple enough. Perhaps just some python.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Tue, 2008-04-15 at 22:57 +0200, Marcin Floryan wrote:
On Tue, Apr 15, 2008 at 04:32:49PM +0000, Ted Gould wrote:
Here is as far as I got with the XSD when I was doing it. It has been sitting on my Desktop taunting me... It should give you a little bit of a head start, but feel free to change it.
OK. Thanks - I have already started on a draft XSD but any other clues much appreciated - in particular how to best handle i18n underscores ;-) Perhaps we should enforce (where it makes sense) to use underscores since I suppose we always want GUI text translatable.
I think for the specification that is a good idea. I left the ability to use non-underscores in the code incase there were other INX files in the wild that we would want to be backwards compatible with.
I would also love it if someone could set up a "make check" test to verify all the INX files in the build. That way we could be sure that we're not shipping any bad files, but also that we keep the XSD up-to-date.
If pointed in the right direction I should be able to do that as well. I suppose writing a simple script/app should be simple enough. Perhaps just some python.
I will be happy to help point. Tell me when is a good time :)
--Ted
Ted,
Things are funny at times. I have just reached a point where I am slightly confused how the XSD should be written (to define parameters) and so I've looked into your XSD and you seem to have been stuck at the same point :-) There is no neat way to define <param type="int" ..>int</param> <param type="float">float</param> since XSD does not support element typing based on attribute values (fair enough). So either we have some less strict XSD rules (and relay on further validation in code) or we change that element's name to reflect the type as well (I opt for the latter, but wonder what people here think).
PS. I suppose this is why you can have <input type="submit" maxlength="12" ...> in XHTML though logically it does not make sense :-)
On Apr 16, 2008, at 7:17 AM, Marcin Floryan wrote:
Ted,
Things are funny at times. I have just reached a point where I am slightly confused how the XSD should be written (to define parameters) and so I've looked into your XSD and you seem to have been stuck at the same point :-) There is no neat way to define
<param type="int" ..>int</param> <param type="float">float</param> since XSD does not support element typing based on attribute values (fair enough). So either we have some less strict XSD rules (and relay on further validation in code) or we change that element's name to reflect the type as well (I opt for the latter, but wonder what people here think).
You might look at the discussions on the CREATE mailing list, etc, in regards to the colour format spec. They hit the same point and preferred the more explicit element names to be more "xml-ish" and allow for easier validation, etc.
However... if the existing things are to be changed, I'd strongly recommend looking at XForms since that was drafted by a lot of smart people solving very similar problems as we are. In this area, they used a <bind> element to attach an XML Schema type to a node in the data tree. It also has a simple mechanism to specify allowed ranges and conditions for validation of data as the user is entering it.
On Wed, 2008-04-16 at 16:17 +0200, Marcin Floryan wrote:
Things are funny at times. I have just reached a point where I am slightly confused how the XSD should be written (to define parameters) and so I've looked into your XSD and you seem to have been stuck at the same point :-) There is no neat way to define
<param type="int" ..>int</param> <param type="float">float</param> since XSD does not support element typing based on attribute values (fair enough). So either we have some less strict XSD rules (and relay on further validation in code) or we change that element's name to reflect the type as well (I opt for the latter, but wonder what people here think).
Yes, I'm not quite how to do this in XSD, but it seems that it has to be doable. I'd really hate to have to change the XML format just to be able to represent it in XSD. I'm not sure that's a good trade off.
Can some XML expert step up here? :)
--Ted
On Apr 16, 2008, at 10:09 AM, Ted Gould wrote:
Yes, I'm not quite how to do this in XSD, but it seems that it has to be doable. I'd really hate to have to change the XML format just to be able to represent it in XSD. I'm not sure that's a good trade off.
Can some XML expert step up here? :)
AFAIK, that's one of the big negatives people have against XSD, or against taking the dynamic tactic in XML.
:-(
On Wed, Apr 16, 2008 at 2:09 PM, Ted Gould <ted@...11...> wrote:
Yes, I'm not quite how to do this in XSD, but it seems that it has to be doable. I'd really hate to have to change the XML format just to be able to represent it in XSD. I'm not sure that's a good trade off.
Can some XML expert step up here? :)
Just don't use XSD. It's wrong to assume that of all schema languages, this one is in any way special or "official". It's just one of the many, and a quite poor one at that. As for me, I prefer Schematron, where such check would be trivial.
On Wed, 16 Apr 2008 14:41:11 -0300, "bulia byak" <buliabyak@...400...> wrote:
On Wed, Apr 16, 2008 at 2:09 PM, Ted Gould <ted@...11...> wrote:
Yes, I'm not quite how to do this in XSD, but it seems that it has to
be
doable. I'd really hate to have to change the XML format just to be able to represent it in XSD. I'm not sure that's a good trade off.
Can some XML expert step up here? :)
Just don't use XSD. It's wrong to assume that of all schema languages, this one is in any way special or "official". It's just one of the many, and a quite poor one at that. As for me, I prefer Schematron, where such check would be trivial.
To underscore this, my impression was that XSD originally *was* more or less the "official" XML schema language, but it sucked so badly that its official position was eroded. In any case, Schematron and RelaxNG are much better alternatives.
-mental
On Apr 16, 2008, at 10:41 AM, bulia byak wrote:
Just don't use XSD. It's wrong to assume that of all schema languages, this one is in any way special or "official". It's just one of the many, and a quite poor one at that. As for me, I prefer Schematron, where such check would be trivial.
After I headed out I thought of mentioning Schematron. From what I can tell Schematron's official position is as an additional supplement to XML Schema or RelaxNG.
And, yes, this sort of check should be trivial in Schematron. Besides, it has such a cute mascot.
On Wed, 16 Apr 2008 18:54:09 -0700 "Jon A. Cruz" <jon@...18...> wrote:
supplement to XML Schema or RelaxNG.
Emac's nxml mode is a nice RelaxNG aware (validation, autocompletion) XML editing mode. Anyone know of any free open source XML Schema aware editors for Linux?
There's also trang http://www.thaiopensource.com/relaxng/trang-manual.html which will write XML-Schema and DTD from a RelaxNG input, so you could write the inx schema in RelaxNG and generate XML-Schemas for those that want them. trang will also derive the schema from an example XML, makes a good starting point anyway.
Cheers -Terry
On Wed, Apr 16, 2008 at 09:32:37PM -0500, Terry Brown wrote:
Emac's nxml mode is a nice RelaxNG aware (validation, autocompletion) XML editing mode. Anyone know of any free open source XML Schema aware editors for Linux?
I used a pretty nice Java editor http://www.xmloperator.net/ - tested in both Windows and Linux. It needs getting used to at first but is very handy. Once you create a new document definition in XML Operator to use the RNG file for Inkscape extensions it makes creating new .inx files really simple and gives some clues - unfortunately it does not handle <param> well enough so it seems.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Tue, Apr 15, 2008 at 04:32:49PM +0000, Ted Gould wrote:
On Tue, 2008-04-15 at 15:12 +0200, Marcin Floryan wrote:
I was playing with some extensions recently and started wondering that it would be nice if the extension files (inx) could be made into properly formatted XML documents with their own namespace and an XSD to come with it.
YES!!! PLEASE!!!
OK. I have done a bit. Now all the .inx files are proper XML documents and have a namespace and there is schema to validate the files and ... all the current .inx files actually validate against it (I used mono-xmltool to validate but I hope it is good enough a validator). Now perhaps would be a good time to hook some validation into the build process (and into the code?) but that would probably need a small C app (all validators I have at hand now are either in Java or .NET).
The new schema file is attached and any comments are most welcome (I have applied some formatting to it so that it is easier to read than the SVN version).
And finally - thanks guys for introducing me to the beautiful world of RelaxNG! It is simple yet powerful and within a day or so I was able to handle all params and even the notebook pretty easily. -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On 18 Apr 2008, at 13:06, Marcin Floryan wrote:
On Tue, Apr 15, 2008 at 04:32:49PM +0000, Ted Gould wrote:
On Tue, 2008-04-15 at 15:12 +0200, Marcin Floryan wrote:
I was playing with some extensions recently and started wondering that it would be nice if the extension files (inx) could be made into properly formatted XML documents with their own namespace and an XSD to come with it.
YES!!! PLEASE!!!
OK. I have done a bit. Now all the .inx files are proper XML documents and have a namespace and there is schema to validate the files and ... all the current .inx files actually validate against it (I used mono- xmltool to validate but I hope it is good enough a validator). Now perhaps would be a good time to hook some validation into the build process (and into the code?) but that would probably need a small C app (all validators I have at hand now are either in Java or .NET).
The new schema file is attached and any comments are most welcome (I have applied some formatting to it so that it is easier to read than the SVN version).
Very cool! Thanks a lot for your work! I just happened to have a small C++ app lying around that uses libxml2 for RNG validation. Since you asked for something down those lines, I'll attach it to this mail. I don't know, if it is exactly what you are looking for, but I would think that it is certainly a good starting point. If you have questions concerning the app or suggestions on how to make it suitable for the needs of the Inkscape build process, feel free to drop me a line.
Cheers, Hannes
On Fri, Apr 18, 2008 at 03:30:00PM -0300, Hannes Hochreiner wrote:
The new schema file is attached and any comments are most welcome (I have applied some formatting to it so that it is easier to read than the SVN version).
Very cool! Thanks a lot for your work! I just happened to have a small C++ app lying around that uses libxml2 for RNG validation. Since you asked for something down those lines, I'll attach it to this mail. I don't know, if it is exactly what you are looking for, but I would think that it is certainly a good starting point.
Thanks for that - all code samples are always valuable.
If you have questions concerning the app or suggestions on how to make it suitable for the needs of the Inkscape build process, feel free to drop me a line.
It actually seems like we can use xmllint to validate the inx files with the rng schema during the build process.
Unfortunately there seems to be a little problem now with the Inkscape XML parser - since the namespace applied to the root element now causes it to prefix all elements with "extension:" (as per xml/repr-io.cpp:443) and no extensions are loaded (as per extension/system.cpp:393).
Hence the question - since we are already including libxml2 with Inkscape why not use it to handle all XML files. I know I am missing something big here but maybe a short info is possible.
It seems that extensions are, anyway, separated enough that parsing of the .inx files could now be done with libxml2 (I should be able to do it). And then to take it a step further, libxml++ comes to mind - since we are moving anyway in the C++ direction. Could this dependency be introduced then? It would need updated config scripts and an addition to the windows libs (I have no clues about osx).
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Apr 21, 2008, at 8:22 AM, Marcin Floryan wrote:
Unfortunately there seems to be a little problem now with the Inkscape XML parser - since the namespace applied to the root element now causes it to prefix all elements with "extension:" (as per xml/repr-io.cpp:443) and no extensions are loaded (as per extension/system.cpp:393).
Hence the question - since we are already including libxml2 with Inkscape why not use it to handle all XML files. I know I am missing something big here but maybe a short info is possible.
It seems that extensions are, anyway, separated enough that parsing of the .inx files could now be done with libxml2 (I should be able to do it). And then to take it a step further, libxml++ comes to mind - since we are moving anyway in the C++ direction. Could this dependency be introduced then? It would need updated config scripts and an addition to the windows libs (I have no clues about osx).
I believe we are using libxml2 already. So if anything it is our specific parameters and calls to libxml that are an issue, *if* there is any issue.
However... I think that the issue is how the namespace was set. It wasn't quite that the top-level element had the namespace set, but that the top-level element sets the default namespace.
Since the default namespace is being set, it is not surprising that the attributes use that.
On Fri, Apr 18, 2008 at 12:06 PM, Marcin Floryan <mfloryan@...1877...> wrote:
OK. I have done a bit. Now all the .inx files are proper XML documents and have a namespace and there is schema to validate the files and ... all the current .inx files actually validate against it (I used mono-xmltool to validate but I hope it is good enough a validator).
Please don't forget to add a detailed description of all changes to http://wiki.inkscape.org/wiki/index.php/ReleaseNotes047#API_changes. This is an important one because it will break all custom extensions people have created, so it must be documented thoroughly.
On Tue, 2008-04-22 at 20:27 -0400, bulia byak wrote:
On Fri, Apr 18, 2008 at 12:06 PM, Marcin Floryan <mfloryan@...1877...> wrote:
OK. I have done a bit. Now all the .inx files are proper XML documents and have a namespace and there is schema to validate the files and ... all the current .inx files actually validate against it (I used mono-xmltool to validate but I hope it is good enough a validator).
Please don't forget to add a detailed description of all changes to http://wiki.inkscape.org/wiki/index.php/ReleaseNotes047#API_changes. This is an important one because it will break all custom extensions people have created, so it must be documented thoroughly.
I don't think that's the case is it? I think that now we have a default namespace set on the loader it'll take care of that... do you have any files to test this?
--Ted
PS - Yes, it should be in the release notes, I'm more concerned if it is breaking things.
Sure, I have a custom extension which stopped to work recently:
** (inkscape:17489): WARNING **: Extension definition started with <inkscape-extension> instead of extension:inkscape-extension. Extension will not be created.
** (inkscape:17489): WARNING **: Unable to create extension from definition file /home/b/.inkscape/extensions/qwerty.inx.
Just take any inx from before the namespace change and you'll see the same.
On Wed, Apr 23, 2008 at 08:15:51AM -0300, bulia byak wrote:
Sure, I have a custom extension which stopped to work recently:
** (inkscape:17489): WARNING **: Extension definition started with <inkscape-extension> instead of extension:inkscape-extension. Extension will not be created.
** (inkscape:17489): WARNING **: Unable to create extension from definition file /home/b/.inkscape/extensions/qwerty.inx.
Just take any inx from before the namespace change and you'll see the same.
Equally, put the namespace into your extension and it will work again!
But now at least there is a common standard that all can adhere to and that lets you verify if the extension is correctly defined and give ideas what can go into the file. Chances are, if you were able to write your own extension you will be able to fix it straight away.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Wed, Apr 23, 2008 at 10:16 AM, Marcin Floryan <mfloryan@...1877...> wrote:
Equally, put the namespace into your extension and it will work again!
I know that, I was just pointing out that this must be well documented for everyone else :)
On Wed, Apr 23, 2008 at 11:15:32AM -0300, bulia byak wrote:
On Wed, Apr 23, 2008 at 10:16 AM, Marcin Floryan <mfloryan@...1877...> wrote:
Equally, put the namespace into your extension and it will work again!
I know that, I was just pointing out that this must be well documented for everyone else :)
Absolutely - this is exactly why I have started: http://wiki.inkscape.org/wiki/index.php/Extensions
:-) Feel free to contribute.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
Perhaps an error thats displayed that points to this documentation when a non namespaced inx is encountered would be a good idea? The problems not going to be with the people who write their own inxs, its going to be with people who are just using them.
2008/4/23 Marcin Floryan <mfloryan@...1877...>:
On Wed, Apr 23, 2008 at 11:15:32AM -0300, bulia byak wrote:
On Wed, Apr 23, 2008 at 10:16 AM, Marcin Floryan <mfloryan@...1877...>
wrote:
Equally, put the namespace into your extension and it will work
again!
I know that, I was just pointing out that this must be well documented for everyone else :)
Absolutely - this is exactly why I have started: http://wiki.inkscape.org/wiki/index.php/Extensions
:-) Feel free to contribute.
Regards,
Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Apr 23, 2008 at 10:42:22AM -0400, john cliff wrote:
Perhaps an error thats displayed that points to this documentation when a non namespaced inx is encountered would be a good idea? The problems not going to be with the people who write their own inxs, its going to be with people who are just using them.
Thanks. Good point. Added.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Wed, Apr 23, 2008 at 10:34 AM, Marcin Floryan <mfloryan@...1877...> wrote:
Absolutely - this is exactly why I have started: http://wiki.inkscape.org/wiki/index.php/Extensions
That is nice, but more important for end user are release notes:
http://wiki.inkscape.org/wiki/index.php/ReleaseNotes047
which should be filled in with details of all new features
Also, there's now an annoying bug: save any file, try to quit => get warned that "SVG Output Inkscape" "may cause data loss". I guess it's something got broken in the output extensions, can you please look into this.
On Wed, Apr 23, 2008 at 11:07:53AM -0400, bulia byak wrote:
Also, there's now an annoying bug: save any file, try to quit => get warned that "SVG Output Inkscape" "may cause data loss". I guess it's something got broken in the output extensions, can you please look into this.
Right. Sorry, I've overlooked one thing. It is fixed now.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
Aha! I was getting worried about this. I've done "save as" on a bunch of docs and saved tons of copies because of that warning making me paranoid. It literally scared me into 10 copies of one doc so I knew I had explicitly chosen Inkscape SVG and there would be a chance of it being editable again.
-Josh
bulia byak wrote:
Also, there's now an annoying bug: save any file, try to quit => get warned that "SVG Output Inkscape" "may cause data loss". I guess it's something got broken in the output extensions, can you please look into this.
Ah...so I'm not the only paranoid one...
But I didn't save 10 copies of my doc - just reopened it before I closed the original ;)
JF
Josh Andler wrote:
Aha! I was getting worried about this. I've done "save as" on a bunch of docs and saved tons of copies because of that warning making me paranoid. It literally scared me into 10 copies of one doc so I knew I had explicitly chosen Inkscape SVG and there would be a chance of it being editable again.
-Josh
bulia byak wrote:
Also, there's now an annoying bug: save any file, try to quit => get warned that "SVG Output Inkscape" "may cause data loss". I guess it's something got broken in the output extensions, can you please look into this.
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
bulia byak wrote:
** (inkscape:17489): WARNING **: Extension definition started with <inkscape-extension> instead of extension:inkscape-extension. Extension will not be created.
Does this mean that Inkscape requires a certain text (namely "extension:") for the xmlns namespace prefix? I think that would be bad.
Aaron
On Wed, Apr 23, 2008 at 10:55:59AM -0500, Aaron Spike wrote:
bulia byak wrote:
** (inkscape:17489): WARNING **: Extension definition started with <inkscape-extension> instead of extension:inkscape-extension. Extension will not be created.
Does this mean that Inkscape requires a certain text (namely "extension:") for the xmlns namespace prefix? I think that would be bad.
Aaron
Well - no, not in the XML file itself - just the xmlns="..." attribute on the root <inkscape-extension> element is sufficient. If we did xmlns:extension="..." than it would be a different story but with just one namespace in the file setting the default namespace seems to work fine.
The other issue is, that when there is a namespace applied Inkscape XML handler adds the namespace prefix to the element's name - even for the default namespace. Perhaps then the warning is somewhat misleading but I've now added a pointer to the WIKI in that message so I hope this helps.
PS. I am personally not convinced that the way current XML parser works with regards to namespace handling is the most sensible one, but that's another story. Perhaps adding a "local-name" property on the node would be a solution.
-- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Wed, 2008-04-23 at 08:15 -0300, bulia byak wrote:
Sure, I have a custom extension which stopped to work recently:
** (inkscape:17489): WARNING **: Extension definition started with <inkscape-extension> instead of extension:inkscape-extension. Extension will not be created.
** (inkscape:17489): WARNING **: Unable to create extension from definition file /home/b/.inkscape/extensions/qwerty.inx.
Just take any inx from before the namespace change and you'll see the same.
Mental,
I thought putting a default namespace would force this to be the default behavior. Is there a way that we can "force" a namespace if none is specified?
--Ted
Ted Gould wrote:
On Wed, 2008-04-23 at 08:15 -0300, bulia byak wrote:
Sure, I have a custom extension which stopped to work recently:
** (inkscape:17489): WARNING **: Extension definition started with <inkscape-extension> instead ofextension:inkscape-extension. Extension will not be created.
** (inkscape:17489): WARNING **: Unable to create extension from definition file /home/b/.inkscape/extensions/qwerty.inx.
Just take any inx from before the namespace change and you'll see the same.
Mental,
I thought putting a default namespace would force this to be the default behavior. Is there a way that we can "force" a namespace if none is specified?
--Ted
Isn't that what a doctype is for?
On Tue, Apr 22, 2008 at 08:27:19PM -0400, bulia byak wrote:
On Fri, Apr 18, 2008 at 12:06 PM, Marcin Floryan <mfloryan@...1877...> wrote:
OK. I have done a bit. Now all the .inx files are proper XML documents and have a namespace and there is schema to validate the files and ... all the current .inx files actually validate against it (I used mono-xmltool to validate but I hope it is good enough a validator).
Please don't forget to add a detailed description of all changes to http://wiki.inkscape.org/wiki/index.php/ReleaseNotes047#API_changes. This is an important one because it will break all custom extensions people have created, so it must be documented thoroughly.
Sorry Bulia, I've missed this email - you are obviously right and I've added my bit there.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Tue, Apr 15, 2008 at 5:12 PM, Marcin Floryan wrote:
Hi!
I was playing with some extensions recently and started wondering that it would be nice if the extension files (inx) could be made into properly formatted XML documents with their own namespace and an XSD to come with it. This should make creating new ones easier as well as validating them. I should be able to carry out all necessary work but wanted to know if you guys think it is sensible...
One thing I discussed with Ted before is i18n for standalone extension subprojects that will never be part of core Inkscape (like Origami Helper or AnimEasy or Inkscape Map).
Do you think you could handle it as well? Would be really cool.
Alexandre
On Wed, Apr 16, 2008 at 04:11:02PM +0400, Alexandre Prokoudine wrote:
One thing I discussed with Ted before is i18n for standalone extension subprojects that will never be part of core Inkscape (like Origami Helper or AnimEasy or Inkscape Map).
Do you think you could handle it as well? Would be really cool.
You would have to tell me more and I might be able ;-)
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Wed, Apr 16, 2008 at 5:43 PM, Marcin Floryan wrote:
One thing I discussed with Ted before is i18n for standalone extension subprojects that will never be part of core Inkscape (like Origami Helper or AnimEasy or Inkscape Map).
Do you think you could handle it as well? Would be really cool.
You would have to tell me more and I might be able ;-)
Well, there is not much more I can tell you :)
The idea is that any extension that is shipped separately should be easily translatable. Not sure PO files are a solution here :-/
Alexandre
Hi Marcin,
Since you've spent a bit of time working with the extension interface, maybe you can help me with my query:
Is it possible for me to invoke 'save as' from an extension?
In my extension, I would like to be able to turn off all text, then save file as pdf, then turn all text back on again.
Many thanks, Richard
On Wed, Apr 23, 2008 at 02:59:16PM +0100, Richard Henwood wrote:
Is it possible for me to invoke 'save as' from an extension?
In my extension, I would like to be able to turn off all text, then save file as pdf, then turn all text back on again
I suppose the answer is - that depends on the implementation. Most extensions are currently implemented as python scripts - and in that case the interface is rather simple and would not allow to execute Inkscape functionality when an extension is being run. Therefore an 'internal' implementation in C++ would probably be required to achieve this goal (if I understand your question correctly - hope I do).
Ted mentioned something about plugins but I have no idea what infrastructure / implementation was meant there.
I suppose one could think about creating an interface between Inkscape and the running external Extension via a simple messaging system using D-Bus architecture (especially that it already provides binding for Python among others). That would fit neatly with the plans to use D-Bus for Inkscape anyway.
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
Marcin Floryan wrote:
On Wed, Apr 23, 2008 at 02:59:16PM +0100, Richard Henwood wrote:
Is it possible for me to invoke 'save as' from an extension?
In my extension, I would like to be able to turn off all text, then save file as pdf, then turn all text back on again
I suppose the answer is - that depends on the implementation. Most extensions are currently implemented as python scripts - and in that case the interface is rather simple and would not allow to execute Inkscape functionality when an extension is being run. Therefore an 'internal' implementation in C++ would probably be required to achieve this goal (if I understand your question correctly - hope I do).
Ted mentioned something about plugins but I have no idea what infrastructure / implementation was meant there.
I suppose one could think about creating an interface between Inkscape and the running external Extension via a simple messaging system using D-Bus architecture (especially that it already provides binding for Python among others). That would fit neatly with the plans to use D-Bus for Inkscape anyway.
Thanks for your thoughts on this. In my case, the extension is python; so as I thought, it is limited to walking/modifying the xml represenatation of the document.
I have added the namespace link to my inx file but the popularity of my extension suggests that it is not worth spending any more time working on a method to get my desired functionality.
thanks again, r
On Wed, 2008-04-23 at 14:59 +0100, Richard Henwood wrote:
Since you've spent a bit of time working with the extension interface, maybe you can help me with my query:
Is it possible for me to invoke 'save as' from an extension?
In my extension, I would like to be able to turn off all text, then save file as pdf, then turn all text back on again.
Yes. What happens with output extensions is that you can define a "helper extension" which is basically the next extension down the pipeline from you. So you'd define an output extension for your type "pdf no-text" which then uses the helper "pdf".
There is no language restriction here. It could be C++ or Python or any language that supports STDIN and STDOUT (all of them).
--Ted
participants (14)
-
Aaron Spike -
Alexandre Prokoudine -
Bob Jamison -
bulia byak -
Hannes Hochreiner -
john cliff -
Jon A. Cruz -
Josh Andler -
Joshua Facemyer / Impressus Art -
Marcin Floryan -
MenTaLguY -
Richard Henwood -
Ted Gould -
Terry Brown