Re: dialog convenience API

[Ettore Perazzoli <ettore ximian com>]

On Fri, 2002-05-31 at 15:09, Havoc Pennington wrote:
> 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.

Makes sense to me.  I don't really care which class contains these
methods, and I agree that fewer classes is better.  I didn't even
actually mean imply that we necessarily need to have a specialized class
(although, it probably came through that way).

But given the current status of GtkMessageDialog and since we are API
frozen there, maybe it's easier to use a different class.

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

Real World Applications have always been writing their own error dialog
functions...  Probably we could just look into what they have been using
so far?

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

You can't really expect people to be consistent with the HIG if having
things consistent with the HIG requires an unreasonable amount of coding
as it does now.  They should have to read the HIG for things that can't
be automated by the toolkit -- but everything else should be consistent
"by default".  When there are too many variables involved, there is too
high a chance for the programmer to do it wrong (or to not do it at
all).

Besides, the basic question is: how likely is something like this to get
into 2.2?

-- Ettore