On 17.03.2010 18:52, Stefan Küng wrote:
> 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. Then TortoiseOverlays could calculate what
>> icons that should go first for any given combination of installed
>> clients on a machine.
> [snip]
>
> Very bad solution. Because it is too complicated to explain to a user.
I haven't even seen myself how it is supposed to work. So I have to
agree that it is complicated.
> Which means we'll spend a lot of time dealing with problem reports from
> users about the overlay icons.
> If it's not fixed which overlays get dropped first, we'll spend a lot of
> time first figuring out what clients the user has installed and which
> versions of those clients.
>
>
> How about this 'drop order':
>
>
> locked : files that are locked are also shown in the commit dialog, so
> users don't really need to see that they still have a lock on a file
> with an overlay.
>
> ignored : not really necessary. Items that are not ignored show up in
> the commit dialog too (if configured that way), and together with the
> 'unversioned' overlay the 'ignored' is redundant (the opposite).
>
> readonly/needs-lock : who opens the files to edit from explorer anyway
>
> unversioned
Very nice. This would be a massive improvement compared to the status
quo (speaking from my TortoiseHg bias). Quite close to my postulated
(TortoiseHg) ideal.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2461213
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-17 19:30:55 CET