Hi, On Mon, 28 Jan 2008, Kirill wrote:
> > -----Original Message----- > > From: Johannes Schindelin [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 28, 2008 6:26 AM > > > > > 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? > > What I meant is basically that HKEY_CLASSES_ROOT has an alias at > HKEY_LOCAL_MACHINE\Software\Classes, which is "awfully alike" to > HKEY_CURRENT_USER\Software\Classes. Ah, thanks. That I did not know. > The above story is meant to demonstrate that a static array as follows is > enough to cover "current user" and "all users" scenarios: > > const char mykeys[][] = { > { "Software\Git-Cheetah", "PathToMsys", "../.." }, > { "Software\Classes\CLSID\{ca586}", "", "Git-Cheetah" } > }; Right. > > > > 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? > > We can try to be "smarter" and by default try system-wide first, go to > per-user if failed. And have three options to force a particular type > (e.g. debug settings). > > However, I'd rather leave debug settings only in the Makefile (as the load > target). Well, I would like to have it as a command line option, so that you can build on one machine, sneaker-net the .dll to another machine, register it and test it easily. Even if you have to test multiple versions ;-) > > > > > +#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"; > > + > > -- snap -- > > But what about DRY? I do understand that chances to change CLSID are > slim-to-none (they better be none, period), but nevertheless, I'd rather > include stdio than risk de-sync two CLSID's. You're probably right. > > But one thing that I find more interesting than the installation > > procedure > > Would you mind to finish and close the discussion about the registration > (installation), just for a sake of, for example, my own education? I > feel that I need to learn so much that it would be hard for me to design > a wrapper around horrible OLE interfaces __and__ learn how to work on > Git at the same time. Hey, if you want to finish the installation procedure first, that's alright with me! > > But the big thing here would be to have a nice and easy menu system > > (wrapping those horrible OLE interfaces). > > I agree. Do you have something in mind? Or we just need to start from > scratch? I'd rather continue as we do it now: access the OLE interface directly. For example, I imagine that it would be relatively easy to extend menu.[ch] so that it has a private pointer to a structure which tells it what menu items to show. Ciao, Dscho
