Introduction
I'd read the two New Riders books [1], and I've used a number
of other GUI toolkits, mostly on Unix and X. Here are some
of the things I noticed when writing my first Gtk+/GNOME
program.
Probably it helped that I've done Tk and X stuff before,
but I got my first program of any size
(hexsweeper)
running in under a day, and had something I could distribute on
the second day. A toolkit that lets people get code runing
quickly is clearly good for getting lots of projects started.
To get lots of projects finished, we need a better
infrastructure. Gnome has started a lot of this, but there
are weak areas (e.g. automake, documentation, option handling).
If Gnome+Gtk isn't as polished as the very best commercial
toolkits, it is more polished than most, better documented
than most, and more robust than most: if the people who
have worked on it are proud, who can blame them?
The Easiest Layout Isn't Right
It is a problem that the easiest way to lay out controls in
a dialog box is not the slickest: for left-to-right
scripts, the controls should align vertically with the
labels right-justified on the left of them, to put them
close to the controls. It's quite tricky to do that with
Gtk+ (I used a table container), and Glade
doesn't seem to make it easy either.
The simplest way I have seen this done is to associate a label
with each control, and then have a container that does the
layout automatically. It them becomes possivle to align the
text in the label with the text in the control correctly,
something that is very difficult to do with Gtk+ today.
AutoConf Sucks
I spent a day and a half to to days writing hexsweeper,
helped by having written XView and NeWS versions in the past.
I spent another day and a half wrestling with autoconf and
getting the confiigure script to produce something that
compiled and ran.
suggestion: The gnome project should have a template,
in CVS, for people to check out, that has one C source file
using gtk and gnome, and perhaps glade, and that has
autogen.sh, configure.in, Makefile.am and macros files
that work and are commented so people can change them.
That would have saved me a day.
String Arguments Suck
Gtk uses string-valued arguments. They are often nice for debugging,
but there are two problems. First, they are not checked at compile
time, so if yuo type "updaet" instead of "update",
you will get a run-time error. Second, if you supply a parameter
of the wrong type, you'll get a core dump insetad of a
compile time error.
Suggestion: define a set of manifest constants such as
#define GTK_SIGNAL_CLICKED "clicked"
so that people don't have to type the strings. Yes, the
nameis harder to type, but if you get it wrong the compiler will
tell you, and that's a Good Thing.
Consider the following fragment:
coverSheet = gnome_canvas_item_new(group,
gnome_canvas_rect_get_type(),
"x1", 0.0,
"y1", 0.0,
"x2", 600,
"y2", 600,
"fill_color_rgba", 0xEEEEEEA0,
NULL
);
The experienced gnomer might at once say that this will dump core,
because the x2 and y2 arguments should be ouble, not int. But
the compiler does not know that.
Suggestion:
One way round that would be to teach gcc about keyword-value pair
arguments, but a more portable and simpler approach might be:
#define gnome_canvas_x2(p) "x2", (double)(p))
With that definition in place, the code becomes:
coverSheet = gnome_canvas_item_new(group,
gnome_canvas_rect_get_type(),
gnome_canvas_x1(0.0),
gnome_canvas_y1(0.0),
gnome_canvas_x2(600),
gnome_canvas_y2(600),
gnome_canvas_fill_color_rgba(0xEEEEEEA0),
NULL
);
Now the arguments get converted using C's type conversion mechanism
if that makes sense, or generate a warning or error otherwise.
It's also worth pointing out there there was a gcc patch to
enable the compiler to detect a missing trailing NULL
argument, originally made for the XView toolkit.
Canvas points insufficiently differentiated
Canvas points are stoerd in a simple array, which I find odd.
PostScript does that too, of course, so maybe that's why.
Some other toolkits use x, y pairs.
Compare:
hi_points->coords[2] = x0;
hi_points->coords[3] = y0;
hi_points->coords[4] = points->coords[8];
hi_points->coords[5] = points->coords[9];
with:
hi_points->coords[1].x = x0;
hi_points->coords[1].y = y0;
hi_points->coords[2].x = points->coords[4].x;
hi_points->coords[2].y = points->coords[4].y;
This is an incompatible change, sadly; it makes the code much
less error-prone.
Colour Picker
Why doesn't the gnome colour picker have an option to set
the colour dierctly from a GdkColor that was filled in by the
gdk_color_parse() routine? (and waat is the return value
of gdk_color_parse()?
API Documentation
Why doesn't the API documentation for widgets on the web pages have
pictures of the widgets?
POPT
Since the Gnome Canvas uses floating point coordinates,
I found my self needing floating-point command-line options.
My recourse was to use strings, but this is ugly.
It is also clear that command-line options are often used as
a way to change default behaviour: they are a way of
overriding preference settings for a single run of a program,
or a way of setting specific defaults. So they should
tie in with preferences. You should be able to say,
this preference setting can be overridden
by this command-line option.