Am Freitag, den 13.02.2009, 23:34 -0600 schrieb Steve Borho: > On Fri, 2009-02-13 at 17:04 +0100, Simon Heimberg wrote: > > The path of hgproc.py is read from an environment variable or hard coded > > in nautilus-thg.py. > > New approach: place hgproc.py in the python path. Import a small module > > which is in the same place. Get the path of this module by calling its > > __file__ property. Replace the filename with hgproc.py. > > The current behaviour can be used as a fallback. > > We spoke briefly about this on IRC this afternoon, but the gist of this > issue is that on Windows, hgproc.py is converted into an EXE and thus > this method of finding it (as clever as it is) would be unhelpful.
This would only be implemented in nautilus-thg.py, the code for Windows would not change. > > In the long run, I think hgproc.py is becoming redundant and we should > try to transition all of the shells to launch their dialogs via hgtk. > I agree, the scripts hgproc.py and hgtk have similar code. Then we should search hgtk in PATH (As windows does for hgproc.bat/exe). > > There is currently no tortoise module which must be imported by > > nautilus-thg. But I hope there will be soon. I think it would be an > > advantage to share code between linux and Windows. I try to extract the > > os independent parts for menu creation and caching. So everybody would > > profit from menu improvements. > > Maybe hgproc should be in the same directory as this new ones. What name > > do you suggest? tortoise is used for windows. Is thgcommon suitable? > > There's a long-standing wish to split the Windows shell extensions into > a small C++ core that is loaded by Explorer and speaks COM, and a python > library or executable that actually interfaces with Mercurial to cache > dirstate and generate meaningful context menus. > > I don't know if this idea has expanded beyond the wish stage, but any > attempt to refactor the tortoise/ module to make it usable by other > shell clients should definitely take this into account. > Having the commands which built menus (actually _get_commands_dragdrop and _get_commands in tortoise/contextmenu.py) in a separate module (menuThg?) does IMHO not interference with this. The cache is in the method _get_state of tortoise/iconoverlay.py. Most of this code would go to a new module (cacheThg?). The python library or executable would contain two more modules. I do not think that there would be more change. Is this problematic? Subtopics: How should the menu look like? Windows and nautilus have different ones. Some differences: commit before / in the submenu, separate entry for diff and vdiff / one diff entry, config in an own submenu / in the submenu How does caching work exactly? How do the variables stay there? Is the python code loaded all the time while explorer/nautilus is running? Is there some caching in the nautilus code by keeping the repo? Which mechanism is better? Is it important to delete the (repo) cache when opening a dialog? Is caching important on Linux when the inotify extension is activated? > I have nothing against the tortoise/ package being installed on > non-windows platforms if one or more of the files in there is generally > useful. If we were to create a new package for this, it would probably > be named something like hgdscache, but this probably won't be necessary. > > TK, do you have anything to add to this? > > -- > Steve ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
