Shin guey Wong escribió:
Grant McLean wrote:
On Thu, 2008-04-24 at 01:04 +0200, Martin Vales wrote:
""One of the main differences from glade-2 is that C code generation has 
been removed from glade-3: this has been done on purpose, since using 
generated code is deprecated; the preferred way to use glade files is 
with libglade
The reason they took it out is they learned from experience that it just
doesn't work.  The problem with generated code is that you need to edit
it to implement your app.  But if you then need to go back to Glade to
tweak the user interface then regenerating the code will lose your

They work in C. In ruby it´s very easy build a new implementation. With a gtk on rails we don´t need touch the gui code because gtk on rails will be extensible.

Yup, I got this problem also when I use the code generation from the 
ruby-glade-create-template script. Your code will being overwrite by the 
generated file. Now, I just generate it once and manually add new code 
if I change the glade file. But the only thing I do is add new signal 
function after the glade file being change.
we can create a module for the GUI and other for the callbacks extending the GUI class.
I think can be succesful. .NET work at this way.

Maintaining the source code and the user interface definition in
separate files makes things much easier to maintain.  This is the
classic separation of business logic from presentation.

Now I'm sure you can dream up some system that allows you to regenerate
your source code without losing your edits but when you implement it you
will find it is fragile and hard to maintain.  The Glade developers
learned this already and libglade is the result.

You still haven't said what it is about Glade that you're having trouble
with.  Perhaps if we knew the details of your problem we could suggest a
simpler solution.
Ok. I go:
- Ruby can not ofuscate code. This is not  C or PERL.
- Take a look to gtktreview code:

    @list_store_clientes =,String,Integer,String,String,String,String,String,String,String,String,String)
    renderer =
    column =, renderer,'text' => 1)
    column.resizable = true
    renderer =
    column ="Tipo", renderer,'text' => 2)
    column.resizable = true

      @view_clientes.signal_connect("row-activated") {|wid,path,column|
      if nombre_cliente==column.title then
This is my code. GLADE only configure the VIEW nor the list_store, nor the renderer and columns. I think this can have autogenerate code...

- Combo box in GLADE depends on the text to configue the instance creation: = true)
If you write text in GLADE they put is_text_only = true else false.
Then i need do this fake to work without liststore:
In GLADE i put a value like "..." what i need delete when the application start. Then i can fill the combo reading a SQlite database for example...

How extend GTK with GLADE:
class ExtendedButton extends GtkButton {
// Text for one state of the button.
var $label1 = 'Click Me';
// Text for the other state of the button.
var $label2 = 'Thank You';
public function __construct()
// Call the parent constructor with the first label.
public function changeLabel($button1, $button2)
// Change the label of the button that was pressed.
// Change the label of the other button.

One problem I found with Glade is that it's somewhat tedious to use the
Glade GUI to set up signal handlers.  I have worked around this using a
layer which automatically connects signal handlers based on some simple
conventions ...

Yes. It`´s true

I thought the glade can automatically connect the signal handlers for 
us? We just need to define the signal handler function ourselves(I do 
this in ruby).
I do the same:

    @glade['b_nuevo_cliente'].signal_connect("clicked") {on_b_nuevo_cliente}
    @glade['b_borrar_cliente'].signal_connect("clicked") {on_b_borrar_cliente}
    @glade['b_buscar_cliente'].signal_connect("clicked") {on_buscar_cliente}
    @glade['b_actu_cliente'].signal_connect("clicked") {on_b_actu_cliente}
* in Glade, each widget that needs to handle signals is given a name
  (eg: the search button might be called 'search_btn')

* in my application object I define a method for each signal I want
  handled and use method names that link a named widget and a named
  signal (eg: a method called 'search_btn_activate')

sound interesting.

* when I start the app a code layer walks through the widget tree
  looking for named widgets; for each widget it walks through possible
  signals emitted by that type of widget; for each widget+signal it
  checks to see if the application object implements a handler and if
  so, connects the signal to the method

So in summary, once this is set up, to implement a new signal handler,
all I have to do is implement a method with the right name.

Admittedly, when I have done this, it was in Perl rather than Ruby but
I'm sure the same type of thing is possible: