[maemo-developers] [Fwd: [Fwd: Re: Coming back to Glade]]

From: Claudio Scordino cloud.of.andor at gmail.com
Date: Thu Mar 8 10:55:04 EET 2007
Eero Tamminen wrote:
> Hi,
> Added CC to the developers list as I think this belongs there too.
> ext Marius Gedminas wrote:
>> On Wed, Mar 07, 2007 at 05:55:58PM +0100, Claudio Scordino wrote:
>>>> Never generate code with glade. NEVER. It's evil. glade-2 developers
>>>> recommend to use only .glade files and load them using libglade. 
>>>> Glade-3
>>>> doesn't support at all generating code.
>>> Oh, now I see!
>>> Can I have more information about why glade-2 messed up generating 
>>> code files ? Wasn't the problem fixable at all ?
>> It is a generic problem when you use some UI tool/wizard to generate
>> source code, and then modify the source code.  If you later want to
>> tweak something, you have to do it in the code (inconvenient), or if you
>> use the same tool to regenerate code, you'll have to redo all your
>> modifications (painful).


Is not possible to make glade-2 generate a .c file which then is _linked_ to my 
  C code without any modification ? This way, the .c generated by Glade would 
never be modified... I think that, in principle, an approach of this kind should 
be possible...

Otherwise, using Glade-2 or Gazpacho is roughly the same, although Gazpacho does 
not provide any manual or guide yet... This is a problem, since we are going to 
sponsor Gazpacho for GTK-based applications development, and people who will 
receive our products won't have any idea about how using it!

That's one of the reasons why we started talking about using Glade instead of 

> There are many RAD tools which handle the round-trip (some less well
> than the others).  AFAIK with Glade the issue was that it just doesn't
> belong into Glade, it should be done by other, specialized programs.
> For example each language which has separate Gtk/Glade bindings (C, C++
> etc) could have it's own code generator tool.  Anyway, for interpreted
> languages like Python, Ruby, PHP, Perl etc. loading the Glade file with
> libglade is probably faster than the generated code that would be
> interpreted.  And on Desktop reading the .glade files directly is fast
> enough in itself I think, the problem is just embedded devices.

Unfortunately, interpreted languages don't fit our needs, because most of 
existing commercial applications are written in C or C++ and the porting cannot 
require changing the programming language...

Moreover, we often have to deal with specialized devices, so probably 
interpreted languages wouldn't fit at all.



More information about the maemo-developers mailing list