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

Re: Suggestion for "select all" functionality in Commit dialog

From: void pointer <rcdailey_at_gmail.com>
Date: Wed, 27 May 2009 15:12:06 -0500

On Wed, May 27, 2009 at 2:11 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:

> GMail doesn't leave the checkmarks if you choose e.g., "Read" and
> "Starred". When clicking on "Starred" after "Read", all read items are
> unchecked again if they're not also starred.

Correct. This is the exact behavior I am experiencing in both GMail and
TSVN, which is perfectly fine.

> Maybe we should do that differently? Only uncheck items when "None" is
> clicked, and 'add' the checkmarks for all others? I.e., a click on
> "Deleted" will check all deleted items, another click on "Added" will
> leave the deleted items checked but also check all added items?
>
> If we do it that way, then disabling the links shouldn't be necessary
> anymore?

I see where you are going now. Here is my thoughts on the design
differences.

In GMail, as you already stated, clicking a selection pattern link undos the
last selection pattern you used. This is appropriate in GMail because you
can quickly do batch operations with a couple of clicks. For example, if I
wanted to delete all starred and unread items, I would do the following:

   1. Click "Starred" selection pattern
   2. Click the "Delete" button
   3. Click the "Unread" selection pattern
   4. Click the "Delete" button

However, in TortoiseSVN we do not have the luxury of doing this. For
example, if we wanted to check in all added and deleted files only, by only
using the selection patterns, we would have to do 2 commits:

   1. Open commit dialog
   2. Click "Added" selection pattern
   3. Commit the items
   4. Open Commit Dialog
   5. Click "Deleted" selection pattern
   6. Commit the items

This is undesirable. I think this is where the design goals of GMail and
TSVN differ. It is convenient for GMail's selection patterns to behave in an
independent way like they do because operations can be done quickly.
However, in TortoiseSVN, we need to be able to perform multiple selection
patterns on multiple types of files in a single operation. For example,
using an accumulative selection pattern approach, we would do the previous
scenario as follows:

   1. Open commit dialog
   2. Click "Added" selection pattern
   3. Click "Deleted" selection pattern
   4. Commit the items

This seems to be a reasonable modification to GMail's behavior to suit
TSVN's needs and differences. The difficult part, however, is figuring out
how to intuitively allow each selection pattern to have both a "check all"
and "uncheck all" behavior.

My first idea on how to do this is as follows. If we have the following
selection patterns in the commit dialog (simplified):

Select: Added, Deleted, Modified

We would simply rename the "Select" to "Toggle", like so:

Toggle: Added, Deleted, Modified

So, if the user clicks "Added" 3 times, it performs the following:

   1. Check all added items
   2. Uncheck all added items
   3. Check all added items

This allows each selection pattern to actively undo itself, and allow the
user to provide any combination of selection patterns to get the desired
overall selection of files that they want.

I like your idea Stefan, the ability to "Toggle" instead of just "Select"
makes more sense for TSVN as I've explained above. However, if there are no
"Added" items in the commit dialog, then I do not believe that the "Added"
selection pattern link should be disabled. I think that by clicking "Added"
when there are no added items, it should end up doing nothing at all except
iterating every item in the commit dialog to search for items with the
"Added" state.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2355918

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-27 22:12:16 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.