On 07.12.2009 19:18, Steve Borho wrote: > On Mon, Dec 7, 2009 at 4:12 AM, Adrian Buehlmann <adr...@cadifra.com> wrote: >> On 07.12.2009 02:49, Mark Hammond wrote: >>> On 4/12/2009 9:13 PM, Adrian Buehlmann wrote: >>> >>>> 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). >>>> >>>> (Sigh, looks like quite a bit of yet more unpaid work). >>> Has any more thought been given to moving to something closer to bzr's >>> tortoise environment as discussed here earlier this year? Bzr has made >>> alot of progress over the last year and has resolved some long standing >>> integration issues - they even recently made changes to it can be built >>> with the free version of MSVC. >> Microsoft now ships the fully optimizing C++ compliers (64 and 32 bit), >> linker and nmake with the Windows SDK for Windows 7, which is gratis for >> everyone to download from Microsoft. >> >> We recently switched to using that. Visual C++ is no longer needed at all, >> not even the Express edition. >> >> See win32\shellext\README.txt in the sources for the details. >> >>> This would seem to solve the problem of hard-coded menu items and make >>> the more complex bits of this easier to maintain - as little written in >>> C as possible, potential for code (and therefore debugging and >>> maintenance) to be shared with other similar projects, all menus etc >>> being handled by the Python implemented taskbar process, etc... >> We have no C sources in the shell extension. Everything is in C++. >> >> The taskbar process is in Python here as well. >> >>> While I haven't looked at their code in about a year, I do see evidence >>> (via bugs being closed) of it progressing well... >> We have made quite some progress as well. >> >> For example, we had a longer standing bug on Vista and Windows 7 regarding >> drawing icons in context menus, which I didn't care much about, since I am >> not >> interested in drawing icons in context menus (I would have removed them). >> But this has now been fixed by others by using the new Vista specific custom >> menu drawing API. It seems to work fine (as I've seen on Vista 64 bit, >> I have no access to final Windows 7 here). >> >> I think we have no other cmenu issues open? > > There's a couple of minor ones. #69 and #154. We don't get a lot of > complaints about the menus being statically generated. I suppose it > annoys a few people, but not enough to file a bug or join a mailing > list. > > It sounds like a good idea for the shell extension to get at least the > initial hard-coded menus from the RPC server, since it has direct > access to our translations. We could do away with the need for > registry files.
Reading a file from the shell extension directly would be much simpler. Pulling the contents a file through the series of both pipe and RPC server seems rather pointless to me. It only creates new unwanted dependency onto the RPC server and needless complexity. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Tortoisehg-discuss mailing list Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
