Re: alternative gmarkup parser

[Paolo Molaro <lupus lettere unipd it>]

On 10/25/00 Havoc Pennington wrote:
> > <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.)

Yep, of course.

> 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>");

Ugh! I didn't want to raise gtkcauldron from the dead:-)
Though that should be possible (and I admit having suggested James
that feature for libglade), I expect (and hope) the support will
be used mostly for loading the xml data from files. As the files
are generated from a program, it's no problem if it's generic
and ugly (since XML is ugly by itself anyway:-), but it's
important it can be loaded quickly and with little custom code.

> > Why not use an array as the implementation in the first place, then?
> 
> Not a bad optimization, I'm just lazy for now. ;-)

I may do it when the code has landed in cvs.

> > 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.

Ok, could you draw the line 3 lines of code below? :-)
I agree with you that we should stop well before code bloat,
but a nice little feature that can be implemented easily with
the existing code base means more flexibility at no cost.
We can state that recursive parsing is not supported, if that
makes you feel better:-)

> 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.

Well, it's you that started this thing:-)
Anyway I would be disappointed in finding expat in glib
(but it would be ok to have a separate library with a GLib
style interface).

lupus

-- 
Paolo Molaro, Open Source Developer, Linuxcare, Inc.
+39.049.8043411 tel, +39.049.8043412 fax
lupus linuxcare com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.