From: John Margaglione (john@margaglione.com)
Date: Tue Jul 10 2001 - 15:25:29 EDT
> Note that there is already an external C code generator for Glade
files:
> http://sourceforge.net/projects/g2c/
>
> It sounds like a good place to start for an external code generator
for
> glade2. It already outputs code using widget arguments where
possible, so
> it should be fairly easy to get it to use widget properties. (I
believe
> the author is on the list, so he can elaborate).
Yeah, I used widget properties to make my life easier when outputting
code. I also did a lot of the property support updates in gtk+2 since I
think the property support paradigm is much more powerful than having a
zillion gtk_set_whatever functions.
Since you're working on Glade2, I'd like to post a few of the
difficulties I ran into when using the Glade XML format. They are minor
grievances, and should be fairly easy to fix.
1. Some of the widget properties in the XML file do not match exactly
with the GtkArg name. For example, GtkRange::policy instead of
GtkRange::update_policy. For a complete list, look at the g2cRemapParam
declaration in g2c_widget.c (in the g2c source code).
2. Many of the widgets have parameters that can not be set using
properties. I think I got them all in the updates to gtk2, but there
are a list of Gnome widgets that do not comply. See the
g2cSpecialHandler struct declaration in g2c_widget.c for a complete
list.
3. Not all widgets can be constructed with a parameterless
gtk_whatever_new call. It would be best if the _new call for every
widget was parameterless, then properties were set, then _show the
widget. I know there are reasons why some of the widgets *must* have
initial parameters, but that is a rare case. Anyway, this would be a
change to gtk2, not to glade.
4. I never could understand the usefulness of the
<last_modification_date> part of a signal. If this was used to let the
author know when it was last updated, whey doesn't this tag exist for
widgets too? I don't really need this, as I use file scanning to check
for changes in the signal handlers.
5. I know this is a got topic, but are you going to use xml attributes
for widget properties, or stick with tags? I generally use tags only if
they are top-level entities or if they are container entities. It's
mainly a style thing, I guess.
It's been a while since I did anything with g2c, and as such I don't
remember what else was on my mind then. Overall I think most of the
problems arise from inconsistencies in the gtk+ API.
> While libglade is great (maybe I am biased :), some people prefer code
> generation, so it would be good to provide this option as well (if
time
> permits).
Now we get to the real issue. James, I really like libglade. I think
most programmers do as well. libglade reduces compile times for
projects, removes the need for intricate knowledge of the gtk/gnome
libraries from application programmers, and is just generally a neat
idea. Windows has no counterpart for this technology.
There are only a few issues that libglade brings up. The first has to
do with the holy grail of IDE functionality: intellisense. If I have to
access my widgets by name (string), then how can the (future)
intellisense parsers tell what type of widget it is? Somebody was
working on a program that would take a glade file and create a C file
that included header information for each of the widgets in a .h, then
provide loading of the widgets through libglade. That synthesis of
ideas is the one that I prefer. That way I don't have to manually
declare variables when I need them. Of course, this also means that the
.h file might get out of sync with the glade-xml file if the programmer
forgets to run the header-generation program. But overall, I like the
concept.
John
_______________________________________________
Glade-devel maillist - Glade-devel@ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
This archive was generated by hypermail 2b29 : Wed Jul 11 2001 - 00:55:17 EDT