Re: property dialogs

["Robert J. Slover" <robert slover Rose-Hulman Edu>]

Tom Tromey wrote:
> 
> I read through all the property dialog replies tonight.  Thanks for
> all the feedback.  I can't say it helped me reach any sort of
> conlusion, but it did serve to illuminate the issues.
> 
> One thing I found particularly interesting:
> 
> [ Robert J. Slover ]
> Robert> Tom, doesn't this suggest that the standard dialog UIs be
> Robert> dynamically loaded libraries...or a CORBA invoked desktop
> Robert> service?  If the people who care about this can reach a
> Robert> consensus on the functionality and the API we can have
> Robert> alternatives to suit different users.
> 
> This makes a lot of sense to me.  I'm not going to go the CORBA route
> (or even the configurability route) in this first version, but I'll
> certainly try to design the API (and typical usage) so that various
> typical arrangements can be accomodated.
> 
> That way any interested party could at least add a config option and a
> new style under the hood.
> 
> This idea neatly splits the problems into two parts:
> 
> 1. What should the default GUI look like?
> 
> 2. What model should we present?  This is really the important
> question, because it affects the code we write in the applications.
> Changing the model will be much harder than changing the buttons and
> layout.
> 
> By "model" I basically mean the choice between "tweak and apply" and
> "instant update".
> 
> So, if possible, I'd like to shift the focus of the discussion from
> GUI details like button layout to the model we present.  My own
> preference is for "tweak and apply".  Here are some thoughts on why I
> prefer this.
> 
> In a past project we used instant update dialogs everywhere.  In many
> cases, this was satisfactory.  But in some cases we didn't like it
> very much.  For instance if a particular change was slow, you'd
> frequently finding yourself wanting to make several changes and apply
> them all at once instead of endlessly waiting for the last change to
> take before you could attempt the next (in our case a change meant
> re-rendering an image, which could be slow).
> 
> Also we found that some dialogs don't feel like instant update dialogs
> to the user.  For instance, if you must type something, then you have
> to press Return or something anyway, which feels different.  Or
> suppose you are using a slider to change the mouse speed (a real
> example).  Having this auto-update seems quite odd.
> 
> However, I'd still like to hear arguments both for and against either
> model.
> 

I would vote, I guess, for the default to be 'tweak and apply' as Tom
suggests, for the reasons that he suggests.  Instant update does seem
reasonable for some things...Adobe Photoshop has a toggle in some 
dialogs for instant-apply...which seems like a reasonable thing to do
where appropriate.

Assuming the API has a method that causes the actual properties to
be synchronized with the dialog values (Apply), this method can be
invoked whenever necessary.  Given an alternative implementation with
a preference of 'Auto-Apply', the method would just be invoked by the
dialog whenever a property changes.  I don't believe the API would 
have to differ at all to provide this behavior over the tweak-and-apply
behavior.

Carrying the thought forward, it may be useful to expose the property
change events to listeners registered for them with the event service.
This way, if I wanted particular properties to act with Auto-Apply
behavior, I could compose a script that listened for the event and
invoked the 'apply' method for the dialog when it noticed certain 
changes...without changing the original dialog source.  Cool.

Would we need a method to set an 'apply mask' to only apply certain
parts of the dialog?  Obviously, this wouldn't be used interactively
but I could see benefits for script-invoked property changes.

> Another model-related question: should we bother with Undo?  How
> exactly should the Undo button work?  How many levels of undo?  What
> happens if you apply, close the dialog, and bring it back up again?
> Etc.
> 

I myself prefer 'Revert' to 'Undo'.  I can't say why.  By 'Revert' I
mean "put things back the way they were when I started."  Undo steps
me back by one change.  I am unsure if 'Revert' makes as much sense
though with Non-Modal dialogs.  In any case,  I should only be able
to go back as far as my previous Commit (not Apply, but Apply+Close).

> I definitely think we should try to have property dialogs be
> non-modal.  It really drives me nuts in Windows when I try to find
> some information but first have to dismiss the property dialog (which
> is the reason I went looking for this piece of info in the first
> place).
> 

I like the concept of a Non-Modal dialog if it is done properly.  By
properly, I mean that the dialog takes the settings of the currently
selected object.  If I leave it up, and select a different object, it
should re-compose itself accordingly.  In this way, it acts as a 
palette for the properties of the current object...which seems to be
more useful than the usual implementation.

> So my own inclination is "tweak and apply", with the default GUI being
> Tim Small's "Apply/Apply+Close/Close" buttons.  I agree that these are
> less confusing than "OK/Apply/Cancel".
> 
> Tom
> 

Perhaps 'Do' or 'Commit' instead of 'Apply + Close'?  Whatever.

-- 
------------------------------------------------------------------------
 Robert J. Slover | Admin Sys Mgr | Rose-Hulman Institute of Technology
------------------------------------------------------------------------

 "Yesterday starts tomorrow, Tomorrow starts today.  The problem 
  always seems to be we're picking up the pieces on the ricochet..." 
                                                    -Marillion, "Jigsaw"