On 05.05.2009 17:45, Steve Borho wrote: > On Tue, May 5, 2009 at 10:30 AM, Adrian Buehlmann <[email protected]> wrote: >> On 05.05.2009 16:54, Steve Borho wrote: >>> On Tue, May 5, 2009 at 1:56 AM, Adrian Buehlmann <[email protected]> wrote: >>>> On 05.05.2009 08:04, Steve Borho wrote: >>>>> -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. >>>> I am confused. >>>> >>>> Why is there any need to "move menu code" into a separate RPC server >>>> process? >>>> >>>> TK's C++ shell extension work includes a context menu handler >>>> programmed in C++. >>>> >>>> If we combine that with my C++ overlay code we have a complete >>>> solution for context menu and overlay icons, all done in C++ in >>>> a dll loaded into explorer (and loaded into applications, if they >>>> use file open dialog). >>>> >>>> So there is no python left to be loaded into explorer >>>> (or applications) any more. >>> This gets back to Mark's original e-mail. I don't want to have to >>> maintain the context menus in C++ in perpetuity. There's a lot of >>> ugly details that are much easier to deal with in Python. Having >>> minimal builtin menus is fine for the short term, but eventually I'd >>> like to have a Python process serve up the menus (over a pipe, so >>> python doesn't infect the application). >> This does not make much sense to me. I never heard of a software >> that needs a server process just do something as simple as a >> context menu. >> >> I don't think that maintaining/expanding C++ would be a problem here, >> since adding/changing menu entries or icons would be trivial, >> even for programmers that have never written a single line of >> C++ before. I'm sure this could be organized as some script >> like area in the C++ (or even moved into an include file). > > There's more intelligence in our menu code than just building static > menus. We're adding/removing menu options based on the files selected > and the state of the repository. There's also i18n issues, and > configurability (on crew you can pick which options are promoted to > the top menu).
If I need a server process just for that, I can well waive such features. And who said we can't configure the C++ shell extension? But I'll stop banging that C++ drum now... (er, well we might even read the menu strings from a resource-like file, but, whatever...) >> But we will see how your "interim" step goes. I'm currently just >> interested in that. Maybe I can then continue to use (fork?) it while >> you take the-python-server-for-the-cmenu route later ;-) > > Feel free to beat me to this interim step :) We'll see. ------------------------------------------------------------------------------ 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
