GNOME Bugzilla – Bug 734603
Use re-read action state changes to drive UI changes
Last modified: 2015-02-16 18:28:30 UTC
Now that the re-read action has state, use this change the status bar and mouse cursor rather than changing them directly everywhere the state of the action is changed. This means we don't have to remember to change the UI when we change the state, it just happens automatically.
Created attachment 283083 [details] [review] Reformat metadata_cb
Created attachment 283084 [details] [review] Use re-read state for UI. Use the state of the re-read action to change the status bar and mouse cursor rather than changing them directly everywhere the state of the action is changed. This means we don't have to remember to change the UI when we change the state, it just happens automatically.
Created attachment 283085 [details] [review] Don't push endless status bar messages. When extracting and playing the status bar is continuously updated with gtk_statusbar_push but the messages are never cleared. To clear the status bar an empty message is pushed. This interacts badly with the re-read code that pushes and then pops messages and also wastes memory. Fix this by (i) using different context ids for extracting, playing & re-reading. (ii) using gtk_statusbar_remove_all rather than pushing empty messages to clear the statusbar. This exposes GTK bug 724281
I wonder if we should use g_application_mark_busy() rather than changing the mouse cursor. It would be nice to get this sorted for 3.14 as at the moment there is no busy indication while the metadata is being retrieved. This is because reread_cd() is now only called once, before the main window is realized.
"mark busy" is great for network downloads.
Created attachment 285465 [details] [review] Use g_application_mark_busy() Marking the application as busy is a better option than changing the mouse cursor. We have to wait for the window to be realized before calling g_application_mark_busy() otherwise the busy spinner doesn't appear in gnome-shell
Created attachment 285466 [details] [review] Don't push endless status bar messages. This is the same patch as before rebased onto "Use g_application_mark_busy()" When extracting and playing the status bar is continuously updated with gtk_statusbar_push but the messages are never cleared. To clear the status bar an empty message is pushed. This interacts badly with the re-read code that pushes and then pops messages and also wastes memory. Fix this by (i) using different context ids for extracting, playing & re-reading. (ii) using gtk_statusbar_remove_all rather than pushing empty messages to clear the statusbar.
(In reply to comment #6) > We have to wait for the window to be realized before > calling g_application_mark_busy() otherwise the busy spinner doesn't > appear in gnome-shell That's not true, I've just tested it again and most times the spinner still isn't showing even if g_application_mark_busy() is called once the window is realized. I'm not sure if it's a problem with the code, my installation of gnome-shell or a bug in gnome-shell. I'm not sure what the expected behaviour of the shell is. Help!
It looks like there is a race between sound-juicer changing it's busy status and gnome-shell subscribing to PropertiesChanged so it misses the change in the busy status. I've filed bug 736492 against gnome-shell.
Created attachment 286807 [details] [review] Use g_application_mark_busy() The problem with the spinner not showing up is a bug in gnome-shell. This is a simplified version of the previous patch. Marking the application as busy is a better option than changing the mouse cursor. This exposes bug 736492 in gnome-shell.
Created attachment 286808 [details] [review] Use re-read state for UI. Use the state of the re-read action to change the status bar and mouse cursor rather than changing them directly everywhere the state of the action is changed. This means we don't have to remember to change the UI when we change the state, it just happens automatically.
Created attachment 286809 [details] [review] Don't push endless status bar messages. When extracting and playing the status bar is continuously updated with gtk_statusbar_push but the messages are never cleared. To clear the status bar an empty message is pushed. This interacts badly with the re-read code that pushes and then pops messages and also wastes memory. Fix this by (i) using different context ids for extracting, playing & re-reading. (ii) using gtk_statusbar_remove_all rather than pushing empty messages to clear the statusbar. This exposes bug 724281 in Gtk+
Attachment 286807 [details] pushed as 976572e - Use g_application_mark_busy() Attachment 286808 [details] pushed as 6c7c530 - Use re-read state for UI. Attachment 286809 [details] pushed as 113d2b1 - Don't push endless status bar messages.