On 04.12.2009 11:13, Adrian Buehlmann wrote:
> On another note, I've started to think about extracting the thg shell
> extension
> into a wholly separate independent from TortoiseHg project, which builds a
> separate installer containing only the shell extension and the rpc server.
> If TortoiseHg decides to kill the shell extension, people could continue
> to use that then. If TortoiseHg agrees to use it, it could install that
> with its installer. So the installer layering would be:
>
> layer 3: TortoiseHg (containing hgtk + cli hg)
> layer 2: thg shell extension + rpc server
> layer 1: TortoiseOverlays (as provided by the SVN project)
>
> Preferrably, this would be packed into an msi installer package, using the
> WIX tools (like it is used for the TortoiseOverlays package we depend on).
>
> Maybe I should extract the currently hard coded cmenu config out of the code
> into a file that is read by the shell extension on init while I'm at it (would
> contain the ui strings, icon file names and the exact command line that is
> started).
Actually, the package split/hierarchy/dependency might probably rather look
like this:
(B) New TortoiseHg installer (adding shellext overlays and cmenu, rpc server)
| \
contains contains
| \
(A) Stripped-down old TortoiseHg (hgtk + hg) (C) TortoiseOverlays
(A) is Steve's current TortoiseHg, minus context menu and overlays, containing
only hgtk and command line hg, mercurial extensions, add-on tools (kdiff,
plink, etc)
and mercurial.ini. No Windows shell extension at all.
(B) is a new TortoiseHg installer and project, which uses A and adds the
Windows shell extension dll (THgShell.dll), providing context menu and overlays
(separately selectable on install). The rpc server belongs into B and is only
installed if the user wants to have overlays, in which case the TortoiseOverlays
package C is installed as well.
B contains A and C, so B depends on A and C.
A does not depend on B or C.
A, B and C are all Windows installers. So the installer B contains installers
A and C. B installs A (and C, if needed).
The key point is, that A does not install any shell extension at all.
After all, the cmenu (in B) calls hgtk (from A).
The sources for the shell extension could then be removed from project A
(the current TortoiseHg) and moved into a new project B (the new 'TortoiseHg').
C is the existing TortoiseOverlays package, as provided by the TortoiseSVN
project.
If A releases a new version, B will make a new release as well, containing the
new A release. If there are independent bug fixes for the shell extension dll,
B may do additional releases (if needed).
A could be installed without needing 'Power User' privileges. If a user just
wants command line hgtk and hg without the Windows shell extension, then
installing
A is sufficient.
Installing B requires Power User privileges, because it requires changes
to the registry (Local Machine) to register the COM servers for the cmenu
handlers
and overlay handlers. TortoiseOverlays needs Power User privileges for the same
reason.
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Tortoisehg-discuss mailing list
Tortoisehg-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
