[python-win32] killing overlay extensions

[TK Soh]

On Tue, Jul 8, 2008 at 7:08 AM, Mark Hammond <mhammond at skippinet.com.au> wrote:
>> I am trying to provide a way for user to [totally] disable the overlay
>> extension, and enable them later if they want, without having to go
>> through the pain to remove the shell extension from windows registry.
>
> Why is removal from the registry a pain?

Technically, probably not so much. But right now overlay extension
read the config file to enable/disable the extension. It simplifies my
work if I am allow to 'kill' the extension that way.

>> > If you want something specific to your app, then your shell extension
>> code
>> > could check some kind of flag/event/whatever and then refuse to do
>> anything
>> > - but that isn't "killing" it.
>>
>> I am doing that already, but unfortunately that's still slow Explorer
>> noticeably.
>
> That is strange - do you think that is simply the overhead of calling Python functions?
>
> [apols to the list for the following, which is really getting off topic for python-win32]

I think this discuss might interest others on win32.

>>
>> > BTW, have you been tracking the shell extension code for bzr?  It
>> shouldn't
>> > be that far from being VCS agnostic and a first cut has been released
>> and
>> > pushed (I'm assuming you are still playing with shell extensions for
>> > mercurial :)
>>
>> I am afraid I haven't. When can I find the new shell extension code
>> for bzr?
>
> It is a launchpad branch at https://code.launchpad.net/~tortoisebzr-developers/tortoisebzr/tbzr2-proto - note it is still very early though.

I will try take a look if I can download it. BTW, can I browse this
bzr repo with a web browser?

>> BTW, is it written in VC?
>
> Not yet, but all VCS work is done by the remote process.  In other words, we are very close to being able to throw away the .py version of the shell itself and replace it with a dumb VC version.  However, it is likely we will not attempt to do that until a little later - once we have more functionality in place - so that we have a complete picture of what the C++ code must do...
>

FYI, I have actually completed the a simple prototype with overlay
extension, written C++, that retrieve Mercurial file status from
remote process through a named pipe. Is really a prove-of-concept
trial based on your proposal earlier.