Steve Borho wrote, On 06/23/2009 04:27 AM: >>>> 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. >
(First some notpicking: On my machine firefox never forks and terminates - but if another process is running then the task is handed over to that and the command terminates. Emacs doesn't start in the background for me - but the man page explicitly says "You will probably want to start the editor as a background process so that you can continue using your original window.") Ok, you convinced me that gvims behaviour is good. It seems like gvim doesn't fork before it really is ready to start a gui, i.e. after command line parsing. If would be nice if hgtk could do the same. The following example shows a difference: [...@localhost ~]$ gvim --badoption VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Mar 27 2009 07:49:09) Unknown option argument: "--badoption" More info with: "vim -h" [...@localhost ~]$ hgtk --badoption [...@localhost ~]$ hgtk: option --badoption not recognized Hgtk - TortoiseHg's GUI tools for Mercurial SCM (Hg) ... use "hgtk help" for the full list of commands or "hgtk -v" for details /Mads ------------------------------------------------------------------------------ _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
