Good feedback. So here is how I will proceed:
A. Create a Glade class as described in the bug report. It will
attempt to find the glade file, if not specified at instantiation, by:
1. looking for a file of the same name as the module, first an exact
match, then all lower case (if the module name uses mixed case), in
a) the directory specified at instantiation, or the same directory
as the module
b) the directory pointed to by const.GLADEDIR
2. If the file is found, it will attempt to set the toplevel instance
a) performing a get_object call using the toplevel argument, if
b) performing a get_object call using the glade file name, as
specified or calculated.
Note that the get_object will return None if no widget is found
with a matching name. Also, note that get_object is case sensitive,
so "FooBar" and "foobar" would be different widgets in a glade file.
B. I will also use this class to replace Gtk.Builder initialization
code in gramps, both to simplify existing code and to provide a model
for future development.
On Mon, May 11, 2009 at 5:00 AM, Benny Malengier
> 2009/5/8, Gerald Britton <gerald.britton@...>:
>> Re: http://www.gramps-project.org/bugs/view.php?id=2888
> Internet too slow here to check on that.
>> Before I go gung-ho on using this approach, I need feedback on some
>> 1. which is preferred, the Glade class as described above or just a
>> get_glade_file function in Utils.py that does much the same thing?
> I don't like too many layers to do simple things. This does not look
> too though. I guess the class is best due to the get_child_object
>> 2. Should we adopt a naming convention for glade files? If so, I would
>> propose that we require the filenames to be derived from the name of
>> the modules that use them, whenever possible, and that the filetype be
> I would not do this. There is already so much 'rules' to take into
> account, let's only make required those that are really needed. So I
> would suggest we support a naming convention to do things automatic,
> but don't require it. If you rename existing files to support that,
> new additions to gramps will most likely just follow that as one looks
> at how things are done already when contributing code. The border
> cases (reuse of a glade file, ???) can do what is needed.
>> 3. If the answer to question 2 is "yes," should we use the same
>> format? e.g. if the module name is "FooBar.py", should the glade file
>> be "FooBar.glade" (CamelCaps) or just "foobar.glade" (lower case)?
>> Today I see a mix of both styles in the glade files.
> New python file names are all small caps, so glade files should be too
> in my opinion.
>> 4. Should we insist that the default toplevel in a glade file have the
>> same name as the glade file itself? I think that this might make
>> things less confusing and it could be exploited in the Glade class
>> when setting the self.top attribute and no toplevel argument is
> You are the expert of gtkbuilder now, so do the sensible thing.
>> Please have a look at the proof-of-concept modules (attached to bug
>> 2888) and let me know how you feel about the issues above. Also,
>> please add any other issues that occur to you during your review.
>> Gerald Britton
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> Gramps-devel mailing list