Re: [gtk-list] Style Guide (was Re: vi bindings for text widgets)

[Andreas Kostyrka <andreas rainbow studorg tuwien ac at>]

On Tue, 7 Jul 1998, Steve Hosgood wrote:

> I say keybindings should be a function of a 'style guide', and not settable
> to random things by users. Here we are, championing GTK as a fine toolkit for
> writing applications, yet we seem to be supporting two conflicting camps
> at the same time:
Actually, I tend to be also in the uniform UI camp ;), but one has to
balance things very carefully.
> Now, I'm not a fan of Micro$oft and their products, but I think I have to
> admit that they had a sensible idea early on (probably in Windows 2 or
> earlier) in that they wrote a style guide. Not every MS developer implements
> everthing according to the book of course, but *most* MS Windows applications
> have a fairly similar mentality running through their GUI. Occasionally, you
> come across weirdo applications which break all the rules (like the RS
> Components CD Catalogue, available in the UK) and they stand out in their
> awfulness.
That depends. Not always the book can cover anything. I don't know about
the catalog, but for example Civ2 is awful. But when one thinks about it,
the problem is not ``not following'' the book, but the fact, that Civ2
make all dialogs modal. 
> 
> The same cannot be said of the X window world. Most things plumb new depths
> of GUI design awfulness! I'd like to think that GTK is a step away from that
Not always. But then, it's perhaps the lack of sensible CLI that appales
me in Win95. And stupidness like binding .ext -> filetype -> application.
(The MAC gets it right.)
> world, and toward a new era of quality applications.
> 
> To take a single example, at least all GTK scrollbars work similarly, and
> tend to live to the right or below the thing they scroll, but some X
> applications place them elsewhere, and/or use the idea of clicking left button
> in the trough to scroll down, right button in the trough to scroll up!
> 
> Now, it is surely fair to claim that GTK should *not* allow random users to
> redefine its scrollbar widget to work in the 'left button'/'right button' way?
Why not? What if the user is used to work with App X this way, and now he
has to reorientate himself because he wants to use App GnomeX?
> Otherwise we'd all get pretty annoyed if we ever had to use each others'
> workstations for a moment occasionally.
That's why Unix is a multiuser OS. No matter where in the office I logon,
I get the same workplace. There is basically one way that differs:
$DISPLAY:)

> I extend this claim to cover the 'vi keybindings' argument. I think GTK
> should have its own keybindings. For convenience they should be chosen to be
> maximally convenient to the most users at the time they are laid down. From
> then on, they go in the 'style guide' as *the* GTK way to do something.
> 
Some notes:
1.) Not GTK, but gnome. GTK is just a widget library, if you want a
    coherent desktop, go for Gnome.
2.) The keybindings probably should be changable. Any key binding in a GUI
    is just an accelerator, and which accelerators are used depends upon
    the task the user wants to do. It's easy to say use standard
    accelerators in a tiny applet, but it's problematic when you try to
    apply this to an app in size of Gimp or greater.
3.) So probably, all apps should come with standard accelerators but this
    should be changeable by the user in a easy standard way, like the Gimp
    does it.

> P.S.
> I have no argument with .rc files setting (say) the font used by menus, or the
> background colours of buttons or windows. But changing *input* methodology in
> .rc files is, I argue, not a Good Thing.
Agreed, but not completely. Making input methodlogy configurable is just
much more work, and should be done more cautious.

> P.P.S
> Should the GTK project even start to think about putting an informal GTK
> style-guide together before GTK applications get so unlike each other in
> mentality that they stop being usable?
Don't think that this is in the scope of Gtk. And Gnome does have a style
guide, which admittingly is sometimes not VERY complete :(

Andreas