On Tue, May 5, 2009 at 12:12 AM, TK Soh <[email protected]> wrote: > On Mon, May 4, 2009 at 5:59 PM, Steve Borho <[email protected]> wrote: >> On Mon, May 4, 2009 at 11:34 AM, Adrian Buehlmann <[email protected]> wrote: >>> On 04.05.2009 17:31, Steve Borho wrote: >>>> I'm pretty close to merging this work, I cloned Adrian's repository >>>> this weekend and took a look at it. >>>> >>>> The C++ work is still based on -stable, which will require a bit of >>>> fixup work, but that's not a big deal. I couldn't figure out from >>>> looking at the code how the new extensions are supposed to be >>>> registered or how they use the RPC server that's in the tortoise >>>> directory. >>> >>> I haven't looked into the details how this could be integrated with >>> current main development line of TortoiseHg, but as a side note, I'm >>> currently fairly happy with version 313005ffe01e of my repo [1] for the >>> overlays. >>> >>> My hackery is an experimental fork of TK's work, for which he provided >>> a how-to for developer installation here: >>> >>> http://www.mail-archive.com/[email protected]/msg03163.html >>> >>> After having compiled and linked the dll, I just started inno setup compiler >>> (version 5.2.2 here) and loaded the file tortoise/shellext/ThgShell.iss into >>> it and hit the run button to install the dll for development testing. >>> >>> Of course this requires the TortoiseOverlays package to be pre-installed, >>> as ThgShell.iss then registers the overlay handlers with >>> TortoiseOverlays (see registry.iss, HKLM\Software\TortoiseOverlays\Normal, >>> Added and Modified subkeys). >>> >>> I didn't care for the context menu at all yet, just noticed that they >>> seemed not yet to work entirely correctly (IIRC dialogs did either not >>> appear or things seemed somewhat broken) -- but the cmenu is there >>> and the context menu handler of THgShell.dll seems to work. I suppose >>> TK knows a whole lot more about that side of THgShell.dll. >> >> Ah, I understand some of the confusion now. TK's initial testing used >> the existing (<=0.7) context menu handlers and the compiled-in ones do >> not use the RPC server at all. >> >> I would like to keep our python context menu code for 0.8, but the >> version on crew is tied our python overlay cache. So it seems there's >> a few non-trivial tasks remaining on the menu side. >> >> Unless I hear otherwise, my steps will be to: >> >> 1) Reproduce your results on my development box >> 2) Pull the changes into crew >> 3) Fix the compiled in menus to at least launch the main GUIs properly >> (commit, log, sync, settings) > > They are working on my system. Not sure what problems Adrian is > facing. BTW, since you plan to keep the python context menu, any > reason to 'fix' this issue?
To have a functioning system for people to test with, before I get the RPC provided menus up and running. >> 4) Build an installer >> >> At this point, everyone else can try out the new overlays and we can >> hopefully get some good feedback. >> >> Then in stage two: >> >> 1) Borrow the RPC version of the menu server from tortoisebzr and hook >> it up to menuthg >> 2) Allow menuthg to work efficiently without the overlays seeding the cache >> 3) Build a 64bit version, fix any bugs it finds. > > Anyone has tried compile the C++ shellext with a 64-bit compiler > (mingw64?) ? Or it's not necessary? > >> 4) Build a 64bit installer >> >> At this point, there should be much rejoicing. >> >> Stage three: >> >> python setup.py py2exe -b1 (pristine install directory, goodbye issue #67) > > I don't remember very clearly, but IIRC, it was the conflict in python > library (thg and other applications use different versions of python) > that was causing the problem. If the python context menu is still in > used, does it really solve the issue? -b1 includes the python2x.dll in the library.zip file. There's a 50% hg and GTK will be ok with that configuration, but issue #67 is mostly about removing python out of the shell extensions. Moving the menu code to the RPC server means that python is not being loaded into every process that opens a file browser. -- Steve Borho ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
