Hey Masao,
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
experince
when I goto create a GUI with Glade.
Often enough, if I don’t need to use the Widget myself (As in, needing
it
directly apparent in my application), I usually just let Glade pick the
name
for it, and leave it at that, where as the controls that I directly want
to
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
clauses,
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,
is it
a window, is it a dialog, or is it a menu/popup menu/menu item
(Excluding
ofcourse Gtk::Menu::SEPERATOR), if this falls under one of these
categories
for names, it’ll create the method for accessing that control handle, as
a
variable within the Glade class. Which should be simple enough, cause
even
if you don’t rename your base controls like Window, Dialog, or Menus,
thoes
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
of
scanning, as well as the actual method adding.
The second “Rule” is that will be a bit more strict, is the fact that
it’ll
get the Control Type for that control, and see if it’s name, matches to
what
Glade gives it, with a Numeric Value added onto the end. Example of
this
being, that if you create a window in Glade, it’ll come up with window1,
if
you add a button, it’ll name it button1, etc, etc, etc. Now, if the
control
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
file,
it’ll by pass these. If there’s a name doesn’t match what the control
type
is, then it’ll create a method accessor for getting the handle of that
control.
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,
and
this will give people the options for either having it, or not having
it. I
think these patches wouldn’t be all that hard to put into the parser,
and
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
to
use, runtime evaluation definition, or hard code definition as well.
Pass back your thoughts on this Masao, and any suggestions you may have
for
adding to this as well, cause I’m very well interested in improving such
a
great tool that you have given us to parse Glade files.
L8ers,
Mario S.
----- Original Message -----
From: “Masao M.” [email protected]
To: [email protected]
Sent: Tuesday, April 18, 2006 9:17 AM
Subject: Re: [ruby-gnome2-devel-en] New patch for
ruby-glade-create-template.rb
Glade has definition for ‘mainwin’, instead of having to access it
end")
.:% Masao M.[email protected]
[email protected]
ruby-gnome2-devel-en List Signup and Options
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642