On Mon, Jun 22, 2009 at 6:35 PM, Mads Kiilerich<[email protected]> wrote: > 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.)
Even if we did do a Qt port, I would not eliminate the GTK version. There's 2-3 years of good work there. So at worst we would add another executable for the Qt version. But you do have a good point, it would be good to plan ahead and have a program name that is independent of the implementation. >>> 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? gvim, firefox, emacs. I consider gvim an especially apt example. Vim does not fork, it is equivalent to hg log. gvim does fork, it is equivalent to hgtk log. > 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. I found that I preferred it to fork, just to save from having to open another shell window. hgtk doesn't interact with the console once it's launched. But it is a personal preference. > 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? We usually put things like this in ~/.hgrc under the [tortoisehg] section. Seems reasonable to add options for nofork and stderrcapture. >>> 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... ;-) Now is the time to change this, as well. config.py doesn't seem too bad. -- Steve Borho ------------------------------------------------------------------------------ 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
