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

[e98cuenc yahoo com (Joaquin Cuenca Abela)]

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