Re: [Usability]Re: An alternative proposal for instant-apply vs. non-instant-apply

[Seth Nickell <snickell stanford edu>]

> Adam is here describing items which can have incorrect settings. These
> are things for which there is a specific reason not to make them
> instant-apply.

No, he's describing things that can take a while to change. Window
Manager, for example, should have *no wrong settings*. We're concerned
about it because the current implementation is buggy, and because it can
take a while for the borders to change. In the long term, Window Manager
is a *preference*. My interpretation of what Adam is saying is as
follows:

"Instant apply is preferable in cases X & Y, but because both X & Y are
currently buggy or slow to take effect, we shouldn't use instant apply
for them at the current date"

Putting implementation issues aside, e.g. speaking theoretically, the
selection of Window Manager is a preference not a setting, and hence
probably should be instant applied. That there are wrong choices today
is an implementation artifact that we will hopefully eventually remedy.
But until we do, we can't use instant apply for it.
 
> I'm willing to expand the role of instant-apply dialogs, but only
> where I am sure that the framework is in place for them to co-exist
> with delayed-apply dialogs.

Explain this further? What is a "framework...for them to co-exist with
delayed-apply dialogs". The technical framework here is pretty easy, do
you mean the logical framework, the labels choices of button etc? I
think Maciej's suggestion was pretty good in this area...

> > and we should be pushing to try and make more
> > and more dialogues instant apply (fixing the issues that make that not
> > feasible today, for example if switching themes took half a second it
> > could be instant apply, etc).
> 
> There will always be issues making it unfeasible. We have to deal with
> the fact that there will be both styles of dialog.

All preferences should hypothetically be able to be instant apply
eventually. I'm not sure if there will always be issues. I do agree that
there will probably always be settings that we'll need delayed-apply
for, so I agree that its very important to make sure they can fit well
together.

> You can go on a crusade to make dialogs instant-apply if you want, but
> bear in mind that opinion is divided on this one. It is essential that
> both styles can co-exist, and that is what I am concerned with at the
> moment. If the dialogs in the panel are anything to go by, I do not
> believe that this has yet been addressed adequately.

We will have to decide on a default to push, that's what's in contention
here. Opinion can be divided internally, but the final decision we reach
needs to have everyone behind it. We need guidelines for choosing when
to use instant-apply and when to use delayed apply. The big question
right now sort of is, should the guidelines read as:

"You should use instant apply dialogues unless (...)"

Or should they read as:

"You should used delayed apply dialogues unless (...)"

The wording here can be very important in determining the eventual
direction that GNOME interfaces make. If it reads as the latter, fewer
people are going to be inclined to make it possible to use instant apply
with their settings, so it may never be a possibility to move to them.
Whereas if we word it the first way, it may take a few revisions but
people are going to be more inclined to change their settings into
preferences (good! irregardless of which way we go here) and move them
over to instant apply.

> PS. Could someone do me a favour? I'd like to take a look at some of
> the instant-apply dialogs in Nautilus, but I don't have the program
> installed. It would be really great if someone could send me or put on
> the web some screenshots of specifically those dialogs which are
> instant-apply. Thanks.

You can't really get a sense for instant apply dialogues without using
them. Is there some way I can get a copy of Nautilus to you? Nautilus
has no delayed-apply preferences, and almost no settings at all. It *IS*
possible.

-Seth