UI guidelines and the libraries

[Havoc Pennington <hp redhat com>]

Hi,

A point about the HIG - it needs to follow the Mac guidelines in one
important respect, which is that the guidelines should be easy to
implement using the stock libraries. In fact I think it would be a
good idea to go ahead and have notes in the HIG on how to implement
each of the suggestions in code, when it might not be obvious.

It's fine to also have a paragraph about the ideal situation and/or
planned library changes, but we need to be telling people what they
can reasonably do in apps today.

To try to make the point concrete, it's OK if implementing the HIG
requires a funky hack or two, like gtk_label_set_markup
(dialog->label), but it's not OK if implementing the HIG requires
rolling dialogs from scratch and not using GtkDialog. If every app is
rolling from scratch that just screws our long-term maintainability,
and will tend to break a lot of other details (such as setting the
semantic type of dialogs, or whatever) in the process of matching what
the HIG says.

If GtkDialog isn't the perfect thing, then tough; we didn't get the
perfect thing in time for 2.0, we'll get it in 2.2. But the HIG should
document what people can do today. It can have a footnote about the
2.2 plan, with a reference to the GTK bug number that will enable it,
of course.

I understand Maciej's point about bottom-up design; but I think my
point here stands regardless. If the HIG team files a bug for 2.2,
then we will have a top-down design for 2.2. And in fact many parts of
GTK 2 were designed with the UI in mind already. But reality requires
that the HIG document what can be done today without creating
unmaintainable code - the HIG should not document an idealized UI, but
the UI GNOME can reasonably have using our current platform.

If the HIG isn't done with this in mind, it's an academic exercise,
not a useful product. HIG is a guide to using the GNOME platform to
make usable apps, not a guide to rewriting the GNOME platform.

.02,
Havoc