Re: Enter the build sheriff: Jacob.

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Mar 14, 2002 at 11:09:44AM -0500, Havoc Pennington wrote:
> 
> Alan Cox <alan redhat com> writes: 
> > Could have fooled me. If we had ACL's Seth would be read only in every
> > piece of code I owned by now.
> > 
> > My code also has a HACKING file. No sherrifs. It's staying that way because
> > I don't trust the UI devel people, and because I have other considerations
> > than Gnome 2. 
> > 
> > Daniel has not only done more for Gnome than you have, he's done more for
> > Gnome than you *think* you have.
> 
> I do think Seth has better UI judgment than most of us Alan, with all
> due respect. ;-) The UI team has made a huge overall improvement to
> GNOME, despite some controversial decisions. GNOME 2 is really moving
> in the right direction.


The initial proposal to change the button order had some problems
that were sorted out before being included in the HIG. I was one
of the people according to it then and only realized one of the big
problems after Maciej pointed it out. (Cancel changes position
if that proposal is followed.)  Then and to this day I have wondered
if maybe the RTL<->LTR switch is correct - i.e., should a sed job
be run over it all to swap that part of the geometry?  I've offerred
this matter as open on more than one occassion, but I've seen no takers.
In a reply on gnome-list (iirc), Seth made a very good argument for
the current directional dependence being correct. Even so, I still have
my doubts, just not enough doubt to make me go through the hoops I'd
have to go through to settle them.

Last night, as part of a favor, I had to use MS Word on WindowsME.
(Bloody awful experience it was.) On the dialog for setting the margins
I'd adjusted some values near the top and then tabbed to the button row.
Every single time I overshot, by keyboard, the OK button. The cause
seemed fairly obvious. Between what I'd changed and the OK button there
were about 10 tab steps. After the first two, I just hit tab a few times
quickly. Because it was really not obvious which was the last item in
the non-OK/Cancel/whatever tab sequence, it was not obvious which tab
would land on the OK button. Without painfully slow tabbing, I would have
never tabbed to the desired button without overshot. Were the order
Cancel then OK, I would have overshot Cancel everytime; hardly a problem
as I'd probably just use Escape to cancel on the rarer occassions when I'd
be cancelling. The key there was that I was looking for OK to have the
keyboard focus when I should have been looking for the item just before
OK to have it so I could stop tabbing; when that item is a button on
the same row, it's easier to see it get focus in the horizontal periphery.

Aside: The margin thing in Word being a dialog and not a property window
really sucks when you're abusing margins for widow editing.

> However Seth there's really no point flaming Daniel, remember that his
> project has lots of non-GNOME customers. Daniel is right that the
> build sheriff agreement was only for some modules.
> 
> > Yes no the left, No on the right. And if you won't fix it I will
> > be releasing "sane-gnome"..
> 
> I agree with you, but occasionally disagreeing with the UI team is the
> price of having a consistent UI. As long as we don't have really
> fundamental disagreements about the overall goals of the thing.
> 
> Havoc

Again, I'd love to see show stopping argument for flipping RTL/LTR 
because . . . well, hey, that'd be pretty much CUA-style, and we
all know how much I love that. ;-)


Signing off with gratuitous irrelevant mention of the ICCCM,
Greg Merchan


P.S. - A few more opinions for the hell of it:
       - Bad sheriff! No cookie!
       - Bad seth! No pants!
     - Disclaimers
       - The HIG has changed since I quit it and reintroduced jumping
         Cancel as well as ButtonNotLabelledCancelWhichIsCancel.
         (in StudlyCaps parlance ;-)
       - Omission is just omission.