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 652066 - Show spinner in top bar to indicate application activity
Show spinner in top bar to indicate application activity
Status: RESOLVED DUPLICATE of bug 697207
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
touch
Depends on:
Blocks:
 
 
Reported: 2011-06-07 17:17 UTC by Bastien Nocera
Modified: 2014-02-24 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2011-06-07 17:17:32 UTC
As mentioned in bug 650604 comment 1, gnome-shell should track the state of the cursor for various windows/apps, and automatically show a spinner in the panel when the application switches to a waiting cursor.

This would allow showing activity, even when only a portion of the interface of that application is affected by the wait, and allows knowing the status of an operation at a glance.
Comment 1 Bastien Nocera 2011-06-07 17:18:20 UTC
This is obviously especially important when the cursor is invisible, as the code in bug 650604 implements.
Comment 2 Bastien Nocera 2011-06-07 17:19:40 UTC
gnome-shell can track cursor changes by listening for XFixesCursorNotifyEvent events.
Comment 3 Dan Winship 2011-06-07 17:24:01 UTC
(In reply to comment #2)
> gnome-shell can track cursor changes by listening for XFixesCursorNotifyEvent
> events.

There's already code to do that in the magnifier (and it runs even when the magnifier isn't running :-/)
Comment 4 William Jon McCann 2011-12-04 13:53:15 UTC
I'm wondering if the cursor is the right fit for this at all. A few things:

I think there may be value in showing this even on non-touch devices.

It can be useful to have a way for applications to signal they are working that is independent of the cursor.

We tend to overuse the strange "busy but not really" cursor a lot that spins but has a pointer. It may be better to indicate the work another way and keep the pointer just a pointer. This avoids contention problems where the cursor needs to change to provide feedback for resizing etc.

We currently don't really know when an application has really started up or loaded new content. This is partly because we don't seem to have a good way for the application to tell us that. I can imagine the startup notification itself causes a spinner to be shown and then the application continues the spinning until it is entirely loaded and ready.

There are times when applications perform work on their own that are unrelated to user input. It would be entirely strange to change the user's cursor at these times since they shouldn't interfere with input. Occasionally, but inconsistently, the status bar has been used for these cases.

Many apps historically have shown their own spinner either in a toolbar, statusbar, tab, etc because there is no application level way to indicate activity.

I'm wondering if we could use a new API for this.
Comment 5 Bastien Nocera 2012-08-03 13:10:51 UTC
From the discussions, I'm guessing that the original request isn't the main point of discussion but the implementation itself. This could be split into:
- Add spinner widget to panel with on/off
- Add API to GtkApplication (or GtkApplicationWindow) to set the spinner
- Port an application to using the spinner (look for GDK_WATCH in an application for example). An application like Epiphany would be great to port.
- Write guidelines as to when apps should use the spinner in the panel vs. the spinning cursor(s)
Comment 6 Matthias Clasen 2014-02-24 12:35:11 UTC
We have g_application_set_busy now
Comment 7 Florian Müllner 2014-02-24 13:49:21 UTC
(In reply to comment #6)
> We have g_application_set_busy now

Indeed - tentatively duping this on bug 697207, feel free to reopen if we need something other than the set_busy() API.

*** This bug has been marked as a duplicate of bug 697207 ***