Re: alternative gmarkup parser

[Havoc Pennington <hp redhat com>]

Paolo Molaro <lupus lettere unipd it> writes: 
> Uhm, I can't find a reference now, but what I actually find useful is that
> the parser strips the whitespace between tags:
> 	<tag>
> 		<nested>blah </nested>
> 	</tag>
> becomes equivalent to:
> 	<tag><nested>blah </nested></tag>
> 
> Processing is done this way:
> 	start_tag_cb("tag");
> 	text = eat_plain_text();
> 	if (skip_ws_option && is_ws(text))
> 		; /* nothing */
> 	else
> 		text_cb(text);
> 	start_tag_cb("nested");
> 	...
> 
> You get the idea. This is easy to do.
>

This is probably useful, yes.

> <dream>
> Once all (or most) of the things you can do now with a gtk_widgetname*() 
> function could be done setting a GtkArg (uh, sorry, GParam), and Glade
> outputs the corresponding .xml file, libglade will reduce to a couple 
> hundred lines of code and could be included in gtk+.
> </dream>
> 

That's not a bad idea at all. Sadly I don't think we have time for
2.0. :-( But I'd like to see it. (Though it will be the GMarkup XML
subset of course, not full XML.)

You could do cool stuff like:
 gtk_widget_new_from_string ("<widget type=\"GtkLabel\">"
                              "<attribute name=\"text\" value=\"Foo\"/>"
                              "</widget>");

Hmm, I guess if we keep the XML generic to shrink the libglade thing
it isn't so convenient. ;-) Making it more user-friendly you could
imagine much more readable and compact widget-creation in some cases:

 gtk_widget_new_from_string ("<hbox>"
                             "<child pack=\"start\">"
                             "<label text=\"Foo\"/>"
                             "</child>"
                             "<child pack=\"start\">" 
                             "<entry visible=\"no\"/>"
                             "</child>"
                             "</hbox>");
 
> Why not use an array as the implementation in the first place, then?

Not a bad optimization, I'm just lazy for now. ;-)

> > I don't want to support user-added entities, it complicates things and
> > isn't really useful for the purpose GMarkup is intended to
> > serve.
> 
> If we allow only entities without tags it's just a conditional
> after the strcmp()s for the standard entities:
> 
> 	if (context->entity) {
> 		char *text = call_entity_cb(...);
> 		if (text)
> 			g_string_append(str, text)
> 		g_free(text);
> 	} else
> 		error_as_usual().
>

I realize it's pretty simple, I just want to clamp a hard limit on the
feature set and API of this thing - otherwise you eventually mutate
into a full-blown XML parser. For the intended use of GMarkup custom
entities shouldn't be needed.

In reality I don't have very good arguments why we shouldn't just dump
a copy of expat (a small standalone single-file SAX-style parser) into
GLib with suitable G-ified wrappers. It is somewhat larger than
GMarkup, about 6000 lines with semicolons vs. 800.

Havoc