[HIG] Re: please do not hardcode look and feel in apps

[Maciej Stachowiak <mjs noisehavoc org>]

On 21Jan2002 07:57PM (-0500), Havoc Pennington wrote:
> 
> Hi,
> 
> Please do not do change look and feel of widgets in apps, unless you
> have an app-specific reason to do so.
> 
> For example, some people disable the separator in GtkMessageDialog. Do
> not do this per-app. Open a bug report like a sensible person:
> 
>   http://bugzilla.gnome.org/show_bug.cgi?id=68938
> 
> Then we will make a consistent, maintainable fix that addresses the
> problem for the whole desktop.
> 
> If we change our mind on what we want as default, or decide to make it
> themeable, or whatever, then app-specific hacks will fuck everything
> up. Plus, changing defaults from the library is the one guaranteed way
> to end up with inconsistency.
> 
> An example of an app-specific reason for changing look and feel is "my
> app has a notebook above the separator, so there's no need for an
> extra separator." An example of a non-app-specific reason is "I don't
> like separators in dialogs ever."
> 
> Avoiding app-specific hacks is one of the many reasons the HIG should
> recommend what the toolkit makes easy, even if we are also
> recommending changing the toolkit via bugzilla. Do not mix the a) in
> the b) or we have a maintenance disaster that handicaps our ability to
> move forward.
> 
> 
> Disagreements with, or suggested improvements for, the libraries go in
> *BUGZILLA*. *NOT* in the HIG. Pretty please. Nothing in the HIG should
> require cutting-and-pasting boilerplate
> modify-the-toolkit-in-trivial-ways code all over creation.
> 
> The HIG is information on how to properly write apps, not a tool for
> arguing with the library maintainers, and not a treatise on the ideal
> UI design. Designs go in RFCs, arguments/bugreports/suggestions go in
> bugzilla or on mailing lists. Deployable, maintainable, finished
> suggestions go in the HIG.

Thinking about this a bit more, it seems to me that it would be good
to have two editions of the HIG. One would describe current best
practices, easily implementable with standard libraries. The other
would describe the target design, and would have links to the
relevant bugzilla bug reports where appropriate.

I suggest this because it's hard to keep a picture of a complete,
coherent design in mind based on a document that does not quite match
it, plus a bunch of scattered bug reports and discussions.

The "current best practices" HIG would be the one we ship with GNOME
as part of the developer docs and try to conform to for 2.0, and the
other would be a sort of "unstable branch" of things the Usability
group wants to see in future GNOME releases.

Another possibility is to have only one edition of the HIG, but with
commentary on possible future changes. But I worry that this would
confuse developers and designers reading the HIG, even though it might
be more convenient for the HIG team.

Regards,

Maciej