Ruby Forum Ruby-Gnome 2 > GTK on rails

Hi all:

After work with GTK in c, c# and ruby APIs i find GTK libraries great,
but i find several problems in real works:

- write code from scratch. It´s the better solution but it´s a slowly
process ($$$$$).
- Use libglade. I find this method very not optimal and incomplete. It´s
relatively quick but it´s not the perfect system.


I was thinking in create a project called gtkonrails to build source
files in c, c# and ruby from YAML files.

This have many advantages:

- In big projects we can mantain the design pattern in a easy way
- We can build new gtk widgets and used it. In GLADE by now this is a
difficult task.
- We can build GUIs not only for complete windows like other
technologies like .NET or the same GLADE. We can hace several YAML files
for a window.
- We can build a .rb source file with the GUI build from a YAML file and
with other rb. files with a class extending the GUI with the signals
inside.
- The YAML files are very easy to understand and write the source code
by hand or from ruby serialization it´s perfect.



This sounds crazy??????
Any ideas??


Example:

---
window1:
- :window
- vbox1:
  - :vbox
  - button1:
    - :button
    - :signals:
      - click
      - activate
    button2:
    - :button
    - :signals:
      - click
      - activate

Martin Vales wrote:
> Hi all:
> 
> After work with GTK in c, c# and ruby APIs i find GTK libraries great,
> but i find several problems in real works:
> 
> - write code from scratch. It´s the better solution but it´s a slowly
> process ($$$$$).
> - Use libglade. I find this method very not optimal and incomplete. It´s
> relatively quick but it´s not the perfect system.
> 

I found that libglade works fine for me. Any specific reason that you 
found libglade is not useful for you?

> 
> I was thinking in create a project called gtkonrails to build source
> files in c, c# and ruby from YAML files.
> 

The YAML files will be very complex. Just have a glance at the glade 
file, if you want more control on the widget, you have to do the similar 
thing as the glade file.

> 
> This sounds crazy??????
> Any ideas??
> 
Well, it would be great if you can do it. But I expect it will require 
'A LOT' of work to be done.

Hi:
> 
> The YAML files will be very complex. Just have a glance at the glade 
> file, if you want more control on the widget, you have to do the similar 
> thing as the glade file.
> 

I see YAML files easy. Much more XML:
http://yaml.org/spec/cvs/current.html
http://www.ibm.com/developerworks/library/x-matters23.html

In older version of GLADE we can generate C source code from the XML 
glade. Nowadays don´t exist a source code autogenerator ??.

GLADE PEOPLE SAY:
""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 (if code generation is needed, this can be provided as 
another tool or plugin, code generation is simply not a part of the 
glade-3 project)""

____________________

A plugin to code generation is very useful.

I see GTK as the skeleton to build interfaces. If your work in C you 
need  GObject to create new widgets, but if we work in ruby, c++ or  c# 
we can create new widgets with classes. In large projects is important. 
Glade does not allow you to create new widgets by programming. With your 
glade you can only work with the original GTK widgets. If we want to 
reuse code for the programs we need new widgets. This is similar to 
philosophy of ruby on rails.

Glade is incomplete. GTK is not designed to glade. Many widgets as 
gtktreeview is not very correct glade.


For little applications GLADE is perfect, but when you works all days 
with GLADE...

Regards.

sorry i mistake.
> I see YAML files easy. Much more ""than"" XML:

On Thu, 2008-04-24 at 01:04 +0200, Martin Vales wrote:
> GLADE PEOPLE SAY:
> ""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
edits.

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.

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 ...

* 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')

* 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:

  http://mail.gnome.org/archives/gtk-perl-list/2006-July/msg00059.html

Regards
Grant

Grant McLean wrote:
> On Thu, 2008-04-24 at 01:04 +0200, Martin Vales wrote:
>> GLADE PEOPLE SAY:
>> ""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
> edits.
> 
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.

> 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.
> 
> 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 ...
> 
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).

> * 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')
> 
> * 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:
> 
>   http://mail.gnome.org/archives/gtk-perl-list/2006-July/msg00059.html
> 
> Regards
> Grant

Shin guey Wong escribió:
>> 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
>> edits.
>>
>>     
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.

>> 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:

    @view_clientes=@glade.get_widget("treeview2")
    @view_clientes.rules_hint=true
    @list_store_clientes =
Gtk::ListStore.new(Integer,String,Integer,String,String,String,String,String,String,String,String,String)
    @view_clientes.model=@list_store_clientes
    renderer = Gtk::CellRendererText.new
    nombre_cliente="Nombre"
    column = Gtk::TreeViewColumn.new(nombre_cliente, renderer,'text' => 
1)
    column.resizable = true
    @view_clientes.append_column(column)
    renderer = Gtk::CellRendererText.new
    column = Gtk::TreeViewColumn.new("Tipo", renderer,'text' => 2)
    column.resizable = true
    @view_clientes.append_column(column)

      @view_clientes.signal_connect("row-activated") {|wid,path,column|
      if nombre_cliente==column.title then
          activacion_cliente_path(path.to_str)
      end
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:
|Gtk::ComboBox.new(is_text_only = true)| 
<http://ruby-gnome2.sourceforge.jp/hiki.cgi?Gtk%3A%3AComboBox#Gtk%3A%3AComboBox.new>
If you write text in GLADE they put||
<http://ruby-gnome2.sourceforge.jp/hiki.cgi?Gtk%3A%3AComboBox#Gtk%3A%3AComboBox.new>
is_text_only = true else false.
Then i need do this fake to work without liststore:
@combo_elipsoide.remove_text(0)
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.
parent::__construct($this->label1);
}
public function changeLabel($button1, $button2)
{
// Change the label of the button that was pressed.
$button1->child->set_text($this->label2);
// Change the label of the other button.
$button2->child->set_text($this->label1);
}
}





>> 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.

Whops, I didn't see this discussion for some time. Better late than 
never, eh? :)

> - write code from scratch. It´s the better solution but it´s a slowly
> process

It is rather slow, true. Maybe we could manage to build customized 
objects,
which we could maintain as some kind of "community" bindings (if there 
is a consensus). So that we can reuse existing components more easily 
and
readily (and with nice docu as well. The current docu of ruby-gtk is 
great, this is a huge advantage IMHO compared to the other ruby-GUI 
bindings)



> - The YAML files are very easy to understand and write the source code
> by hand or from ruby serialization it´s perfect.
> This sounds crazy??????

I dont think this sounds crazy at all.
The glade people abuse XML to layout and describe the GUI so I believe 
it is of EQUAL right to say that instead of XML we could use YAML.
However, this sounds like a great idea, that requires a lot of work :(
I am not discouraging anyone, but in my experience what starts with 
great ideas, really often means that the work load will make it slow 
down, and some slowed down projects will never happen.


> The YAML files will be very complex. Just have a glance at the glade 
> file, if you want more control on the widget, you have to do the similar 
> thing as the glade file.

I think this argument does not hold because XML is hardly human 
readable. So if one uses YAML, it cant really become that less human 
readable.
XML tends to become crowded with close-tags and overlong lines. I think
the better way to layout a GUI is to describe it as pure as possible,
and as straight as possible. GTK even has its own way with rc_files and 
then we also have web .css which I believe is the best model (because 
many people will know it, and its easier to learn one thing, and apply 
that on everything else)



> 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.

I actually challenge this notion. Yes, decoupling it is better than pure 
html with fixed <font> tags and so on, but an even better way is to 
remain flexible AND generate html and css via ruby :)
I even use replacement hooks, ie RANDOM_BORDER_8PX translates to
"border: 8px groove darkblue" (as example, on every reload/reserving, 
the
result would be different). The thing is that such a system leads to 
more and
more complex applications while still being super easy to maintain, and
as flexible as needed to. If I want to use a pure template i can
use rbtenjin. Or i let ruby generate everything. Or I load some external
css files, use that, and hook up my own autogenerated css files as well.


But just so I am not misunderstood here:
I love the CSS model. I think it is very close to how the human brain
thinks. It could be better, yes, but I think it is very solid.

Example what i like:

.x {border:1px solid black; font-weight:500}

<p class="x">test</p>

But I dont like XML that much, it gets too crowded IMHO.

> Perhaps if we knew the details of your problem we could suggest 
> a simpler solution.

I think the simplest solution is to not use Glade. ;)
But this is just my opinion of course, use what makes you happy and
your life easier.


> I see GTK as the skeleton to build interfaces. If your work in C you 
> need  GObject to create new widgets, but if we work in ruby, c++ or  c# 
> we can create new widgets with classes. In large projects is important. 

Well, do you have an example? Because to me it seems that we have some 
smart people on the list, but everyone cooks widgets on his own.
I am not sure that your approach would make them use YAML a lot just 
now.

YAML is very nice but it also has a few annoyances.
- Whitespace errors can be a problem (yes yes, editors can help, but I 
as a human dont really love to  hunt down errors anyway)
- The nesting could become a problem if the widgets are intertwined a 
lot.


Ah well, I better stop here, I think this is quite interesting.
But I remain sceptical ;)

PS: Why would it be called gtkonrails? Does one need to use rails for 
this then?
I am not using rails and dont plan to, but i am using ruby-gtk still a 
lot

Hi:
Sorry for the delay in my reply.

> Whops, I didn't see this discussion for some time. Better late than 
> never, eh? :)
> 
I was for a positive response from a ruby community hehe.

>> - write code from scratch. It´s the better solution but it´s a slowly
>> process
> 
> It is rather slow, true. Maybe we could manage to build customized 
> objects,
> which we could maintain as some kind of "community" bindings (if there 
> is a consensus). 

This sounds interesting

So that we can reuse existing components more easily
> and
> readily (and with nice docu as well. The current docu of ruby-gtk is 
> great, this is a huge advantage IMHO compared to the other ruby-GUI 
> bindings)

Yes. well i like GNOME very much hehe.
> 
> 
> 
>> - The YAML files are very easy to understand and write the source code
>> by hand or from ruby serialization it´s perfect.
>> This sounds crazy??????
> 
> I dont think this sounds crazy at all.
> The glade people abuse XML to layout and describe the GUI so I believe 
> it is of EQUAL right to say that instead of XML we could use YAML.
> However, this sounds like a great idea, that requires a lot of work :(
> I am not discouraging anyone, but in my experience what starts with 
> great ideas, really often means that the work load will make it slow 
> down, and some slowed down projects will never happen.
> 

Well, that´s true. Perhaps people get involved or not. We don´t know 
hehe. I am here to announce my planning. i would been working in 
something... It´s depends of the time and the interest of the people... 
hehe. I don´t want build a ruby on rails alone... It´s obvious



> 
>> The YAML files will be very complex. Just have a glance at the glade 
>> file, if you want more control on the widget, you have to do the similar 
>> thing as the glade file.
> 
> I think this argument does not hold because XML is hardly human 
> readable. So if one uses YAML, it cant really become that less human 
> readable.
Yes and it´s direct build data structures from ruby, python, etc... from 
YAML.

> XML tends to become crowded with close-tags and overlong lines. I think
> the better way to layout a GUI is to describe it as pure as possible,
> and as straight as possible. GTK even has its own way with rc_files and 
> then we also have web .css which I believe is the best model (because 
> many people will know it, and its easier to learn one thing, and apply 
> that on everything else)
> 
XML sucks it´s obvious. Ten years of pain it´s just enough.

This weekend i was in a meeting with people from GNOME and KDE in 
valencia (spain). there many plans about GTK 3. People like css files.
http://developer.imendio.com/sites/developer.imendio.com/files/gtk-hackfest-berlin2008.pdf

This changes only afects to C not ruby in principle. RUBY bindings 
ROCKS!!!
They want change public C scructures to private. THe access only by C 
methods.
> 
> 
>> 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.
> 
> I actually challenge this notion. Yes, decoupling it is better than pure 
> html with fixed <font> tags and so on, but an even better way is to 
> remain flexible AND generate html and css via ruby :)
> I even use replacement hooks, ie RANDOM_BORDER_8PX translates to
> "border: 8px groove darkblue" (as example, on every reload/reserving, 
> the
> result would be different). The thing is that such a system leads to 
> more and
> more complex applications while still being super easy to maintain, and
> as flexible as needed to. If I want to use a pure template i can
> use rbtenjin. Or i let ruby generate everything. Or I load some external
> css files, use that, and hook up my own autogenerated css files as well.
> 
> 
> But just so I am not misunderstood here:
> I love the CSS model. I think it is very close to how the human brain
> thinks. It could be better, yes, but I think it is very solid.
> 
> Example what i like:
> 
> .x {border:1px solid black; font-weight:500}
> 
> <p class="x">test</p>
> 
> But I dont like XML that much, it gets too crowded IMHO.

Well i was thinking in something more easy. IMHO in applications the 
style are normally the same. This helps people don´t confuse 
applications with a circus hehe.
The first step for me would be a simple packing system for all GTK 
widgets and own ruby widgets (classes) .

For big proyects is important mantain the same "boring" style.
If you need change the style we can use an ruby on rails to all project.


IMHO If we want personalize applications we can use webkit and AJAX from 
ruby . CLUTTER sounds like a great future also.
http://clutter-project.org/


> 
>> Perhaps if we knew the details of your problem we could suggest 
>> a simpler solution.
> 
> I think the simplest solution is to not use Glade. ;)
> But this is just my opinion of course, use what makes you happy and
> your life easier.
> 
I totally agree.
> 
>> I see GTK as the skeleton to build interfaces. If your work in C you 
>> need  GObject to create new widgets, but if we work in ruby, c++ or  c# 
>> we can create new widgets with classes. In large projects is important. 
> 
> Well, do you have an example? Because to me it seems that we have some 
> smart people on the list, but everyone cooks widgets on his own.
> I am not sure that your approach would make them use YAML a lot just 
> now.
> 
> YAML is very nice but it also has a few annoyances.
> - Whitespace errors can be a problem (yes yes, editors can help, but I 
> as a human dont really love to  hunt down errors anyway)
> - The nesting could become a problem if the widgets are intertwined a 
> lot.
> 
> 
> Ah well, I better stop here, I think this is quite interesting.
> But I remain sceptical ;)
> 
> PS: Why would it be called gtkonrails? Does one need to use rails for 
> this then?
> I am not using rails and dont plan to, but i am using ruby-gtk still a 
> lot

Hi:

Inskape people understand clearly why GLADE is a problem:
http://wiki.inkscape.org/wiki/index.php/GtkMMification