GNOME Bugzilla – Bug 650045
create Temporary Dummy Window when starting application
Last modified: 2011-06-07 20:34:34 UTC
I'd like to suggest a Temporary Dummy Window that is shown between triggering an application launch and the appearing of the main application window. This is a description of the experience when dragging an application launcher to a workspace: The Temporary Dummy Window (TDW): As soon as the application icon is dropped a dummy window appears. It has window decorations, close button and maybe a large icon of the application as a place holder in the main area. As soon as the main application window is loaded, the place holder is replaced by the main window content. Features: * Visual feedback From initiating the application start until the actual application appears, there is highly visible feedback saying "this application window will soon appear here on this workspace". (Even better than the dummy task-button in the taskbar of other OSs. ;-)) * Resizing The TDW has the size the application had before closing. It can be resized and repositioned before the actual application is loaded. If the "old size" is not available a standard size will be used. * Abort loading The application loading could be aborted before the main window appears. Very useful when accidently starting a very large application. * Failing If the application fails to start, a message appears in the TDW's main window. Maybe "retry", "console output" or other useful stuff can be offered. * Workspace handling If the application is dragged to the empty workspace the TDW can set the workspace to be used and initiate creating a new empty workspace. (fixes bug 645331) Is this worth implementing?
I think it would be better to focus on making applications start up faster instead of a workaround. Also, how would it know the default size of the window if the program has never been started before, or if it has no standard setting that displays it's size?
(In reply to comment #1) > I think it would be better to focus on making applications start up faster > instead of a workaround. Of course this would even be better. But it would mean that every application finds it's own way to fix it. Besides making startups faster many applications show a splash screen (OpenOffice). Instead of every application showing it's own fancy splash screen (that isn't visible in overview) it would be better to handle the "waiting for application load" by the shell. And besides that - no application start up can be as fast as just creating a place holder from the information the launcher already provides. > Also, how would it know the default size of the window > if the program has never been started before, or if it has no standard setting > that displays it's size? "Haven't been started before" can only happen once. ;-) And even if there's no size available there can be different ways to handle this: * display the TDW as non-resizable (just like a splash screen) * make the TDW resizable and (try to) resize the actual window to that size after loading Anyway I don't know where to get (or where others like KDE get) the window size/position of applications that where started before. Do the applications provide it or does the window manager save the last recognized window's parameters?
IMHO this is simply application bugs. You can't seriously expect gnome-shell to workaround random bugs in random applications. If the application takes too much time to put something on the screen then fix it. Anyway, marking as needing ui-review.
I think an approach similar to unity for application launching indication is actually quite good - make the dock icon for the launching application subtly visible on all desktops. It establishes the mapping between the dock and the application early. I suppose you could say the current implementation does something similar using the app menu (but currently the app menu has no features)
(In reply to comment #5) > (but currently the app menu has no features) That is going to change in 3.2 ... Regarding the proposal: Until the application actually opens a window, we don't have any information whatsoever about its size. Applications which restore a previous window size implement it themselves - if, how and where the previous size is stored is completely up to the application. So all we could realistically do is to force a splashscreen on all applications (and given that spashscreens are evil, it's pretty safe to say that it won't happen) ...
Really doubt we would do this.
It is actually a fairly interesting idea. WebOS and iOS do essentially this. They have the advantage of always knowing the window size of course. And iOS knows what the window should look like/looked like last. So, it is a bit harder for us. I considered it for our startup notification but decided using a spinner next to the app menu was way easier. Could be something to look at later though.