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).
Hi,
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
Gazpacho...
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.
Regards,
Claudio
_______________________________________________
maemo-users mailing list
maemo-users@maemo.org
https://maemo.org/mailman/listinfo/maemo-users
