Re: This is a Troll!

["Edward A. Falk" <falk efalk org>]

Ok, FWIW, I've been using Gnome/Gtk extensively for a couple of years
now, and have several projects on sourceforge.  Most significantly
a cad program at xdraft.sourceforge.net.

There are lots of little nits that I could pick, but all-in-all it's
the best GUI toolkit I've ever used, and I've used quite a few.  I've
even written a couple.

Let me pick a couple of big nits, thought, that I would love to see
addressed in the not-to-distant future.  I'll even volunteer to do some
of this work if people want.


The file-chooser is a little clumsy.  Its look and feel could be improved
someowhat (e.g. icons for the "create dir", "delete file", etc. buttons.)
Also, it's patterned after the Motif file chooser, which isn't that great
a model.  The (I hate to say it) windoze model is more useable, I find.
I found from a programming and user standpoint that the file filtering
mechanism left a lot to be desired.

One issue I have is that the directory selector menu at the top doesn't
allow the user to simply type a directory in.  I think a combo box would
be more appropriate here, perhaps coupled with a "browse" button.

I think the directory path and the filename should be kept completely
seperate.

Next, I think the filter should also be a seperate string.  Note that
multiple filetypes could be specified in the filter, e.g.
"*.jpg *.pnm *.gif"

Finally, there really should be a way for an application to customize a
file chooser dialog.  They way I implemented this in my own file chooser
was to leave empty rows and columns in the table widget the chooser
was built on.

For an example of what I have in mind, see

	http://www.efalk.org/Widgets/#fileselect

which is a file-selector I wrote for athena/motif many years ago.

If there is interest, I could work on the Gnome file chooser.



Second nit:  Although I took a while to get used to it, the way you can
attach an accelerator to a menu item is really great.  You just pop up
the menu, highlight one of the entries and touch a key.

There are two major problems with this model, however.  First, it's a
little too easy to accidentally change keyboard accelerators, and no
way to undo the change you've made.

Second, and most important, the use of unmodified keys as keyboard
accelerators is highly confusing.  If I pop up a menu, and then press an
unmodified key, the correct action would be to select the menu item with
that key underlined -- or if no item has that key underlined, then the
first item that starts with that letter should be selected.  Again (much
as I hate to say it), look to windoze for the way this ought to work.

I find these issues make it much more difficult to navigate a program
from the keyboard than it needs to be.

The solution to both of the above problems is to not allow unmodified keys
(except function keys) to be assigned as keyboard accelerators by the
user.  (It would still be permissible for the program to assign them
explicitly.)

Finally, I think a stock menu item should be created (and added to the style
guide) for a File menu item which locks and unlocks user assignment of
keyboard accelerators.

Another good idea would be an accelerator editor dialog.  Anyone who has
access to CoolEdit 2000 can take a look for a good example of this.  If
there is enough interested, I'll try to post a screenshot.



Finally, here are a number of minor bugs, the fixing of which would do
much for improving the usability of Gnome/gtk.

* The combo box should set its width based on its largest menu item,
  rather than the currently-displayed menu it.  It also be nice for the
  combo box to make resize requests as larger menu items are added, but
  it's not all that crucial.

* The "default" border around buttons (the one that indicates that the
  given button is the default) should be optionally fixed in place.
  For instance, I might write a dialog for which hitting enter anywhere
  confirms the dialog.  (And escape cancels, of course.)  For a dialog
  like this, the default border should remain permanently around the
  "Ok" button.  Currently, the border follows the keyboard focus,
  disappearing completely if no button has focus.
  
  In general, the border should surround exactly whatever action would
  be activated by the enter key.  Thus, any time the "Ok" button *or any
  other widget which would activate the dialog* has keyboard focus, the
  "Ok" button should have the default border.

* Sometimes I like to specify the location of an application on the
  commandline.  For this reason, Gnome/Gtk should parse the "-g WxH+X+Y"
  commandline option used by other GUI toolkits.  I realize this is
  somewhat meaningless for applications which pop up multiple top-level
  windows, but these applications are the minority.  Simply honoring the
  "-g" option for the first top-level window would be sufficient.




Anyway, those are my observations from a user point of view.  I have
some more comments from a programmer's point of view, but they can wait.
And besides, the user interface is far more important than the programmer's
interface.

	-ed falk