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

RE: [TSVN] Re: Keyboard Shortcuts

From: Flanakin Michael C Ctr HQ OSSG/OMR <Michael.Flanakin_at_Gunter.AF.mil>
Date: 2005-09-27 21:43:35 CEST

I agree with not wanting conflicting menu items. That's why my original request was to only have them for the TSvn submenu. If they were configurable, it'd be even better.

As far as requiring a reboot is concerned, it's already "required", so if they don't do it... Well, let me just whip out an old quote: Shutup and color :-)

Michael

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn@gmail.com]
Sent: Tuesday, September 27, 2005 12:49 PM
To: dev@tortoisesvn.tigris.org
Subject: Re: [TSVN] Re: Keyboard Shortcuts

Lübbe Onken wrote:

>> I raised the issue
>>{http://svn.haxx.se/tsvn/archive-2005-09/0340.shtml} a couple of weeks
>>ago. Stefan Küng cited l10n problems as one reason for not
>>implementing them (actually, removing them).
>
>
> What is the problem with l10n? Would that mean that the same keyboard
> shortcut like 'C' for Checkout would have to be used in each language?
> Then I can understand not implementing shortcuts.

It's a little worse than that actually (depending on the OS version).
If we define e.g. &Checkout and then the user switches to german, the 'C' will be active even though the menu now has &Auschecken. At least, until you reboot.

Also, when we first *had* those shortcuts, many users complained that their default shortcuts were now suddenly used twice (and I remember some very nasty insults in my direction from some of those people).

So you see: if I implement the shortcuts, I get slammed from those who don't like shortcuts doubled (something which we can't avoid 100%). If I don't, you guys complain.

(The song I'm listening to right now may be the most fitting to this situation ;) "EAV - Leckt's mi do am oarsch"
:) :)

> Would it make sense to add some default groups and allow people to
> freely move entries between groups. I suggest six groups, 0 being the
> windows context menu and 1 the current TSVN menu.
>
> 0) Windows context menu
> 1) TSVN -> (Help, Settings, About)
> 2) TSVN -> "Working copy" -> (Cleanup, Branch / Tag, Switch, Merge,
> Relocate, Export)

Ick! "Working copy"??
I can also check out a working copy, update, revert, ....
Almost *everything* in TSVN is working copy related.

> 3) TSVN -> "File/Folder" -> (Update, Commit, Diff, Revert, Rename,
> Delete, Add, Ignore, Update, Update to revision, Get Lock, Release
> Lock)

And again 12 entries...

> 4) TSVN -> "Information" -> (Show Log, Annotate, Check for
> modifications, Repository Browser, Revision Graph)

"Diff" would also be an information.

> 5) TSVN -> "Others" -> (Create Patch, Apply Patch)
>
> Did I forget any? This is an obviously debatable suggestion, but it's
> a suggestion. This is by no means the default layout that I'd suggest
> to ship with TortoiseSVN, just an idea how entries could be grouped.
> The default layout could have Update, Commit and Diff in Group 1. What do others think?
> Could be nice, but maybe it's not worth the effort.

Just FYI: such a change is not done right away. This requires a big change to how the shell extension now handles the context menu.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Sep 27 21:44:01 2005

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.