[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: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 28 May 2009 18:56:41 +0200

On Thu, May 28, 2009 at 18:46, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> Hans-Emil Skogh wrote:
>>>> 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?
>>
>> This makes sense to me as well.
>>
>>> My first idea on how to do this is as follows.
>> ...
>>> Toggle: Added, Deleted, Modified
>>
>> And what would happen if you manually uncheck half of the added files
>> and then click added? Or unchecks all of them?
>
> I wouldn't implement this as a toggle function. A click on the link
> would only check the corresponding items and leave all not-affected
> items as they were: if they were checked, they would still be checked,
> if they were not checked they would still be unchecked.
> Having a link behave as a toggle button is bad - either we would have to
> use a real toggle button (with a 'pressed' and 'normal' state) or not
> toggle but only check.
> But toggle buttons look ugly (my opinion - others might disagree).
>
>>
>>> 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.
>>
>> I still thinks that options that doesn't do anything should be grayed
>> out. If you save a document, the save option gets grayed out until you
>> make a change. If you press undo, the button gets grayed out when there
>> are no more things to undo. They doesn't just stay enabled wating for a
>> user to press it and then silently do nothing.
>>
>> Graying out an option does also provide additional cues to the user,
>> like that the document has not been modified since the last save in case
>> of a save button, or the presence of added files in a list of files in our.
>>
>> I just can't see why we should make an exception from a perfectly good
>> GUI defacto standard here, without getting a single benefit from doing so!
>
> It sure would be possible to gray such links. But it's not as easy as
> you might think. That will take me a while...

Hmm, on second thought:
imagine a commit where tons of files/folders are added (more than fit
in the items list of the commit dialog without scrolling). The default
for the CM dialog is the automatically check all important items
(those that require a commit). But since all added files/folders are
already checked (clicking on the 'added' link would do nothing), the
link is grayed out. But the user doesn't know that all those items are
already checked and wonders why he can't check all added items.

We could however gray out those options which never do anything, e.g.,
gray out 'added' if there simply are no added items.

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=2356347
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-28 18:57:09 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.