Hi there,
is it possible to make the new namespace for inx files optional? I see no real benefit for the namespace, but it is a real drawback that all previous custom extensions will become invalid (until you add the namespace to the inx files). When we release 0.47 lots of users will be confused and will report bugs for this I guess.
Thomas
On Sat, 2008-12-13 at 22:38 +0100, Thomas Holder wrote:
is it possible to make the new namespace for inx files optional? I see no real benefit for the namespace, but it is a real drawback that all previous custom extensions will become invalid (until you add the namespace to the inx files). When we release 0.47 lots of users will be confused and will report bugs for this I guess.
Not really. Basically by doing this transition once we make things a lot better for the future. I wasn't able to find a way to bring in old files without doing something nasty like string editing them on the fly -- which isn't desirable at all.
I'm not sure how to deal with the confused users though, ideas?
--Ted
On Wed, Jan 7, 2009 at 2:57 PM, Ted Gould <ted@...11...> wrote:
On Sat, 2008-12-13 at 22:38 +0100, Thomas Holder wrote:
is it possible to make the new namespace for inx files optional? I see no real benefit for the namespace, but it is a real drawback that all previous custom extensions will become invalid (until you add the namespace to the inx files). When we release 0.47 lots of users will be confused and will report bugs for this I guess.
Not really. Basically by doing this transition once we make things a lot better for the future. I wasn't able to find a way to bring in old files without doing something nasty like string editing them on the fly -- which isn't desirable at all.
I'm not sure how to deal with the confused users though, ideas?
The Inkscape dump extension loading errors to the stdio. I think it must to show an alert message for each loading error in a gui window for the non tech user know what is happening.
The error alerts must say what file is wrong and why (if that is possible). The missing dependencies must be showed on this alerts too, because today an user may install a extension, that may do not appear in menu and the non tech user has no idea why that happen.
--Ted
Aurélio A. Heckert wrote, On 01/07/09 19:56:
On Wed, Jan 7, 2009 at 2:57 PM, Ted Gould <ted@...11...> wrote:
On Sat, 2008-12-13 at 22:38 +0100, Thomas Holder wrote:
is it possible to make the new namespace for inx files optional? I see no real benefit for the namespace, but it is a real drawback that all previous custom extensions will become invalid (until you add the namespace to the inx files). When we release 0.47 lots of users will be confused and will report bugs for this I guess.
Not really. Basically by doing this transition once we make things a lot better for the future. I wasn't able to find a way to bring in old files without doing something nasty like string editing them on the fly -- which isn't desirable at all.
we could use a function like that to match all tag names:
gboolean match_tagname(const gchar *cstr, const gchar *tagname, const gchar *ns = INKSCAPE_EXTENSION_NS_NC) { gchar *str = (gchar*) cstr; int nslen = strlen(ns); if (!strncmp(str, ns, nslen)) if (str[nslen] == ':') str += nslen + 1; if (*str == '_') str += 1; return strcmp(str, tagname) == 0; }
maybe this is "nasty", but it works (I've tested it) and I would prefer it over broken old extensions.
I'm not sure how to deal with the confused users though, ideas?
The Inkscape dump extension loading errors to the stdio. I think it must to show an alert message for each loading error in a gui window for the non tech user know what is happening.
Most people who I know and who are not computer nerds would not manage to put a namespace attribute into some XML file, even if they would get clear instructions :-) Ok, the number of unexperienced users who ever installed some custom inkscape extension might be small, but why bother them if there are other solutions?
Thomas
On Wed, Jan 7, 2009 at 5:02 PM, Thomas Holder
Most people who I know and who are not computer nerds would not manage to put a namespace attribute into some XML file, even if they would get clear instructions :-) Ok, the number of unexperienced users who ever installed some custom inkscape extension might be small, but why bother them if there are other solutions?
Agreed. This is not a bug that the old inx files have no namespace, it's just previous version format. We must support it, just as we support Sodipodi namespace and even the "duck prion" namespace (which _was_ a bug).
On Wed, 2009-01-07 at 22:02 +0100, Thomas Holder wrote:
Aurélio A. Heckert wrote, On 01/07/09 19:56:
On Wed, Jan 7, 2009 at 2:57 PM, Ted Gould <ted@...11...> wrote:
On Sat, 2008-12-13 at 22:38 +0100, Thomas Holder wrote:
is it possible to make the new namespace for inx files optional? I see no real benefit for the namespace, but it is a real drawback that all previous custom extensions will become invalid (until you add the namespace to the inx files). When we release 0.47 lots of users will be confused and will report bugs for this I guess.
Not really. Basically by doing this transition once we make things a lot better for the future. I wasn't able to find a way to bring in old files without doing something nasty like string editing them on the fly -- which isn't desirable at all.
we could use a function like that to match all tag names:
gboolean match_tagname(const gchar *cstr, const gchar *tagname, const gchar *ns = INKSCAPE_EXTENSION_NS_NC) { gchar *str = (gchar*) cstr; int nslen = strlen(ns); if (!strncmp(str, ns, nslen)) if (str[nslen] == ':') str += nslen + 1; if (*str == '_') str += 1; return strcmp(str, tagname) == 0; }
maybe this is "nasty", but it works (I've tested it) and I would prefer it over broken old extensions.
I think it's nasty, but I'd be willing to go for it. Mental? Do you have any thoughts on this?
--Ted
maybe this is "nasty", but it works (I've tested it) and I would prefer it over broken old extensions.
I think it's nasty, but I'd be willing to go for it. Mental? Do you have any thoughts on this?
as an alternative, we could do the same like with SVG files. There is a "promote_to_svg_namespace" function in xml/repr-io.cpp, so SVG files work fine with and without xmlns attribute.
Thomas Holder wrote, On 01/08/09 14:35:
as an alternative, we could do the same like with SVG files. There is a "promote_to_svg_namespace" function in xml/repr-io.cpp, so SVG files work fine with and without xmlns attribute.
patch applied that promotes the default namespace to all read XML files, not just SVG. What do you think about it? Still nasty?
Thomas
Index: src/xml/repr-io.cpp =================================================================== --- src/xml/repr-io.cpp (revision 20479) +++ src/xml/repr-io.cpp (working copy) @@ -362,16 +362,16 @@
namespace {
-void promote_to_svg_namespace(Node *repr) { +void promote_to_namespace(Node *repr, const gchar *prefix) { if ( repr->type() == Inkscape::XML::ELEMENT_NODE ) { GQuark code = repr->code(); if (!qname_prefix(code).id()) { - gchar *svg_name = g_strconcat("svg:", g_quark_to_string(code), NULL); + gchar *svg_name = g_strconcat(prefix, ":", g_quark_to_string(code), NULL); repr->setCodeUnsafe(g_quark_from_string(svg_name)); g_free(svg_name); } for ( Node *child = sp_repr_children(repr) ; child ; child = sp_repr_next(child) ) { - promote_to_svg_namespace(child); + promote_to_namespace(child, prefix); } } } @@ -416,10 +416,9 @@ if (root != NULL) { /* promote elements of SVG documents that don't use namespaces * into the SVG namespace */ - if ( default_ns && !strcmp(default_ns, SP_SVG_NS_URI) - && !strcmp(root->name(), "svg") ) - { - promote_to_svg_namespace(root); + if ( default_ns && !strchr(root->name(), ':') ) { + const gchar *prefix = sp_xml_ns_uri_prefix(default_ns, NULL); + promote_to_namespace(root, prefix); } }
On Thu, 2009-01-08 at 19:22 +0100, Thomas Holder wrote:
Thomas Holder wrote, On 01/08/09 14:35:
as an alternative, we could do the same like with SVG files. There is a "promote_to_svg_namespace" function in xml/repr-io.cpp, so SVG files work fine with and without xmlns attribute.
patch applied that promotes the default namespace to all read XML files, not just SVG. What do you think about it? Still nasty?
Yes, it's nasty! I'm not necessarily against promotion for specific sorts of XML files, but please don't do this unconditionally for all XML files!
-mental
MenTaLguY wrote, On 01/09/09 08:16:
On Thu, 2009-01-08 at 19:22 +0100, Thomas Holder wrote:
Thomas Holder wrote, On 01/08/09 14:35:
as an alternative, we could do the same like with SVG files. There is a "promote_to_svg_namespace" function in xml/repr-io.cpp, so SVG files work fine with and without xmlns attribute.
patch applied that promotes the default namespace to all read XML files, not just SVG. What do you think about it? Still nasty?
Yes, it's nasty! I'm not necessarily against promotion for specific sorts of XML files, but please don't do this unconditionally for all XML files!
for sure it's not my goal to introduce nasty code. I just tried to give some suggestions how to solve the extension namespace issue.
Thomas
On Thu, 2009-01-08 at 19:22 +0100, Thomas Holder wrote:
Thomas Holder wrote, On 01/08/09 14:35:
as an alternative, we could do the same like with SVG files. There is a "promote_to_svg_namespace" function in xml/repr-io.cpp, so SVG files work fine with and without xmlns attribute.
patch applied that promotes the default namespace to all read XML files, not just SVG. What do you think about it? Still nasty?
Nasty? Yes. Also practical.
Can you go ahead and make the patch for the relevant INX loaders also?
Thanks, Ted
MenTaLguY wrote, On 01/09/09 08:16:
Yes, it's nasty! I'm not necessarily against promotion for specific sorts of XML files, but please don't do this unconditionally for all XML files!
Ted Gould wrote, On 01/10/09 05:05:
Nasty? Yes. Also practical.
Can you go ahead and make the patch for the relevant INX loaders also?
svn revision 20501: promoting default namespace now to SVG and INX files.
Thomas
Aurélio A. Heckert wrote:
The Inkscape dump extension loading errors to the stdio. I think it must to show an alert message for each loading error in a gui window for the non tech user know what is happening.
On Windows there is a file called : C:\Documents and Settings\Alvin Penner\Application Data\Inkscape\extension-errors.log which stores error messages for those extensions that fail because of missing dependencies. Could this same file be used for the namespace failures as well?
Currently I get a DOS exit message when an extension fails for this reason, why not just redirect this exit message to the above file?
P.S. I would not be happy to see any kind of visible message or prompt coming from this type of failure because most of the extensions that fail are things that I don't care about and don't want to be reminded of.
On Wed, 2009-01-07 at 15:56 -0300, Aurélio A. Heckert wrote:
The Inkscape dump extension loading errors to the stdio. I think it must to show an alert message for each loading error in a gui window for the non tech user know what is happening.
The error alerts must say what file is wrong and why (if that is possible). The missing dependencies must be showed on this alerts too, because today an user may install a extension, that may do not appear in menu and the non tech user has no idea why that happen.
We did this initially and everyone hated it. The reality is that almost no one has all the dependencies needed for all the extensions.
I'd like to find the time to finish the extension browser that's half finished in the codebase to be able find these errors. But I haven't enabled it as it's very much a WIP.
--Ted
On Thu, 2009-01-08 at 02:42 +0300, Alexandre Prokoudine wrote:
2009/1/7 Ted Gould wrote:
I'm not sure how to deal with the confused users though, ideas?
Do we even have them?
I'm sure we would if things just started breaking like the external extensions that they had loaded. They'd probably find some forum or something, but it'd be nice to have the nipped in the bud.
--Ted
participants (7)
-
Alexandre Prokoudine -
Alvin Penner -
Aurélio A. Heckert -
bulia byak -
MenTaLguY -
Ted Gould -
Thomas Holder