Re: dialog convenience API

[Havoc Pennington <hp redhat com>]

Hi,

I don't have time today to respond in detail, but a high-level
comment; I think it would be far better for the GTK API (and
programmers trying to learn it, and our general bloat level) if we
somehow extend GtkMessageDialog, instead of creating a new GtkAlert
type. That way there's no question which to learn about and use.

I'd suggest that we at least try to do this by adding a couple
features to the message dialog as needed, and then have a convenience
function or two that does things like set it !resizable and take
bold/nonbold text arguments. A separate GtkAlert object is a bit too
"heavy" a solution for the scale of problem here, IMO.

In any case, we can maybe try out some of these ideas in libegg and
see in practice what kinds of issues there are.

Havoc

(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.)