6:38 a.m.
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
2:57 a.m.
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
3:56 a.m.
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 http://colivre.coop.br/Aurium
GNU/Linux User #312507 http://counter.li.org
- - - - - - - - - - - - - - - - - - - - - - - - -
Ilustração Vetorial Livre: http://InkscapeBrasil.org
Coop. de Tecnologias Livres: http://Colivre.coop.br
- - - - - - - - - - - - - - - - - - - - - - - - -
"Eu temo pela minha espécie quando penso
que Deus é justo." Thomas Jefferson
Antes de imprimir esta mensagem reflita
sobre a sua responsabilidade com a
preservação do Meio Ambiente.
6:02 a.m.
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
6:35 a.m.
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).
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
8:10 a.m.
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
10:35 p.m.
> 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.
3:22 a.m.
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);
}
}
4:16 p.m.
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
5:58 p.m.
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
1:05 p.m.
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
4:42 a.m.
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
7:39 a.m.
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.
--
View this message in context:
http://www.nabble.com/extension-namespace-tp20994804p21341497.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
8:19 a.m.
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
10:38 a.m.
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
5252
days inactive
5281
days old
inkscape-devel@lists.inkscape.org
15 comments
7 participants
participants (7)
-
Alexandre Prokoudine -
Alvin Penner -
Aurélio A. Heckert -
bulia byak -
MenTaLguY -
Ted Gould -
Thomas Holder