[Glade-devel] CVS commit policy for glade3 module.

[bighead users sourceforge net (Archit Baweja)]

Hi

Hmm I didn't know one of you was testing it on some other platform besides
linux. :-).

anyways, it seems like a much better design to follow a "inheritence" structure
for the .xml files defining the properties.

curiously enough the gtkwidget.xml seems to be very small? have you commited
the changes yet?

Cheers!
Archit Baweja

Joaquin Cuenca Abela <e98cuenc yahoo com> writes:

> 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  -  Glade-devel lists ximian com
> http://lists.ximian.com/mailman/listinfo/glade-devel