Just because a tool exists that allows you to do something does not mean it is the right thing to do.
Sometimes we realize it was not worth doing in the first place.
Tobacco Smoke Enema Kit
Sometimes we realize there are better ways to accomplish the same goal.
Olden Shower
And so it is with widget tool kits as well.
I urge you to avoid using the GtkProgressBar‘s dreadful activity-mode. You know the one – where the “progress” bar pulses from side to side and back again.
If possible, figure out a way to estimate the duration of an action so you can use the progress bar for what it is designed for. If you can’t then maybe something like an activity spinner/throbber is more appropriate. Code that simply calls gtk_progress_bar_pulse very likely needs to get fixed. We should probably update our Guidelines too.
Unless you have an Anamorphic Equalizer please don’t pulse all over my screen.
(I really wanted to include a Dead Ringers reference but it didn’t quite get the same point across)
As soon as such a spinner widget exists in GTK prime I’ll change my code to use it. Until then, deal with it. =)
I second the notion of not using a pulsing progress bar. It’s like a progressless bar. I suppose it lets me know that the operation isn’t blocking the GUI or hasn’t frozen the application.
You failed to give a specific reason for why to not use it. A simple “it’s wrong” is not very educational.
That said, I’ve always thought pulsing was reserved for cases that should have a progress indication, but can’t. Like my browser downloading something that didn’t give a Content-Length. Or is it wrong for that, too?
otte: because it’s ugly and distracting 🙂
Indeterminate progress bars are “ugly and distracting” only because most GTK themes make them bounce back and forth. That is a silly way to present them, partly because it makes them look hyperactive, and partly because if you glance at one at the wrong moment it looks identical to a determinate progress bar. I suggest reporting a bug against every GTK theme that presents them this way.
Wherever possible, progress bars should be determinate, even if the proportions allocated to subtasks aren’t exact. Programmers often don’t do this, because they think — incorrectly — that inaccurate progress feedback is worse than none at all. (Giving an estimate of time remaining is a whole different kettle of fish.)
Progress of a long-running task, where the user is likely to be interested in its completion, should be shown in a dedicated progress window whenever there isn’t another relevant window to show it in. And a dedicated progress window should always include a progress bar, not a spinner, even if the progress is unfixably indeterminate.
There’s plenty more advice that could be written about progress bars, none of which is in the Human Interface Guidelines yet. (For example, a common error in Gnome software is to use a progress bar as a gauge of something other than progress.)