Edit: Already trashed, so ignore the window preview thing

-----------

When I read the thread about the "Bouncy Cursor" status indicator (https://forum.kde.org/viewtopic.php?f=285&t=125090), I thought "This could be extended to a more general approach concerning the general system of application startup notification", so here my ideas:

Note: My ideas could be confusing, have holes, could be extremy complex to implement .... maybe I can input something to inspire better ideas
Also I don't know if some functions I suggest may be already implemented


First - What's the goal of an application startup indicator?
I think the goal should be providing information that an application is starting without making the impression that the system hangs/lags.

Current behaviour
There is a status indicator waiting until a window is created (?), if not, it runs until predefined time (e.g. 10s)

Currently there are two indicators (afaik):

• Bouncy cursor (or more)
• Task Manager rotating thingy indicator

Problems with current behaviour
Note: Only from user side of view - just ignoring the technical restrictions for this

• If an application fails to start, the indicator runs until eg 10s and nothing more happens -> user confused
• Some applications will take more time to load than the status indicator runs -> the user thinks "WTF?! Is my computer hanging?"
• Applications started from launchers (e.g. Steam) are not indicated -> If a game needs some time to load, the user thinks that the computer hangs

Solution?

The technical problem is obviously: We don't know which behaviour of a programm is expected.
Should it create a window? Is this program just running for a short time and closes itself? Will the program minimize itself to the tray? How do we detect "spawing" applications from launchers such as Steam? How do we separate them from helper programs?

A key aspect could be the creation of a window (or a tray icon, but I focus on the window)
If we know that a program usually creates a window, we can expect a window and maybe add some additional effects (see later).

An approach would be a list of all programs* with (minimal case) information if this program creates a window. Additional information (how many, where, size, ...) maybe could be provided by kwin (?).
But how to get this list of programs? There could be a set of predefined known programs (such as firefox, dolphin, ...), analysis of used libraries if a unknown program is started the first time or watching for creation of a window for a specific amount of time after the program started, ...

[Note: this approach would result in no "extended" start indicator for the first time - only the default one if started by K-Menu or similar]

*
More sensitive/Less specific (would have problems with e.g. python) -> Executable
Less sensitive/More specific -> Command

Additional effect for "Something with a window is starting"
If plasma expects a window to be created by given program, it could additionaly show some sort of "prototype window" (empy or translucent or some nice effect), giving the user the information that something will load there.
If possible the user could already modify the window (move it around, resize it, ...) and when the program starts, the window manager will try to do this to the actual program window. The whole process should be animated (no jumping), so there is a transition between prototype window and actual window.

Some graphical representation of my ideas

Program's loading prototype window


You can modify it


When program created it's window, the prototype window transitions (?) into the actual window

Displaying an arbitrary window might be confusing as well.
To be HIG conform I'd claim that programs get started immediately. Let's say "Any program certified as 'made for plasma' has to start within 500ms". If the program needs to load additional data, runs sanity check in advance or whatever it has to feed back the progress with a start dialog.
Of course, if we talk about slow hardware where loading programs takes ages its up to the OS to indicate the progress. So to throw in another idea: Throbber (aka spinner) are well known from web browsers. Why not show such a big icon as an OSD?

The next version of the Mir-based Unity will use a combination of these two ideas: see https://www.youtube.com/watch?v=c3PUYoa1c9M at 0:50.
I think a big OSD would be too disturbing; the bouncy cursor is perfect for that (not very disturbing but still visible).

Displaying an arbitrary window might be confusing as well.

Yes this would be confusing. I talk about a window that "mimicks" the window created by the program until the program creates it's own window. You could move this window around, minimize it, move it to another workspace and when the program created it's window, it just "blends" in.

Some quick KdenLive magic:
https://www.youtube.com/watch?v=tlLrW-344TU&feature=youtu.be
(You should be able to freely move the window around and then Chrome will "blend" into that window)

louis94 wrote:The next version of the Mir-based Unity will use a combination of these two ideas: see https://www.youtube.com/watch?v=c3PUYoa1c9M at 0:50.

Exactly! I thought about something similar to this behaviour: http://youtu.be/c3PUYoa1c9M?t=2m9s*

Just an immediate and "native feeling" (no extra OSD, ...) response from the desktop environment that the application is loading (by displaying a window "representing" the window to be loaded).

To be HIG conform I'd claim that programs get started immediately. Let's say "Any program certified as 'made for plasma' has to start within 500ms". If the program needs to load additional data, runs sanity check in advance or whatever it has to feed back the progress with a start dialog.

Yes. This would work - but honestly - which programs will be "Made for plasma"? There are and will be alot of programs which are not "made for plasma".

--

Edit: This "window prototype moving around thing" would "fix" a little annoyance: If you start an application such as Chrome or Firefox if you are in Workspace 1 and you quickly switch to Workspace 2, the application creates it window in Workspace 2. You have to wait in Workspace 1 until the application created the window (or move back the newly created window to Workspace 1 manually). Setting workspace by KWin is not an option, because I want a browser in all workspaces.

* Aarrg! It took me longer than usually needed to find the exactly position in video ... Firefox really wants me to switch to Chrome! Even with Firefox 36 MSE fails with videos longer than 2 minutes ... (no, i dont want to use ultra-security-hd-MLG-FlashPlayer(TM))

Ignoring (for the moment) that KWin cannot create managed windows itself (event handling mess):

Even if you had a list of "expected" behavior, that does not allow you to prospect whether the "expected" windows would be created minimized or on another activity or virtual desktop.
You're also in trouble if the client specifies a particular geometry (position and size) for that window (which should be honored) - repositioning the dummy as soon as it gets replaced. (This may also be required because the actual window has limitations on its minimum size, which the dummy does not share. Ie. you may have shrunk the dummy below a size acceptable by the client for the actual window)


Next problem is the list of "expected" behavior.
Who creates and maintains such list? How would it be updated? (As the next version of firefox could behave totally different)

And then: how many windows will firefox bring up? One? Maybe two browsers? Maybe one browser and the download list? - This is mostly defined by your last firefox session. Or not.
What if the first firefox window is the plugin updater?
And which would we assign to which dummy?

=> Such "list based" approach does not scale at all.
It's the client that needs to provide such information at runtime (I'm gonna need 3 windows of sizes A, B and C, entitled Foo, Bar and FooBar) - and that's pretty much equal to "create a window now and feed in the content later"



Looking at the ubuntu video, libreoffice and google maps show up "early" with different sizes and the libreoffice "dummy" is not replaced, but several elements appear inside it one by one (inner title, docks, toolbars, menubar & spreadsheet. Last a layout change)
Also the splash screen (and the dialogs) seem part of the main (LO) window.

=> I'd say canonical has "fixed" those clients downstream (with Mir adaption) and fixing clients to not take years to show up is what should be done in the first place. (Alternatively, their stuff encounters the problems mentioned above and fails on non-trivial cases - which have not been shown)
"Designed for plasma or not" - it's just very lousy if your program needs 5 minutes before the first visual feedback (ie. it creates a window)


You can btw. run "kstart --currentdesktop firefox" (but likely "fails" if the first window is the plugin updater)

Yes you are right no external program could predict the behaviour of another program exactly and if there would be plans to implement something similar to this, it would be quite difficult (or impossible).

it's just very lousy if your program needs 5 minutes before the first visual feedback (ie. it creates a window)

Yes, indeed. But it will never go away. There are always programs that take forever to load (especially some games, Firefox, Chrome or even Amarok (Yes!)).

So, let's trash the window preview thing - It was just an idea and I knew it would be almost impossible (But I threw it in here anyways). Are there any other ideas to handle these "evil" applications and not to confuse users so they think something crashed or "Linux is ****"?

You can btw. run "kstart --currentdesktop firefox" (but likely "fails" if the first window is the plugin updater)

Wow, I didn't know that! Is it possible to just tick a checkbox somewhere and apply this to all applications in the K-Menu or Icon Task bar? (A normal user would ask this)

Issue 1:
Time prediction. One does not know how long it will take for the client to be up itself.
Eg. a splash screen or similar might be shown for 100ms only - rather a flashy annoyance than helpful.
Waiting 500ms before showing something doesn't really help if the client needs 600ms

Issue 2:
Annoyance vs. visibility.
If a client really takes a long time (yes - I'm looking at you, inkscape!) to show up, so that you can do sth. different in the meantime (like writing "war and peace" or "gone with the wind" any cursor manipulation is really nasty, because there's "under your digit" that interferes with your work.
On the other hand, some "far off" indication (a notification?) may easily go unnoticed.

Issue 3:
Indication timeout.
If the process needs a long time to start up, you'll either have a too long (application failed to start) or too short (running into timeout to prevent eternal indication of a failed application launch) indication.

Issue 4:
Applications not started by a service (your steam case)
There's simply *NO* signal that some GUI client is starting at all.

--------

Resolving issue 4: WONTFIX.
It's the same problem when eg. starting a process from konsole by executing the binary. There's no hint that something is starting (and if we'd display something everytime "some" process is spawned, the user will soon see nothing else) - there's nothing that could be possibly be done about it, whether a bouncing cursor or a dummy window, we just don't know that something might be required in the first place.

Resolving issue 3: WONTFIX.
Respectively needs a protocol[1] update or only a heuristic solution ("is there something that looks like a pid key?") would be possible.
If we had a (local) PID, we could do a "high" frequency (once per second) check whether the process is still alive to keep or quit the indication.

Issues 1 & 2 fall into the same category: "find something that's neither offensive, nor invisible"
One could eg. display the icon + app name in the center of the screen (128x128 "mini splash", no input window, translucent w/ compositing) for about a second and then animate it towards the taskbar or the notification area?

[1] http://standards.freedesktop.org/startu ... latest.txt

On the pro side a preview window could help when an app crashes on start by showing the output (of course you can run it from the shell too). And for the preview we could use just a screen-shot of the last known state.

Personally I do not like that idea that much. I understand the problem though I find the solution not really attractive. You do not gain anything from faking a window. Practically it gives you no benefit, I would find it rather annoying. I would vote for improving the startup indicators. (For example: I do not find a timeout based approach reasonable: Sometimes in extreme cases the indicator gets lost and the application is still loading in the background. It should indicate the starting process as long as the process is running and give a possibility to kill it, which would be quite practical imho. Cool would imho also be the possibility to send sigstop and sigcont via the right click menu.) Its the job of the application to give visual feedback as early as possible.

Heiko Tietze wrote:On the pro side a preview window could help when an app crashes on start by showing the output (of course you can run it from the shell too).

The runner could indeed (redirect, log and) present the stdout of the process when it exits w/ a return code != 0

Heiko Tietze wrote:And for the preview we could use just a screen-shot of the last known state.

Leaving the security/privacy concerns aside (do you really want you GF/wife see a screenshot of the last open webpage? this faces the window assignment issues mentione above (ie. can only be reliably done by the client, not some external process)
Also, there's no guarantee that the last content is nearly similar to the new one, so if you just opened gimp w/ foo.png and see a gimp window w/ bar.png, you'll be just worried to have opened the wrong file.