[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Another auto-close idea...

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Mon, 30 Mar 2009 18:14:12 +0200

void pointer wrote:
> Hey guys,
>
> I've been really putting a lot of thought into TSVN's auto-close
> behavior. I posted a thread a while back with an idea but I think I've
> found a better one.
>
> Right now the progress dialog in TortoiseSVN seems to be used in several
> places for both local and remote operations. Examples:
>
> Local Operations that use the progress dialog:
>
> * Delete
> * Add
> * Revert
> * etc
>
> Remote Operations that use the progress dialog:
>
> * Update
> * Commit
> * Switch
> * Merge
> * etc
>
> Of all of the operations we can perform, regardless of if they are
> remote or local, there is one commonality between them: They all use the
> progress dialog.
>
> So to make the progress dialog auto-close to the user's exact
> preference, the obvious solution is to provide an "Auto-close" option on
> the progress dialog itself. Consider a fresh installation of
> TortoiseSVN. In this case, no progress dialogs at all would auto-close.
> However, as the user starts using TortoiseSVN, they will begin seeing
> the progress dialog used in different operations. For example, the user
> may find it annoying that when performing a successful commit that the
> progress dialog does not automatically close. So the user would select
> "Auto-close if no errors" for that dialog.
>
> The user then proceeds to do an "Add" of a directory. The progress
> dialog does not go away, so he would choose "Auto-close always". You see
> where this is going? This gives the user the ability to select how they
> wish for progress dialogs to close on-demand.

An "auto-close always" is bad. Very bad. We should never auto-close if
there are errors.

> One tough thing to consider is that not all auto-close "types" work for
> all progress dialogs. As far as I know (Please correct me if I'm wrong),
> every use-case for the progress dialog shares 2 specific states: Failure
> or Success. However, the update progress dialog has a few special
> states... such as Merges and Conflicts. For the update progress dialog,
> the user would be able to select the following auto-close settings:
>
> * Merges
> * Adds
> * Deletes
> * Conflicts
> * Errors
> * Success

Not just the update dialog. Switch, Merge, Branch/Tag have the very same
states.

> And for the "Add" progress dialog (When adding a directory hierarchy),
> they would have a limited subset of those choices above:
>
> * Errors
> * Success
>
> Another difficulty if figuring out how to provide these options. I
> personally think that check boxes would be the most intuitive way, since
> it allows the maximum possible flexibility to the user. However, placing
> a collection of 6 or more check boxes (For the update progress dialog)
> could result in some clutter that a few of you might have some personal
> issues with. However, I think with a lot of discussion and careful
> design, we can make it work. A combo box is *not* the solution. Perhaps
> a combo-box with check boxes as elements? But I think that's getting a
> bit too complex... I'd have to see it first to know if it would work.

While I understand your desire to have a separate auto-close setting for
every single operation, I really think this adds way too much UI clutter
and way too much complexity.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1483524
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-03-30 18:14:30 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.