<< August 16, 2008 >>
G_GNUC_CONST considered harmful

some sort of epic plague has set upon gtk, and it's time someone said something about it: why are _get_type() functions declared G_GNUC_CONST?

to wit: GType gtk_entry_get_type (void) G_GNUC_CONST;

glib's own documentation has this to say on the matter:

Likewise, a function that calls a non-const function usually must not be const.

"usually must not" is a little passive-aggressive for api docs, but anyway these _get_type() functions almost all call g_type_register_static_simple, which is not const.

anyway, the problem is if you have code like this:

GTK_TYPE_ENTRY; g_print ("%s\n", g_type_name (g_type_from_name ("GtkEntry")));

it may or may not work, depending on your optimization level. if you ignore the return value of a G_GNUC_CONST function, gcc -O2 will happily optimize it out, as i discovered long ago.

the fix workaround is to pass the return value from the const call into a function that is not declared const; g_type_qname() fits this bill rather nicely.

well, i'm sure they have a good reason.

<< August 16, 2008 >>
another eight weeks

it's taken two months, but my name is finally on the outside of my office. it's not painted on the door, or etched into anyway; just a simple printout. but now maybe people will stop calling me amy.

it's still sort of weird working for a proprietary company. just about nothing i worked on at novell ever got released, or looked at by anyone other than myself, so i didn't think it would be a big change. but at an employee meeting the other day they were recognizing people who'd registered software patents. the juxtaposition between the cheering there and the reaction most of my normal friends have to software patents is quite striking.

<< August 16, 2008 >>
square one

after my previous failure with XPCOM, a helpful person on #content pointed me at XTF. don't let the sparse documentation and lack of examples frighten; in my experience those are signs that you are on the road to glory.

basically, it lets me register an object that gets called when elements with a specific namespace are encountered in a document, and i can create an object that is effective aggregated with that element. since i use namespaces, this is exactly what i have been looking for this whole time. and it looks like it'd be pretty easy to add support for other libraries, if you are interested in some incredibly erotic widgets.

unfortunately, though, this means throwing out just about every line of code i've written since october, and more or less starting anew. the cost of progress, i guess. and anyway, did i really want to maintain my own dom implementation?

anyway, in a night or two i got it creating widgets, and setting their properties (including container child properties) working correctly. i even have an nsIDOMNavigator implementation written in javascript. pretty awesome! anyway, i think the difficult legwork in getting scripts working is done, but there's a little more work there that will have to wait for tomorrow.

i am not quite yet ready to svn rm my old implementation; but that day is fast approaching...