weft 0.4

[Frank Fesevur]

At 30-10-2006 18:12, Dave wrote:
> Comments on the package itself:
> 
> 1. You've created a C++ program that essentially is just writing to the
> registry. Have you considered scripting it instead? Then you can leave
> the registry handling to regtool.

There were two main reasons for me to choose for C++:
- I know I'm better with C++ then with bash scripts (it's always good to 
know your own limitations ;-)
- When I saw the quoting nightmare (as you say in your own comment) you 
had to get the shell for the 'passwd', I knew when I write directly to 
the registry it would less of a problem.

> 2. You have hardcoded the bash invocation line.

Sorry, but I don't understand it. I think it is because English is not 
my native tongue, but what do you mean with "bash invocation line"?

 > It took a while to get
> it right with chere. Issues that you'll find with the invocation you're
> using:
>   a) won't work on scripts in network paths
>   b) won't play with ash or tcsh. Not a problem now since you're only
> supporting bash.

The only reason I didn't add other shells yet, is because I don't have 
any experience with them. When you look at the code you see in 
SetShell() other shells can be added without much problems.

>   c) I don't think this plays well with spaces or '$' in a path (but I
> could be wrong). Note '$' is commonly found in MS hidden network shares.

It is no problem to start a script when spaces in the filename. I just 
tested and indeed it does not work when the script is on shares.

> 3. You're starting a login shell for every script you want to run.
> Probably fine on a modern machine, but there's always someone trying to
> eke out a performance gain.

You got a point.

> More general:
> 
> weft will manage invoking scripts (or programs) which do not require
> additional arguments directly from a particular shell. To add the
> ability to handle a type of extension that does not want to be executed
> by a shell (say for .pdf), the source of weft will need to be patched
> and recompiled (and run to add the handler).

I don't know if many would want to do this with a cygwin app, but then 
again, many most people here in cygwin-apps don't feel the need to start 
a script from the Explorer.

But I don't see the problem of this. It goes for almost any package that 
you need to recompile to add functions. And why not have an option to 
specify a path the start when you add an extension.

> My feeling is that we need to have a single package which manages all
> the explorer extensions anybody may want to add. I don't think the
> package as proposed can easily be made to do this.

Sounds like a good idea to me.

> Together with the fact that I've never felt the need to execute a script
> directly from Explorer, weft doesn't get my vote as it stands.

But when I look at the reactions I got IRL and the fact that is has been 
discussed on the lists before, I think enough people do like it. I know 
the 0.4 version is not yet a general releasable version. It does not 
have that version number for nothing ;-)

> I have a work in progress which could do the generic management of
> explorer extensions (see link below). As is typical, I haven't had time
> to perfect it - but by all means, have a look at what I've done and
> between us we might get this functionality into cygwin.

I have looked through the archive before I started coding. I found the 
message I mentioned in my readme, but I missed that one :-(

I don't mind to drop weft and help to make the new package. My reason to 
write is, was to have the functionality. It doesn't have to be weft if 
there is another/better way to do it.

I will definitely take a closer look at your code.

Just two minor remarks. I'm personally not that much a fan of tray 
icons. I already have way too much on my machine. And I don't think .xpi 
is a good extension as it is already used for Mozilla extensions.

Regards,
Frank