RE: [Usability]shouldn't action-area-border of GtkDialogs be 6 by default?

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-04-11 at 09:33, Christian Neumair wrote:
> Am Fre, 2003-04-11 um 09.26 schrieb Murray Cumming Comneon com:
> > http://bugzilla.gnome.org/show_bug.cgi?id=98779
> > and other similar bugs from the links here:
> > http://developer.gnome.org/projects/gup/hig/
> Thanks for pointing out those links.
> 
> > The GTK+ developers have not declared a decision, but I suspect that they
> > will refuse this.
> Well, some call them ignorant and arrogant, some call them unflexible. I
> won't do either, I just get the feeling that the GTK+/GNOME framework
> contributors belong to different fractions, some even completely
> ignoring that GNOME and it's concept *rely* on GTK+ and it's developer's
> attendance to change code which may require many fixes in dependent
> applications. As most of the GTK+-only applications anway don't follow
> the HIG that wouldn't even bother them as they often have a border of 0
> for the widgets above the action area and therefore such a change
> wouldn't even be noted. But for the applications included with GNOME it
> would improve things as the HIG could be followed without having to work
> with odd border widths. We should have a monolithic framework, not in
> terms of packages but in terms of consistency. If the HIG suggests it,
> then why don't adapt that small code snippet?
> Please, GTK+ developers, if you refuse to change this, explain
> exhaustively WHY you refuse it. Having transparent decision processes
> would be a great achievement.
> I accept that this can't be fixed in 2.2.x for UI reasons but why don't
> change it in HEAD aka 2.3.x?
> This is NOT yet another flamewar, I just want to bring GTK+/GNOME where
> I want it to be: To the top of it's form even if it requires some
> developers to bite the bullet!

If the request for the change was rejected, the bug would be
closed. We don't keep bugs open because we like having open bugs.

You'd have to be ignorant of the GTK+ development process
to not figure this out.

The reason that this bug takes some consideration is that it
is an *incompatible API change* -- just as GNOME wants a value
of 6 specifically, some other environment may specifically want
the current values.

It's quite arrogant to say think that only GNOME application
writers pay attention to the details of their application's
layout.

Now, it's an *incompatible API change* that will only break
applications in subtle cosmetic ways, so the idea hasn't
been rejected out of hand. But it's an incompatible API
change that gets put in the queue with the other API changes.
Early in the 2.3.x development process, we have to spend
our time on larger pieces of API.

Regards,
                                            Owen

[ Hint: calling people ignorant and arrogant is probably not
  a good way to make them receptive to your requests ":-) ]