[Usability] GNOME Applications and the Shell Environment



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]