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

[Christian Neumair <chris gnome-de org>]

Am Fre, 2003-04-11 um 04.37 schrieb Owen Taylor:
> 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.
Well, I often feel like there are a lot of bugs which seem to be
orphaned - nobody feels responsible to commit patches without giving
reasons. That may sound like flaming because it names no concrete
examples and doesn't mainly refer to GTK+ but to some GNOME components.
However, I'd definitly appreciate a more "open" development system where
guys like me (aka plebs) can attract a maintainer's attention to a bug
for which a fix is available and reconstruct why something has been
decided that way.
Maybe I should join the bug team :)

> You'd have to be ignorant of the GTK+ development process
> to not figure this out.
Not all parts of GTK+ development process are visible to me; what I see
is mostly great, but qualified criticism has to be accepted.

> 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.
I didn't say that. I said that most GTK+ applications don't follow the
HIG, though. Sorry, but that's a fact.

> 
> 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.
I fear that such "small cosmetic" things just get lost in development
process. There are some examples where similar *very* tiny issues have
been scheduled for fixing pre-2.0 but nobody was willing to take care of
them (again refering to the whole GTK+/GNOME framework).
In my opininion each bug should get a big grade of attention regardless
in which stage of development we are, especially if it's etfapu
(easy-to-fix-and-pretifying-ui).
I now note the fact that it's an incompatible API change and accept that
you "have to spend (your) time on larger pieces" but that shouldn't
prevent you from discussing such small flaws.
I just wanted to sensitize you for that.

regs,
 Chris

> [ Hint: calling people ignorant and arrogant is probably not
>   a good way to make them receptive to your requests ":-) ]
To be honest this was just meant to arrest attention. Additionally, it
was a reference to oGALAXYo's provocative mails which annoyed some of
you.

-- 

»Man kann Moral und Ethik nicht mit Technologie regulieren«
  John "Maddog" Hall, Präsident von Linux International