On Wed, May 27, 2009 at 1:04 AM, Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se
> wrote:
> >> However, I do get slightly confused that all choices are clickable all
> the time.
> >> I would suggest to gray out the links that does would have the same
> effected
> >> as clicking "Check: None".
> > So if there are no Modified files shown, does that mean the "Modified"
> selection
> > pattern should be grayed out? The same applies to "Added" or "Deleted"
> (If those exist).
>
> Yes. That was what I had in mind.
>
> > The point is, this feature is not designed to be dynamic, at least as far
> as
> > GMail is concerned.
>
> Then maybe gmail also has a point to improve upon. :-)
> Designing GUIs on the web is still pretty "new" and there are no standards
> (as far as I know) for graying things out. In windows GUIs there is a very
> common (and in my opinion good) practice to gray out options that are
> invalid.
>
That's just my point, though. None of the selection links can EVER be
invalid. The links simply say "Select all of these". And if it happens to
select NOTHING, that's considered the same as finding one, or two, or
five-hundred. The link's responsibility is not to make sure that at least 1
or more is selected. Its responsibility is to iterate every item in the list
and select any with a specific state, for example, if the state it is
searching for is the "Deleted" state, it will check any with that state.
However, if it does not find any, it has still done its job and done it
successfully.
If your goal is to check how many deleted items there are, for example, then
using the link for this is wrong. For example, some people might be curious
as to how many "Deleted" items are in the commit dialog, however they expect
to see the "deleted" link disabled or grayed out in order to determine if
they have none, or some.
If this is indeed your goal (to see how many items are selected), perhaps
Stefan could add some text somewhere on the commit dialog showing you the
number of selected items, if this does not already exist. For example, if
you wanted to see how many deleted items there were, you would click the
"Deleted" link, and if it selected nothing, you would see "Selected Items:
0", and if there were 5 deleted items checked by the pattern, then you would
see "Selected Items: 5".
But I'm still not 100% sure on what you are expecting by those links being
disabled.
For example in the commit dialog, you cannot check "Show externals from
> different repositories" if there are no externals in your working copy. I
> think the same thing should be added for the links.
>
To me, this is the exact same thing, and "Show externals from different
repositories" being disabled doesn't really affect the usability or
stability of the commit dialog. By stability, I mean that if the user has
this checked and there are no externals, then simply nothing would be added
to the commit dialog. However, the user should not care. To me, this says
"I'm checking this because just in case there ARE externals, I want those
items to be shown here. However, if there are not any externals, then this
feature will do nothing, regardless of its checked/unchecked state".
Basically what you're asking TortoiseSVN to do is: "Well, I know that the
behavior of "Show externals from different repositories" is wrong, so I want
other things to behave in a broken way too".
> Note that the links are grayed out for a moment while the working copy is
> being scanned when the dialog is just opened. So support for graying out
> links is already there in some form.
>
As I told you before, their job is to iterate the list of items. If there
are no items, then they cannot do their job. Secondly, the initialization
phase of the commit dialog may be sensitive in such a way that using these
features creates problems and could possibly crash some things. Disabling
them may prevent the user from crashing the program.
I can see a lot of practical reasons for having them disabled in this case.
However, disabling the items just because some of the items in the list do
not have a specific state is silly and doesn't accomplish anything. Clicking
a link that checks no items is not functionally different from that link
being disabled in the first place. Clicking it has no harm.
So graying out checkboxes is also less intuitive? Maybe we should remove all
> graying out in the entire application to make it more intuitive?
>
You're being too naive. You have to understand the design of a feature
before you can determine if it makes sense to have it disabled or not. Think
of how the feature would behave if it were not disabled when you think it
should be. Would it break the application? Would it cause any behavior that
is abnormal or harmful enough to mandate disabling it?
I will tell you this, and as I mentioned earlier with an example, some of
the checkboxes I've seen that get disabled really would be just fine without
being disabled. Of course, I am basing this purely on their behavior and
function. Stefan may have a specific implementation that has anomalies when
they are used in certain situations, but he will have to comment on that.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2355807
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-27 17:11:57 CEST