After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 108040 - No recommended usage of busy-interactive cursor
No recommended usage of busy-interactive cursor
Status: RESOLVED OBSOLETE
Product: gnome-devel-docs
Classification: Applications
Component: hig
unspecified
Other Linux
: Normal normal
: ---
Assigned To: HIG Maintainers
HIG Maintainers
Depends on: 122728
Blocks:
 
 
Reported: 2003-03-10 20:44 UTC by Michael Toomim
Modified: 2021-07-05 10:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2



Description Michael Toomim 2003-03-10 20:44:46 UTC
The HIG says "Use a busy pointer whenever users are blocked from
interaction with your application for 1 second or longer."

But the HIG doesn't say what to do with input isn't blocked.  I think it
should.  It defines a "busy-interactive pointer", but doesn't say when to
use one.

For example, try visiting /usr/lib in nautilus.  Input isn't blocked, and
there isn't a busy cursor.  But I think that a busy-interactive cursor
would still be useful.  I'd like the HIG to take a stance on issues like these.
Comment 1 Murray Cumming 2003-04-04 10:46:55 UTC
I think a throbbing ProgressBar would be more appropriate. I can't
think of any app on Windows, Mac, or GNOME that changes the mouse
cursor to a busy-cursor while still allowing the mouse cursor to be used.
Comment 2 Calum Benson 2003-04-04 11:02:20 UTC
I've certainly seen it on Windows (it's one of the standard pointer
types), but I forget in which apps exactly, I'd need to go and play...
I think Windows Explorer uses it while it's generating all the image
thumbnails in a directory though, for example, since you can still
manipulate the files in the meantime.
Comment 3 Michael Toomim 2003-04-04 16:52:58 UTC
Murray: not busy-cursor, but busy-interactive-cursor.  I'm talking
about the cursor with an hour AND an hourglass, not just the hourglass.

Also, let me clarify what I meant a little: I think the HIG should say
something like "if the app is working on giving results back to the
user, but input is not blocked (ie., because the app lets the user
work on the data as it is being created) it should display a
busy-interactive cursor."
Comment 4 Murray Cumming 2003-05-30 09:54:59 UTC
Do we even have such a "busy-interactive-cursor" cursor?
Comment 5 Seth Nickell 2003-06-02 06:37:25 UTC
I don't think so, but perhaps we should consider getting one...
Comment 6 Murray Cumming 2003-09-19 12:38:22 UTC
I filed a GTK+ enhancement bug about that and made this bug dependent
on it.
Comment 7 GNOME Infrastructure Team 2021-07-05 10:53:19 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/

Thank you for your understanding and your help.