Re: [HIG] Re: [Usability]No HIG maintainer?

[Seth Nickell <snickell stanford edu>]

On Tue, 2002-12-10 at 09:02, Murray Cumming wrote:
> On Tue, 2002-12-10 at 16:56, Havoc Pennington wrote:
> > On Tue, Dec 10, 2002 at 04:09:46PM +0100, Murray Cumming wrote: 
> > > Shouldn't we just tell them to use the default, then later change the
> > > default in GTK+?
> > 
> > That would probably be ideal, but I think the stuff Gregory came up
> > with (just set frame style to none, make the title bold, and indent 12
> > pixels via either a vbox hack or padding all around the inside of the
> > frame) is pretty easy to implement for apps using Glade, and for this
> > type of dialog pretty much everything is using Glade. So I don't think
> > it's terrible to go ahead and implement it. I did it quickly and
> > easily in gnome-terminal for example.
> 
> My logic was
> a) There should be a widget for this "categorisation" of child widgets,
> and GtkFrame has been that widget until the HIG said otherwise.
> b) GtkFrame can be made HIG-perfect easily, and we seem to expect that
> for GTK+ 2.4. So let's just use the defaults now for simplicity's sake
> and benefit from automatic HIG-ization in future.
> c) People are still debating parts of the HIG, such as border spacing.
> If the HIG is embodied in the GTK+ defaults, and if everyone uses the
> GTK+ defaults, then changes in the HIG can be inherited automatically by
> applications. That's less work.
> 
> This does delay HIG-ization until GNOME 2.4. But then again, for UIs in
> GNOME 2.2 itself, we hit UI freeze before we could HIG-ize much anyway.

The reason I disagree with you and Havoc on this stuff is that GTK+ has
not been responsive to HIG desired changes. Look at how long HIG related
box have been sitting in Bugzilla, often without any GTK-team
commentary. In fact, most of the pressure I'm seeing to get these things
added to GTK is from programmers such as jrb who are implementing the
existing HIG spec but want to do it more conveniently. If GTK+ can
provide better assurances that HIG related stuff will not be ignored
without us first asking programmers to hack around GTK+, I'm much
happier having changes made in GTK+ first. 

Right now, making the changes in the HIG first is:

1) Much less work for an already over-stretched team who doubles in
doing usability work for much of GNOME (currently I'm pretty sure we'd
have to spend lots of time pestering GTK+ folk to actually get things
changed... I don't want to have to go through a big mailing list
nightmare for every change)
2) More likely to result in success because programmers are more likely
to fix things in order to be lazy (because its hard to implement HIG
currently) than because a few of us say "We want this for HIG": no
matter how obnoxiously and frequently we say it.

-Seth