GTK on rails

[martin_gnu]

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_gnu]

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

[martin_gnu]

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.

[martin_gnu]

sorry i mistake.

I see YAML files easy. Much more ““than”” XML:

[martin_gnu]

On Thu, 2008-04-24 at 01:04 +0200, Martin V. 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:

Re: widget valid signals and properties

Regards
Grant

[martin_gnu]

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:

  @[email protected]_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.

[martin_gnu]

Grant McLean wrote:

On Thu, 2008-04-24 at 01:04 +0200, Martin V. 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:

Re: widget valid signals and properties

Regards
Grant

[martin_gnu]

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

test

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

[martin_gnu]

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

test

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

[martin_gnu]

Hi:

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