On 16.03.2010 21:13, Adrian Buehlmann wrote:
>> I've decided to leave the max. handler check as it is for now. That will
>> give us 9 overlay slots even on win7 x64.
>
> With TortoiseOverlays 1.0.15, the unversioned icon still doesn't work on
> a pristine Windows 7 x64 (as already reported).
>
> So there must be some bug in your calculation.
The calculation is correct, but the load order isn't.
I've committed the change to use xTortoiseYYY as the registry keys, but
haven't yet made another overlays release.
>> If we want to remove one handler, I would suggest to remove the 'added'
>> handler and use the 'modified' handler for added items too.
>> Or the 'deleted' handler, since deleted files are gone, only deleted
>> folders would have that overlay.
>>
>> Or maybe not remove those handlers but just change the code so that
>> 'added' and 'deleted' are the first handlers to go, before the
>> 'unversioned' handler.
>
> Speaking for the TortoiseHg project, the locked handler is the one with
> zero prio for us, since for a distributed VCS, there is no locking.
>
> The readonly icon is useless for TortoiseHg as well.
>
> Deleted could go as well (provided we can have unversioned back - don't
> ask :-).
So we could change the priorities of the handlers to make the "deleted"
one go first.
> So, for TortoiseHg, we basically already have three completely useless
> icons eating up three slots (for the calculation, see below).
>
> Next one we don't use currently is ignored. But we might start doing so
> (in theory).
>
> Use of 'conflict' is planned (we plan for a conflict, hehe :-).
>
> We *do* use the added icon. I suspect removing the added icon wouldn't
> be that well appreciated by our users (BTW we had>10000 downloads for
> the TortoiseHg 1.0 Windows installers in 10 days. That means 10k
> potential more customers of TortoiseOverlays for you :-). But I agree
> that - in theory - the modified icon could be used instead of the added,
> if you really must remove the added icon.
>
> But I guess the priorities of TortoiseSVN are not the same as for
> TortoiseHg, which starts me thinking if a shared component for the two
> projects really continues to be such a good idea (at least for the case
> where there is no plan to install both Tortoises on the same machine).
>
> 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. Currently, TortoiseOverlays assumes that
> all of its own 9 icons are in use. Which is wrong for machines having
> only TortoiseHg installed.
>
> Like this, machines that only have TortoiseHg installed, could stop
> counting locked, readonly, etc.
>
> Would you accept such a patch?
Sure, if the patch is made so that it checks which clients are installed
and which handlers are actually used. But if it just changes the
component to work for THg and make it worse for TSVN, then not.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2460733
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-16 21:54:38 CET