[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 106290] watch the processes which are created by a started
From:       Hauke Laging <hauke () laging ! de>
Date:       2008-06-01 0:04:07
Message-ID: 20080601000407.29822.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=106290         
hauke laging de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |



------- Additional Comments From hauke laging de  2008-06-01 02:04 -------
I have been to the Linuxtag fair in Berlin today and talked about this problem with \
several people at the KDE booth and even with those from Gnome (where the KDE guys \
sent me to in order to check how the rest of the world handles this).

The results:
1) EVERYONE has accepted the problem. I still experience this with kmail/kontact, the \
other ones mentioned Amarok as a frequent source of this problem.

2) MacOS (really, hard to believe...) ALREADY does something similar (the Gnome guys \
said). There the process start up feedback is directly related to the process state \
(in contrast to the one in KDE...) and you are given the possibility to kill a \
process even before it has opened an X Window (after that it can be killed in Linux \
by <Ctrl>-<Alt>-<Esc>).

3) The Gnome guys admit that the solution should be located central in the \
desktop/window manager. One of the KDE guys holds the argument of comment #4 - that \
one should rather fix the bugs in the applications than create such a generic \
"solution". But he himself pointed out that he had reported this problem several \
times to the Amarok developers without them having fixed it yet. The other KDE guys \
hold my opinion (which doesn't prevent application bugs from getting fixed, of \
course).


I would like to make a comparison with other levels of software. Refusing this kind \
of control in the instance starting other processes (the desktop in this case) would \
be equivalent to the X Server refusing to kill a dead window (which can be done by \
<Ctrl>-<Alt>-<Esc>; "Why kill the app if you can kill the whole X server and login \
again?").

The other analogy: Imagine the kernel would not allow you to kill processes. "Why be \
able to kill processes if you can reboot the system instead?" It is obvious that such \
arguing would be rediculous. It seems very strange to me that what is obviously for \
the kernel and the X server should be the opposite(!) in an analogous situation, just \
at another software level (desktop manager).

If we all relied on the quality of software we could still use DOS - because who \
needs any kind of forcable control if every component of the system is supposed to be \
cooperative (which implies "bug free")?

And besides the theoretical arguing: If EVEN MacOS offers that (and Gnome might in \
the future) it is obvious that this would be a good addition to KDE.


[prev in list] [next in list] [prev in thread] [next in thread]