Re: [Usability]Re: dialog convenience API

[Seth Nickell <snickell stanford edu>]

> (On a more abstract level, and this is hard to explain, my feeling is
> that the "try to impose UI consistency by having a high-level API that
> does everything for you" approach to UI consistency is sort of
> limited; it tends to fall over in the Real World when the
> super-high-level API a) just isn't good enough so people do their own
> thing anyway and b) ends up being really overengineered...  anyway,
> I'm not sure how much that applies to the current situation but it's
> something to keep in mind. I'm not sure a bit of extra typing, or a
> need to actually read the HIG, should be considered 100%
> evil. Especially when you consider that cross-platform and other
> non-GTK toolkits really should have a reasonable chance of fitting in
> to a GNOME environment. Anyway, maybe this is an argument for a simple
> convenience API and if you want to do something wacky, you have to
> drop back to the "raw" API.)

In this case the increased difficulty of adding non-stock buttons to
dialogues serves as a real impediment in actual implementation of the
HIG guidelines. I'm still chasing down "Yes/No" dialoguse, they're just
too easy to do compared to actively phrased buttons.

Also, just to throw another point in the klinker, I'd like to have
standard calls for throwing up "stock alerts" such as save-confirmation
alerts, password prompts, and a few others. The more code gets shared
here the more likely the user is to end up with consistency.

-Seth