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

List:       kde-devel
Subject:    Re: program loading
From:       "Patrick D. Dowler" <dowler () pt1B1106 ! FSH ! UVic ! CA>
Date:       1999-02-23 19:38:06
[Download RAW message or body]


>We need immediate feedback when an application is launched. I agree.

On a similar note, swallowed apps in the panel get sunk when you click
on them, but docked apps do not. Thus you cannot, for example, tell
if you have actually clicked on your kbiff to launch kmail.

Back to the main thread, the options appear to be:

1. Since kpanel launches the app, it should monitor progress.

        Some apps get launched from desktop icons, Alt-F2 (minicli?),
        or indirectly via swallowed/docked progs. Also, kpanel is
        getting pretty full as it is... X

2. Since kfm actually process the kdelnk for both kpanel and desktop
icons, it could do it.

        kfm doesn't deal with Alt-F2, and it is already pretty large and
        busy. It is a filemanager, ftp tool, web browser, and such
        already, after all... X

3. The taskbar could show loading (unmapped?) progs in a special way
to denote their status.

        The taskbar gets sooo large now that many people don't use it.
        I for one use the WindowList instead (from kpanel and MMB+root).
        Also, it currently doesn't do anything with non-GUI progs.

4. A "console" where apps (KApplication) can write a few salient
messages during startup and especially if they crash before mapping.

e.g.

	Kmail starting...
	KMail ready.

after which the kmail window should appear. It would be easy to
wrap non-KDE apps in a script that did this. All you need is a
named pipe to write messages to and a "ksystemconsolemonitor" that
reads from the pipe. To implement in KApplication, the constructor
could write the first message and exec() could write the second one.
*** This should not be used for debugging ***

5. A fancier "console" GUI which also allows one to kill things.

	We already have the very nice "kpm" which can send such
	signals. Also, kill is not necessarily the solution when
	a process fails/locks/hangs, so if you want the monitor to
	also provide a way to fix it, you are in for a large and
	messy task (can that prog add paper to the printer? just
	kidding :-)


thoughts?

Patrick Dowler

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