Progress dialog for starting applications?

[hmc]

Hi guys,


in this thread, the idea was mentioned, that a progress bar for starting applications, which take long to load (e.g. PNDManager) is displayed, so the user knows, that his request to start an application is really processed ,even if it take a while, until the actual program window is shown.


I have done something like that before, for a system, where application startup can take quite a while. E.g. 30 seconds for Firefox, up to a few minutes for OpenOffice... ;-) This was a system called "weeXpc", an optimized variant of pdaXrom for the Sharp Zaurus PDA.


The progress dialog, which I introduced in weeXpc looked like this:

Question is now:


Would we like to have something like that in our Pandora OS, too?


I see chances to implement this in a very central place, in the PND library, which handles startup of all PND applications. So no PND would have to be modified, in order for this to work.


Instead of showing a certain percentage or remaining time in seconds until the application is started, on the Pandroa it would probably preferable to just show a "loading..." dialog, maybe with some animated element in it. On the Zaurus it was quite clear, how long an application needed to start, but since the Pandora can be configured to different CPU speeds, and there will be faster ones in future, the method I used in weeXpc - determining the approximate time an application needs to start, and code that firmly into the startup script (e.g. "if application = firefox, use time for progress bar = 30 sec") would not be appropriate here.


What do you think?


Please use the poll for voting for or against such a dialog, and please post your detailed opinions, too.


Not that this will be a decision to implement it, if "Yes" wins here. but it will help to determine, if there is any demand for that at least.


Daniel

 

[TrashyMG]

Honestly I just look at the SD card lights as indication it's actually working..

 

[hmc]

Sure, that's what I do, too.


But if you start an application from the NAND..? Okay, large PNDs probably will not be installed in NAND.


Also, there can be other reasons for an application to take long to start, not just bare loading-from-storage time.


I also think, that such a dialog should not be displayed for all applications. It would only flicker for applications, which start quickly. And flickering is evil.


It should only be shown for applications, which take over - say - 5 seconds to start.

 

[hmc]

Answering _wb_'s questions from here:

What would the progress bar be based on if this dialog is to be shown in an application-independent way? Would it just keep track of the average time needed by the application to start? But then how does it know when it has actually finished loading? Somehow ask the window manager when a new window gets opened? (but even then, some apps might quickly create a window but take a long time to actually show anything in it) Or would it have some database of empirically obtained "starting times" for each application (but then the times would probably not be very correct if you run at a different clockspeed or have exceptionally slow or fast SD cards).

Indeed in weeXpc I asked the Windows manager, when the program window was displayed, and then stopped the dialog.


This was the most reliable way to do that.


It required me for each application observed by this script, to manually put its average starting time and its windows manager main window name into some configuration file or configuration part of the script (don't remember now).


For the average starting time, I already said above that I would avoid that here, and just show a generic "loading" animation without an indicator about the remaining loading time.


For Window manager inquiry about application main window availablity, I currently don't know, if and how this can be solved in a generic way in the PND system. But we should be able to find a way.


Daniel

 

[PaulForey]

I don't have anything to contribute technically, but from a usability standpoint it would be really neat to have a VERY simple "loading..." when you load up a big PND. I hate it when you do an action and there isn't instant, recognisable feedback. Even if the PND takes a while to load, a quick "loading..." dialog should make the system feel more responsive.


Disclaimer: I don't have a Pandora yet, so this is talking in generalities.

 

[Prometheus]

^ Agreed. Whilst, as with Linux-SWAT and hmc, I tend to watch the SD Card access LEDs, I think that this is a good idea for usability's sake. After all, not all users will necessarily connect the access lights with program activity...

 

[lollipoppizza]

That would be really great but a bit smaller. A simple loading bar with percentage and "Loading (application name)..." would be fine.

 

[Binky]

Doesn't a cpu load monitor do the job well enough?

 

[NearTao]

A loading meter will only be as accurate and dependable as the author of the .pnd would make it. I cannot foresee that this could be made generically for all .pnd files in a meaningful way. Although a framework could be made to support it, again the worst case would be something like the legendary windows progress bar that just bounces around or worse pushes forward and then stalls.


Unfortunately there isn't an easy mechanism to measure 'progress' for loading an application... you'd probably get more traction here for a 'doing stuff' kind of notification but even that has issues and is hard to deduce any relevant meaning. I suppose a monitor process could be put in place to denote 'still running' or 'not a zombie' process... but well... yikes

 

[mcobit]

You could track the mounting process and make some kind of indicator with: Mounting pnd, loading app, unmounting pnd.

 

[Caine]

It should be possible to invoke zenity --progress in the pnd_run script at specific points to display an advancing progress bar.

 

[sebt3]

It should be possible to invoke zenity --progress in the pnd_run script at specific points to display an advancing progress bar.

I guess I can add this rather easyly, not ssure it worth it (At least I would find it annoying)

 

[Caine]

I guess I can add this rather easyly, not ssure it worth it (At least I would find it annoying)

I wouldn't like it either.

 

[_wb_]

I would like this, with an option to switch it off for those who don't like it.


pnd_run could be adapted as indicated above, but I suspect that the mounting is not the largest contributor to long loading times. It's a start though. How easy would it be to ask the window manager whether any new window has been created (without knowing its name)? This would be the point at which loading would be consider to be done.


Then you could keep a small database containing an entry for each PND with its previous mount time and post-mount load time. Or maintain a running average of these timings. If you really want to push things you can even store additional info like current cpu freq and system load, and use these for even more accurate interpolation. Anyway, just the previous timings will probably be accurate enough. You could use these timings to show an actual sliding progress bar that accurately and steadily goes from 0 to 100 (you rarely encounter such progress bars).


I like the weeXpc thing, but it looks a bit too "technical" - I would rather have something that looks a bit more friendly: no window-decorations, keep text to a minimum - "Application Startup Control" sounds a bit intimidating . Just "Starting <appname>" and the progress bar (no need to show the actual percentage) on a nice little rounded rectangle background...

 

[skeezix]

The usual way something like that is done (flicker free progress bar) is .. usually you have some API to post updates to it ("we've moved"), or at least a kickoff timer ("start showing now", even though nothing is showing.) At any rate, after X amount of time goes by you _actually_ start showing the progress (be it on nesdt callback, or after some SIGALARM time has gone by, that sort of thing.)


So avoiding flicker is trivial in concept..


Showing a progress bar .. Well, you could do a staged onme, showing the stages of pnd execution .. mount it, run the app, but theres only a couple stages (mounting takes the long time.) If you want to show a 'loading..' "at all" then wrapping it aroudnf the mount might work, since its a long operation (show befor emount, ditch after mount, before run script), but thats maybe a relatively constant number.


The real goal I guess is to know when the runscript is producing something _useful_, but without application assistance, how would you know?


lsof against the mount to see if some jobs are doing stuff? Thats really just the same as showing before and dropping before the runscript, .....


Really I think its moot -- good UI design mweans the aspps come up and do _soemthing_ before they're actually able to work; a window should open, or _something_ happens. If an app is running, but chugs for 30s before showing _anything_, it is a _bad application_. The system can't really do much about it. pndstore or whatever.. why isn't it doing something? Fix the app


jeff


ie: Remember, an app coudl be using X11 plain, or something like QT/gtk/etc, or SDL, or framebuffer, or opengl, or nothign at all (a plain console app or even a non-output app, that processes and exits.)


Maybe you could watch children of the runscript, and see if their cpu activity goes useful, and say aha, we ran the run script, and its kicked off somethign that is actualyl doing work.. drop the 'loading screen'; does that risk breaking the app though .. ie: if its gl, you've lost the loading screen already likel;y; if its SDL, showing a window will screw with the SDL display (ie: run minimenu, tell it to fire up a terminal, watch how it goes from fullscreen to windowed automatically; thats great actually, but if you're doing a little 'loading' dialog, and causing the fullscreen to toggle windows/fullscreen a few times, its going to be ugly ('flickery').


Doing it without side-effects would be nice .. maybe on another layer (minimal risk there)..

 

[mcobit]

For Panmame, I simply use gtkdialog to display a splash while loading.


As it displays a normal gtkwindow, it is visible until sdl initializes its video and switches to the new layer.

 

[hmc]

You could track the mounting process and make some kind of indicator with: Mounting pnd, loading app, unmounting pnd.

I disagree with this.


The standard user doesn't want to know these things.

 

[hmc]

I would like this, with an option to switch it off for those who don't like it.


pnd_run could be adapted as indicated above, but I suspect that the mounting is not the largest contributor to long loading times. It's a start though. How easy would it be to ask the window manager whether any new window has been created (without knowing its name)? This would be the point at which loading would be consider to be done.

Attention:


Although this will be true in most of the cases, there can be cases, where the user starts another application, while waiting for the frist one to start up. But even then, we could consider, if it's okay to remove the "Loading..." indicator at this point in time.


So maybe it's aver good idea, to simply detect, if ANY new window has been created. And this shouldn't be too hard.

Then you could keep a small database containing an entry for each PND with its previous mount time and post-mount load time. Or maintain a running average of these timings. If you really want to push things you can even store additional info like current cpu freq and system load, and use these for even more accurate interpolation. Anyway, just the previous timings will probably be accurate enough. You could use these timings to show an actual sliding progress bar that accurately and steadily goes from 0 to 100 (you rarely encounter such progress bars).

Although this sounds like a bunch of very good ideas, maybe it wold be favorable to keep it simple and really just show a splash-screen like window, which says "Loading applicationXY....", which disappears, if loading is finished (however that is detected). Without a progress bar, which can never be really accurate. Even if we collet data to estimate loading time on later launches, loading time can depend on so many thing. If 5 other applications are populating RAM, and on loading application 6, RAM contents must be swapped extensively, loading of large application 6 can easily be double or three times the normal loading time. This was also one of the problems with the weeXpc approach.

I like the weeXpc thing, but it looks a bit too "technical" - I would rather have something that looks a bit more friendly: no window-decorations, keep text to a minimum - "Application Startup Control" sounds a bit intimidating . Just "Starting <appname>" and the progress bar (no need to show the actual percentage) on a nice little rounded rectangle background...

I fully agree here.


Well, the "application startup control" mechanism took care of a lot of other tings, too, in weeXpc, not just of displaying the starting screen.


But I have learned a lot since then, about user-friendlyness and ergonomics, so I agree with you, that the dialog should be much more simple and not "intimidating" at all ;-)


Btw: For example, "wasc" also made sure that always only one instance of a program could be started, and if the program is started a second time (because the user maybe did not realize that the program was started already, because it was minimized), it brought up the already started instance.


It also made sure that program windows start up maximized by default.


All that was configurable on a per-application basis, so applications could be configured to be multi-instance-allowed, or small-window etc.


All this was done using wmctrl, which is not available on the Pandora (incompatible windows manager). I wonder, if an equivalent command line utitily exists for XFCE?


Daniel


P.S.: Here is the main startup code of my wasc script, for you to get an idea about hoe it works:

Spoiler

#Start application: If TIME=0, do not show hourglass.


echo $0: $NAME is starting. Please wait...


if [ $TIME -gt 0 ]; then

  (for ((i=0;i<=$TIME;i+=1)); do

  echo .

  sleep 1

  done) | \

  Xdialog --rc-file "$GTKRCFILE" --title "$TITLE startup control" --backtitle "$BACKTITLE" \

  --icon "$ICON_WAIT" \

  --progress "Starting:


$NAME


Please wait.

" "$SIZE_DIALOG" $TIME &

fi


$1 $GEOMETRY &

PROCESSID=$!

WINDOWEXISTS=0

TRIALCOUNTER=0


# This speeds up startup because the loop is not enetered

# during waiting for the wasc hourglass window to come up:

sleep 5


while [ $WINDOWEXISTS = 0 ]; do

  TRIALCOUNTER=$[$TRIALCOUNTER+1]

  sleep 1

  if [ -z $WINDOWNAME ]; then

	WINDOWID=`wmctrl -l -p | awk '{print $1 " " $3}' | grep " $PROCESSID$"`

  else

	WINDOWID=`wmctrl -l -p | awk '{print $1 " " $5 $6 $7 $8 $9 $10 $11 $12 }' | grep "$WINDOWNAME"`

  fi

  if [ $? -eq 0 ]; then

	WINDOWEXISTS=1

	wmctrl -c "startup control"

	if [ $MAXIMIZE -eq 1 ]; then

	  echo Maximizing window $WINDOWID...

	  wmctrl -i -r $WINDOWID -b add,maximized_vert,maximized_horz

	fi

  fi

  if [ $TRIALCOUNTER -eq 180 ]; then

	echo wasc was not able to maximize the window of "$NAME"

	echo because there was no window with corresponding

	echo PID or Window Name within 3 minutes. Exiting.

	exit 1

  fi

done

 

[mcobit]

Use the spoiler tag?

 

[hmc]

Really I think its moot -- good UI design mweans the aspps come up and do _soemthing_ before they're actually able to work; a window should open, or _something_ happens. If an app is running, but chugs for 30s before showing _anything_, it is a _bad application_. The system can't really do much about it. pndstore or whatever.. why isn't it doing something? Fix the app

Most applications are developed and tested on fast systems, so most application authors don't see the need to do anything else on startup than showing the main window, once it is available. They don't consider, that their applications would be run on low-end systems, too, that may take a lot of time to accomplish the startup.


Also, I think a central implementation of something like that would be more user-friendly. It would look strange, if every applications would show its own "loading..." dialog. Also because actually it's the OS, which "Loads" something, not the application, which is "loaded" but not "loading". But maybe I am nitpicking here.


I would clearly prefer a "loading" dialog, which looks unified for each application.


And for the reason of the first argument given above (developer not aware of low-end systems), I think it would be a great help to have a central implementation in the pnd system.


Daniel