Well you're the authoritative figure on the project :)
I guess this can't be done if the developers won't do it.
At the very least can we make "Close local operations" include the commit
dialog if there are no errors? Granted, commit progress is not a local
operation, however it has no special information in it worth viewing unless
it fails. It's literally showing me what I've committed when I've already
seen that in the commit dialog when I was typing my log message.
On Tue, Mar 31, 2009 at 2:07 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> void pointer wrote:
> > On Tue, Mar 31, 2009 at 11:30 AM, Stefan Küng <tortoisesvn_at_gmail.com
> > <mailto:tortoisesvn_at_gmail.com>> wrote:
> > Such buttons are ugly and never work properly for users who use
> > non-default themes or use theming applications.
> > You forgot to mention that it's functional...
> If it breaks on a lot of systems, I would not call it functional at all.
> > And how would users know about this? You know that users don't read
> > docs...
> > That's what static text is for. Have text above the OK button that says
> > "Shift+CLICK for auto-close settings"
> We will soon end up with something like this:
> > I have a hard time seeing the benefit of such extended auto-close
> > behavior.
> > Really? I thought I explained it quite well. What exactly are you having
> > a hard time seeing?
> > We already have fine grained auto-close behavior, admitted
> > one setting for all operations.
> > I've already established that it is NOT fine-grained. You give the user
> > a very limited set of auto-close options. I've already found 2 or 3
> > cases where I wanted certain auto-close behavior that TSVN did not
> But why? Is it so hard/annoying to click the OK button after the
> operation finished?
> I think it's way more annoying to see an option (no matter how it's
> implemented or what controls are used for it) in the progress dialog
> that is only used once (if at all) by most users but visible for every
> > But what's the big gain here?
> > Increase in usability and flexibility of TortoiseSVN. You seem to
> That's sales-people talk. Buzz words, but they don't tell anything.
> > pessimize this idea quite harshly. You have already acknowledged support
> > for auto-close behavior, since you already have some limited support for
> > it. However, with all do respect, it has been half-assed. I say that if
> > you do not implement the feature properly (and in its most flexible
> > form) you shouldn't have it implemented at all.
> I'm against implementing something that doesn't add value to most people
> but worsens the UI for all.
> Flexibility is good, but it must be limited and weighted against usability.
> > If you find that any ideas presented here you are unhappy with or
> > foresee issues with, then by all means help contribute some thoughts.
> > I'm sure you can come up with some great ideas.
> Yes, I'm not happy with this. And you expect me to present ideas to make
> it happen anyway??
> I'm arguing against it, for reasons I've explained.
> > There's a dialog staying open until you click OK, but that dialog
> > contains important information. So for me that's not a big deal at
> > But you do not determine what that important information is, the user
> > does. Errors are the only thing we can assume are "important
> > information". If you base auto-close behavior on important information,
> > then you need to let the user define what falls into the "important
> > information" category. Merges, for example, may be important information
> > for some people (and thus they would not want the dialog to auto-close)
> > but not for others. I need TortoiseSVN to be flexible to my needs. I
> > don't want any features feeling like a burden. Let me tell TortoiseSVN
> > when I want it to auto-close for each dialog in the most intuitive way
> > possible.
> Sure, it would be great if you could configure everything to your needs.
> But every feature requires code and an UI to configure it. For many
> people, there are already way too many options in the settings dialog.
> Adding more doesn't help at all.
> To keep the UI user friendly, we have to make it so that it works for
> 'best practices' and what's most common.
> Having the same dialog auto-close for different operations does not fall
> into that category. Also, having the dialog close automatically even if
> there were errors is something I will not allow, sorry.
> > If clutter is an issue for you, then simply add a static text as I
> > mentioned earlier that says "Shift+Click to set auto-close options"
> > above the "Close" button. In addition, add a special modal dialog that
> > pops up when you SHIFT+CLICK that has a collection of check boxes in it
> > that allow me to select the different types of information I do *not*
> > consider important and thus will auto-close for.
> > In the commit progress dialog, for example, I would uncheck everything.
> > This would mean that unless an error occurs, I always want the commit
> > dialog to close.
> > If you do not mind a little bit of extra clutter, then we can do a
> > little more than the static text and provide the check boxes right on
> > the dialog itself. However, I like the SHIFT+CLICK idea the best.
> If you can come up with a reasonable UI for the settings dialog, that's
> fine. But adding that to the progress dialog is simply wrong.
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
> To unsubscribe from this discussion, e-mail: [
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-31 21:54:18 CEST