On 16.03.2010 20:18, Stefan Küng wrote:
> On 15.03.2010 23:32, Adrian Buehlmann wrote:
>> On 15.03.2010 20:51, Valik wrote:
>>> On Mar 13, 7:30 pm, Adrian Buehlmann<adr..._at_cadifra.com> wrote:
>>>> I'm not convinced that asking the user is a good idea here.
>>>>
>>>> Given Stefan's approach, the unversioned overlay is simply unusable,
>>>> because it will never be initialized on Windows 7 and thus defunct.
>>>
>>> Right, that's my point. On Windows 7 the overlay is unusable. It
>>> would be rude of TSVN (or anything using TortoiseOverlays) to just
>>> unregister a Windows built-in overlay to make room for the Unversioned
>>> overlay. For various reasons it's also impractical to say "It's
>>> there, you want to use it, delete something on your own". Removing
>>> the overlay as you suggest is certainly one option but the other
>>> option is asking the user in a manner I outlined above. Leave it up
>>> to the user to determine how they want TSVN to behave. I realize
>>> those of you who use the TortoiseOverlays module are still out of luck
>>> because, as Stefan mentioned previously, it does not have a GUI
>>> component. However, surely there's some way for Stefan to provide a
>>> re-usable installer page and pass the settings selected on that page
>>> to the TortoiseOverlays module? Even if it's going old school and
>>> requiring those of you using TortoiseOverlays to copy a block of code
>>> into your installers to get the page, it's still better than removing
>>> the overlay.
>>>
>>
>> I've removed usage of the unversioned overlay from TortoiseHg
>> completely. This will be released in 1.0.1, which is due on April 1st.
>>
>> So I don't care that much any more (besides the fact that I would be
>> interested in TortoiseOverlays not counting a slot for the unversioned
>> overlay handler, since we don't use it).
>>
>> The numbers of overlay icons "provided" by TortoiseOverlays is too large
>> anyway IMHO. And as we have seen, this has consequences.
>>
>> The fact is that there are too few available slots on Windows (and even
>> fewer on Windows 7). So better don't pretend that TortoiseOverlays can
>> take a whopping 9 of them.
>
> 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.
> 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, 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?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2460716
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-16 21:22:13 CET