Hi,

On Sun, 27 Jan 2008, Kirill wrote:

> > -----Original Message-----
> > From: Johannes Schindelin [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, January 27, 2008 6:17 PM
> 
> > Should not all of install.reg [and uninstall.reg] be converted in one 
> > go, rather than only a few?
>
> That sounds like a fine idea, but does not seem to be pressingly 
> important. AFAICT, there are couples ways to do it:
>
> - store our .reg files in the resources and invoke regedit 
> appropriately; cons: is regedit.exe guaranteed to be present on each 
> system?
> 
> - (as you mentioned) store registry as key-value pairs in resources and 
> implement simplified regedit engine.

I'd rather not have them as "resources", but as hard-coded keys, with a 
_very_ minimal regedit engine.

> > I imagine that a key/value array would be needed; however, this is not 
> > as trivial as it sounds, since we have different settings depending on 
> > the mode we wish to install: for all users, for one user, or debugging 
> > settings.
>
> Well... as I discovered today, the difference between "all users" and 
> "current user" is just the first parameter to 
> RegCreate/Set/DeleteKey/Value (HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER). 

AFAICS there are two different root keys in install.reg.in: 
HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT.  You mean that the 
HKEY_CLASSES_ROOT is not to be changed for user-only settings?

> As of debugging settings we can just use command line option, as you 
> suggested, and handle separately.

Yes, that sounds sensible.

> > For that matter, can you pass command line options when registering 
> > the .dll?
>
> Technically you can, but I'd rather limit this use to "for-developers use".

Of course!  So... should the default be per-user, with two different 
options triggering system-wide, and debug settings, respectively?

> > > +#include <stdio.h>
> > Do you use it?
> Seems like sprintf defined there.

Ah.  But should this not be constant?  I.e. have something like this:

-- snip --
diff --git a/ext.h b/ext.h
index 4cf3549..4cf2163 100644
--- a/ext.h
+++ b/ext.h
@@ -15,6 +15,9 @@ static const CLSID CLSID_git_shell_ext = {
        {0x85, 0x37, 0x72, 0x67, 0x24, 0xdf, 0x69, 0x29}
 };
 
+const char *git_shell_ext_clsid_string =
+       "ca586c80-7c84-4b88-8537-726724df6929";
+
 static const IID IID_git_shell_ext = {
        0xca586c81, 0x7c84, 0x4b88,
        {0x85, 0x37, 0x72, 0x67, 0x24, 0xdf, 0x69, 0x29}
-- snap --

> > > + char path_to_value[MAX_PATH]; // more than necessary for registry 
> > > key
>
> > There's a line wrap here.  You are sending via GMail's web interface, 
> > right?
>
> Usually, I am using Google Groups to start a new discussion. Sometimes, I
> reply through their web interface.

Ah, I understand.  Because AFAICT GMail's plain text web interface no 
longer line-wraps.

> > That's basically the reason why I left this for a later stage...
>
> Don't NOTES represent "The Plan"?

Heh, that was written by Brian (I would have written a file "TODO", and 
the NOTES would contain instructions how to get started, what the coding 
style is supposed to be, and a long term vision).  Unfortunately, it seems 
that Brian has lost interest.

So I am very happy to take (even incremental) steps to those goals 
outlined in "TODO".

But one thing that I find more interesting than the installation procedure 
("cross a bridge when you stand before it, not miles before that") would 
be to design an elegant way to call "git rev-parse --show-cdup" in the 
current directory (which would be the item itself if the user clicked on a 
directory, but the parent of the item if it is not) to see if there is 
already a repository (exit status 0 means "yes").

Then we could have a proper "Git" submenu for existing repositories, or 
"Git Init Here" and "Git Clone Here" if not.  Maybe the "Git Clone Here" 
only if clicked on a directory.

But the big thing here would be to have a nice an easy menu system 
(wrapping those horrible OLE interfaces).

Another thing will be to detect the MSys path automatically: if 
../bin/git.exe or ../../bin/git.exe exist (relative to the .dll path), 
then we found the MSys path.  But this will have to wait until we made 
git-cheetah an official submodule.

Ciao,
Dscho

Reply via email to