This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: weft 0.4
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