[Glade-devel] CVS commit policy for glade3 module.
- From: bighead users sourceforge net (Archit Baweja)
- Subject: [Glade-devel] CVS commit policy for glade3 module.
- Date: 10 Aug 2003 00:52:24 +0530
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]