Sorry for the late reply in this, been busy with RL Work. Go figure.
Anyways, as to your inqury, and retraction, I was actually looking into
that, and think I have a way to solve that problem, from my own
when I goto create a GUI with Glade.
Often enough, if I don’t need to use the Widget myself (As in, needing
directly apparent in my application), I usually just let Glade pick the
for it, and leave it at that, where as the controls that I directly want
work with, I specifically give them names, that I can remember to access
within my application. Now looking at it from this view-point, I can
definatly see a way we can work around it, with basically two if
that will keep the memory requirements to a minimum. So that way, it
doesn’t add extra time onto the parsing of the Glade file.
The first “Rule” that it must past, is the base requirements, such as,
a window, is it a dialog, or is it a menu/popup menu/menu item
ofcourse Gtk::Menu::SEPERATOR), if this falls under one of these
for names, it’ll create the method for accessing that control handle, as
variable within the Glade class. Which should be simple enough, cause
if you don’t rename your base controls like Window, Dialog, or Menus,
are things we primarly need access to. Ofcourse, I can always include a
little toggle switch to prevent this kind of evaluation, for both types
scanning, as well as the actual method adding.
The second “Rule” is that will be a bit more strict, is the fact that
get the Control Type for that control, and see if it’s name, matches to
Glade gives it, with a Numeric Value added onto the end. Example of
being, that if you create a window in Glade, it’ll come up with window1,
you add a button, it’ll name it button1, etc, etc, etc. Now, if the
has a similar name to this, and unless it’s expressly directed that all
controls are to be given a method accessor within the Ruby Definition
it’ll by pass these. If there’s a name doesn’t match what the control
is, then it’ll create a method accessor for getting the handle of that
With this, I’ll have to add some Options parsing to
ruby-glade-create-template.rb, in order to make it work as I mentioned,
this will give people the options for either having it, or not having
think these patches wouldn’t be all that hard to put into the parser,
get to ya, if you think these are worth doing? And if I do add Options
Parsing to the parser, then I can add which type of creation they want
use, runtime evaluation definition, or hard code definition as well.
Pass back your thoughts on this Masao, and any suggestions you may have
adding to this as well, cause I’m very well interested in improving such
great tool that you have given us to parse Glade files.
----- Original Message -----
From: “Masao M.” email@example.com
Sent: Tuesday, April 18, 2006 9:17 AM
Subject: Re: [ruby-gnome2-devel-en] New patch for
Glade has definition for ‘mainwin’, instead of having to access it
.:% Masao M.firstname.lastname@example.org
Using Tomcat but need to do more? Need to support web services,
Get stuff done quickly with pre-integrated technology to make your job
Download IBM WebSphere Application Server v.1.0.1 based on Apache