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. -- Steve Borho ------------------------------------------------------------------------------ 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
