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

Re: TortoiseOverlay icon prio (Was: Re: Not all overlays appear on Windows 7 with TSVN 1.6.7+)

From: Adrian Buehlmann <adrian_at_cadifra.com>
Date: Wed, 17 Mar 2010 10:48:33 +0100

On 17.03.2010 08:17, Hans-Emil Skogh wrote:
>> I'm currently thinking of creating a patch for TortoiseOverlays, that
>> iterates through registry Software\TortoiseOverlays, counting only the
>> actually registered handlers there and use the actual number of handlers
>> in the max slot calculation.
>
> A suggestion: Maybe each installed client could add its prefered overlay
> priority to the registry.

This could be implemented by having the client handlers register their
COM servers under Software\TortoiseOverlays using a name 'foo-N' to
indicate priority class N.

For example, TortoiseHg would register its Normal handler under
'Software\TortoiseOverlays\Modified' using the name 'TortoiseHg-0' to
indicate that its Modified handler should have highest priority.

> Then TortoiseOverlays could calculate what
> icons that should go first for any given combination of installed
> clients on a machine.
>
> Each client would give a strictly ordered list of most important (lowest
> number) to least important (highest number) icon.
>
> For example (just an example, real prios may differ):
>
> TortoiseHG might order the overlays as:
> 0: Modified
> 1: Normal
> 2: Added
> 3: Unversioned
> 4: Ignored
> 5: Conflict
> 6: Deleted
> 7: Locked
> 8: ReadOnly

Ok. Putting my exact petition on the table:

On behalf of TortoiseHg, I can tell you that we would like to have the
following priority list (we only need 7 priority classes. Highest
priority is 0):

0: Modified
1: Added
2: Normal
3: Conflict
4: Unversioned
5: Ignored
6: Locked, ReadOnly, Deleted

That is, we would like to drop Locked, ReadOnly and Deleted before
anything else (since we have no use for them). We don't care in what
exact order these three go, but we prefer to not drop Ignored unless all
of {Locked, ReadOnly, Deleted} have been dropped first.

The current implementation of the TortoiseOverlays shim drops
Unversioned first on overpopulation. Which is quite hard to understand
from our perspective (given that we would drop a whopping four overlays
before proceeding to drop Unversioned -- if we were to decide alone).

Note that I'm not listing this petition in order to force my way through
here. I'm just depositing it here in the hope it is useful to find the
best solution for all.

> And TortoiseSVN:
> 0: Modified
> 1: Normal
> 2: Added
> 3: Conflict
> 4: Ignored
> 5: Locked
> 6: ReadOnly
> 7: Unversioned
> 8: Deleted

Could the TortoiseSVN project please publish its final most wanted
priority list here as well? Stefan?

> That would give a total priority of:
> 0: Modified
> 2 Normal
> 4: Added
> 8: Conflict
> 8: Ignored
> 10: Unversioned
> 12: Locked
> 14: ReadOnly
> 14: Deleted

Can you please describe the algorithm that calculates the total priority
for the most stupid average reader (=me)?

How is the question "Which overlay needs to go next?" answered?

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

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-17 11:19:14 CET

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.