On Sat, 2009-02-14 at 11:27 +0100, Simon Heimberg wrote: > 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?
Nothing obviously wrong with it, except that we prefer lower case filenames. > 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 When nautilus-thg was first written, nautilus-python did not support submenus and so I shortened the menu options as much as possible. Now we do have submenus, but nautilus sorts them for us so we do not have as much control over them as we do on Windows. To pull them together, we should try to match nautilus-thg to the Windows menus in general. I think nautilus-thg does a better job of building context menus for selected files (offering only applicable choices), this is something we want to pull back to the Windows side. > How does caching work exactly? How do the variables stay there? Is the > python code loaded all the time while explorer/nautilus is running? As I understand it, Explorer.exe loads the tortoise module into it's process when explorer starts, and keeps it there until explorer exits. > Is there some caching in the nautilus code by keeping the repo? Which > mechanism is better? Keeping the repository object helps some. One important difference between Nautilus and Explorer is that Nautilus never seems to ask for overlays on directories. It only ever asks for single files in your current directory, so the optimal cacheing mechanism between the two of them may be different. I have very little knowledge about how cacheing is done on Windows, that has been TK's domain. > Is it important to delete the (repo) cache when > opening a dialog? On Windows, we use a notification technique in our dialogs to inform Explorer that files have changed state. Explorer in turn asks us for new overlays. In Nautilus, there is no way to trigger this, so far as I can tell. It's on the TODO list to figure out. There's been some confusion, historically, about how Mercurial deals with this. We've sprinkled repo.dirstate.invalidate() calls in various places to force Mercurial to take a new look at files. > Is caching important on Linux when the inotify > extension is activated? Not nearly as much, I expect. There's a long-term TODO to add inotify like support in Windows (the OS supports this feature). That would greatly improve the shell extensions. -- 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
