Hi Archit! Archit wrote: > > Hi (Paolo and Joaquin mainly :-) > > When I first started hacking on glade3, chema celorio was the > maintainer and he gave me 2 pieces of advice for patches and > their subsequent "cvs commit" > (Note: NOT his exact words) > > 1) The patch should fix something (obviously, which is not > the point here) > and not introduce a new "apparent" bug or break something > like the build. > Always test it. (unless ofcourse IMO its a big patch > and you want to commit it in 2 stages). > > 2) Always send an email with the patch to glade-devel-list > (which this is) > for review before commiting. > > I don't know if Joaquin discussed his last patch but well it > broke the > build (kinda didn't install glade-palette.xml), but I don't > know if he discussed it on the mailing list either? Somehow > its good to have sort of a history of a patch/feature on the > mailing list.
I'm really sorry for having break the build. In general, I agree with Chema'a advice, but now we don't have anymore only one platform, but two. It's not realistic to ask for a test on both platforms before a commit, and we should have to live with some temporary breakage (quite rare, and usually it's quite easy to fix). I've always tried to change the linux build system/code when I did a change, but this time I completely overlooked the Makefile.am. And for the explanation, you're absolutely right, as I only spoke about it with Paolo. There are several changes, but they boil down to two main changes: 1) It makes the order of the catalogs on the palette determined. Before the patch, the order in which the catalogs appeared on the palette was determined by the order in which we find gtk-base.xml & gtk-additional.xml on the directory (not something we can control). While I was at it, I added a little bit more info on the catalogs about the widgets that it should load. Now on the catalog itself we have the name (e.g. GtkWindow), generic name (e.g. window), filename (e.g. gtkwindow.xml). Only the name is required. That puts the most important info about each widget on the catalog file, so if the widget doesn't need to handle specially any property, we don't need a file for this widget at all. 2) It handles the inheritance of widgets. If you have a special property on an abstract widget (let's say "visibility" on GtkWidget), we don't need anymore to repeat the special treatment of this property on each inherited widget. That makes it possible to have a widget without any special property, and yet make it handle "visibility" et al. properties. I've just removed the xml files for the widgets that obviously don't contain anything behind the name & generic name, and created an xml file for gtkseparator, gtkbox, ... That removes ~40 useless xml files. Cheers, ===== Joaquin Cuenca Abela e98cuenc at yahoo dot com __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
