Steve Borho wrote, On 06/21/2009 11:42 PM: > On Sun, Jun 21, 2009 at 2:40 PM, Mads Kiilerich<[email protected]> wrote: > >> TortoiseHg uses hggtk and thgutil from the python package namespace without >> any good reasons. Please place all the the libs below the tortoisehg >> namespace - which also happens to be the name used by the egg. >> > This may not be a bad idea, if a bit pedantic. We can do it after the > 0.8 release. >
Oh yes. For py2exed installations it is indeed _very_ pedantic. For "real" installations in site-packages on windows together with some other applications it is slightly less pedantic. On "linux" systems thousands of independent packages must work together, so some degree of pedantic attention to namespaces is needed. And I would rather discuss it now than later on. ;-) >> It is a bit confusing that the rpm package "tortoisehg" mainly provides a >> binary called "hgtk". Perhaps it would be an idea to introduce the name >> "thg" and slowly move to that and deprecate "hgtk"? >> > hgtk is the GTK implementation of the TortoiseHg dialogs. thgutil has > utilities shared by hgtk, the nautilus extension, and the thgtaskbar > application on windows. There may be other implementations in the > future (Qt is being considered). > This is definitely your decision. But I would assume that currently, with hggtk being the only implementation and the command line command being a very usable interface to "tortoisehg", then it deserves to carry (a variant) of the projects name. If you should decide to switch to Qt (which I hope you don't) then I assume that you don't want to keep the GTK implementation. Which GUI toolkit is used is an implementation detail which shouldn't influence the user interface - except for the better, hopefully. It would be nice if your product - and "my" rpm - could provide the same command line interface anyway. (Distribution RPM packages will often be updated automatically without the user paying attention, so it is even more important than usually that the user interface and functionality doesn't regress or change without being backwards compatible.) >> A unix commandline tool like "hgtk" shouldn't fork. We need a way to disable >> that by default, prefably without patching the code. A setting in >> "__paths__.py" would be fine. >> > I beg to differ, many apps that are primarily GUI fork a background > process. Most GUI apps I know doesn't fork. They might however terminate early if they can convince an existing process do the work. Which examples do you have in mind? To me the main difference from most GUI apps is that hgtk is a GUI application which I actually would like to use from the command line. Unix shells always has the & to run an application in the background. Having forking built in is probably nice on windows, but having it enabled by default on unix is unconventional. IMHO. However, I mainly object because the nice error messages from illegal commands or options are written to stdout/stderr from the background process and hide the shell prompt, making it look like the process never terminated. If I hadn't been confused by this then I probably wouldn't have complained ;-) > As far a mechanisms to disable it, there's currently > --nofork and HGTK_NOFORK. Adding further options would be ok. > What kind of options do you have in mind? >> Is names like "__paths__.py" really a good idea? That kind of names are >> reserved for Python, for example there is thgutil.__path__ which is >> confusingly close to thgutil.__paths__. I would suggest using "custom.py" or >> "config.py" instead. >> > The underscores were mainly to indicate the file is machine generated, > like __version__.py. The exact name of it is not that important. > Yes, the name is not important. But it might be important that the name is reserved... ;-) And thanks for the fixes! /Mads ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
