Re: A matter of principle [Re: HIGification of dialog boxes]

[Cyrille Chepelov <cyrille chepelov org>]

Le Fri, Jul 18, 2003, à 02:44:52PM -0500, Lars Clausen a écrit:


> I'd like to point out that the current setup is non-modal with Ok and
> Cancel buttons (i.e. explicit apply).  Does it appear to be confusing?  

It can be confusing very fast indeed. When the WM plays games and there is
really not enough screen to put a taskbar (my 800x600 laptop, very handy for
watching real tv while trying to do real work -- ahem --), I lost count of
how much time I accidentally lost a property window. pwm is very nice for
some of its aspects, but getting back a lost window is not high in its
priority list.

> I understand the concern about 'difficult' properties like color and
> complex text needing a proper undo.  But we don't currently have any better
> undo than what the instant apply offers, we just have an extra button to
> press before things take effect.  We have no help seeing what the results
> are until we press Apply, and once we do, there's no other way back than
> the undo stack anyway.  

Hmmm. Yes, it's clear to me now that Apply != Try.
	Apply = OK but don't close
	Try = let's see *temporarily* what this does, but if I click cancel,
		that cancels.
This discussion is starting to be really interesting. How about a really
heterodox solution: not one, not two, not three, but four! buttons per
*now modal* property dialog:

	[Cancel] [Revert] [Try]	[OK]

(in that order). Nobody catatonic yet? Let me explain:
	cancel: aborts all changes, closes window.
	Revert: reverts the last change only (done by Try)
	Try: applies the current change set to the diagram)
	OK: Try + close

The normal undo stack would be used (perhaps with a small smart, that if two
successive changes to a property are done, they are coalesced together),
except that the dialog would remember the stack's level at the dialog
appearance, so that the Revert button does not go back beyond that (and to
disable undo stack coalesces between two successive calls of the dialog. If
I set to blue, close, reopen, set to red, close, I want to have two undo
entries: before-red (blue) and before-blue (whatever was on).

Hmm; I see where the instant apply logic makes sense:
	[Cancel] [Revert] [Close]
make a change, (with undo stack coalesce on), have it refresh immediately.
Close just closes (accepts the change). Revert uses the undo stack until all
entries created since this dialog was shown are used up. Cancel uses all of
these entries then closes. Might even be disposed of if event coalescing
works really well and using multiple reverts to achieve cancel doesn't mean
42 mouse clicks.

Keeping the dialog modal simplifies the handling of multiple sources for
undo stack events, and also helps making sure the property dialog doesn't
get buried behind the diagram.

> I'd rather have instant apply and then an easy access to the undo stack in
> the properties dialog -- at the very least allow the keyboard shortcut, if
> not adding an undo button.

Oh -- I see that I'm getting influenced back into the "true gnome way" :-)
I don't think that allowing only the shortcut is a good thing. Revert is a
good thing to let the user know is possible; it belongs to the action area
(in addition to the shortcuts).

> As an aside, I think the original instant apply comment was about the
> preferences and diagram properties (grid etc), not object properties, and
> there's no undo stack for those anyway.  But we need to be consistent.

Yep. By for instance, allowing these to go on the undo stack as well ? -<:o)
(and then someone brings a "undo stack picker dialog" so that one
transaction can be dug up and undone individually, and then the world
wonders how we could live without that feature before).

	-- Cyrille

--