Hello, My application is a GUI designed especially for GNOME. Thus, when my application is launched, I register it with the GNOME libraries and then instruct the kernel to create a separate process for the application. The procedure is called forking. The effect of this is that when my application is launched from a shell terminal, the kernel detaches it from the shell terminal's process, therefore making the application run in its own process.
Apparently, this has offended some geeks who argue I am breaking some pointless UNIX convention. Their argument is that most (GNOME) applications do not detach from the shell terminal when run from it. And by detaching from the terminal, not only am I creating inconsistencies, but also creating an element of surprise. My response is that this behavior is a hold back from the days when UNIX had no GUI and when almost all applications that ran on it were console applications. The only environment a console application can run in is in a shell environment. That is why console applications have every right to "hug" the shell terminal. Also blocking the shell terminal is the only way console applications can recieve input from users. Graphic user applications, especially the ones designed for "desktop environments" have virtually no reason to be bound to a shell terminal's process. In particular, the only environment a GNOME application should be bound to is the GNOME desktop environment. And I believe you do that by registering with the GNOME and/or freedesktop libraries. In fact, I argue it is bad practice for GUI applications to be bound to a shell terminals process because if the terminal's process dies for any reason the application(s) bound to that terminal dies along with it. In my early linux years, I have lost documents this way. I launched several via the shell terminal, and then I forgetfully or accidentally close the shell terminal's window. Miraculously, all my applications disappear. Also, most graphic user applications are not console applications and as such the life-cycle of such applications should not be determined or controlled or constrained by shell terminal's process running in the sight of users that can easily be killed accidentally or otherwise. The geeks' counter responses ranged from questioning my competence as a shell terminal user, to suggestions to reconfigure my shell properties, to changing my shell environment, to connecting my application to the kernel's KILL signal so it can save its state before dying, among several funny comments. In fact, there's only one reason to provide an option for not detaching. Some console applications may need to pipe their result to my application. And my application needs to be connected to the shell's process for that to be happen successfully. There are many other silly UNIX conventions that are a hold back from yesteryears which bite us in the behind today. I recommend the "UNIX Haters Handbook" for an exhaustive listing. Yet many people religiously clinge to them without reason. I feel this issue is one them. Is it advisable to encourage developers via the HIG to avoid hugging the terminal. I mean, apart from the fact that it is just pointless especially for GUI apps, there's also the possibility of losing applications bound to the terminal's process when the terminal quits for whatever reasons. And why on earth would anyone want to bind a GUI app to the process of another user visible application? I bring this up here because the geeks say I am trying to "fix" the problem the wrong way. They insist that the problem, if at all it is one should be "fixed" at a global level outside my application. I'm guessing perhaps at a library level. So, I welcome your comments and thought on the issue. My opinion is that the default behavior for GUI applications, GNOME in particular, is to detach from the shell terminal, while an option to prevent detachment should be provided for those who need it. A positive side effect of my suggestion is that it frees the terminal to be used by other applications designed for terminal usage. Cheers _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
