GNOME Bugzilla – Bug 702212
Support for activity on top of icons
Last modified: 2021-07-05 12:32:23 UTC
In Boxes, we need to indicate to user if a box is under installation or being imported. In case of former, we have no means to track progress so we'll want to show a spinner on top of the box icon. In case of latter, we have means to track the progress and therefore would want to display a progress bar instead. Attaching my WIP patches to get feedback on this and hoping to also get some help on theming and the issue I mention in the 2nd patch.
Created attachment 246775 [details] [review] pixbuf-renderer: Support for activity on top of icons This will be useful to indicate that there is some automated activity going on the item the icon in question represents. The main use case I have in mind with this is Boxes indicating VMs that are under installation.
Created attachment 246776 [details] [review] pixbuf-renderer: Support for progress on top of icons This will be useful to indicate that there is some automated activity going on the item the icon in question represents. The main use case I have in mind with this is Boxes indicating VMs that are being imported. Issues: * Theming is completely wrong. Some theme somewhere is setting the bg color to transparent so the progress bar's frame/background is drawn all transparent. Also the progress bar itself is drawn transparent if don't make the following call: gtk_style_context_set_state (context, GTK_STATE_FLAG_ACTIVE); before drawing and we really shouldn't be needing to call that.
Created attachment 246866 [details] [review] pixbuf-renderer: Support for progress on top of icons Nevermind the theming issue, gnome-themes-standard just needs some adjustment too for this.
I'm pushing the theme changes here for now: https://git.gnome.org/browse/gnome-themes-standard/log/?h=wip/gd-activity-on-icons
Forgot to mention that I've been in contact with jimmac about this idea and he is in favor of it.
Since we were discussing this on IRC, here are my two cents. 1 - the idea makes sense to me and it is clearly useful for boxes, the downside is that this small renderer is growing into a monster :-) 2 - could you attach screenshots? I can see how the spinner size with regard to the icon size could be bikeshed in different ways and I can also imagine different ways to draw the progress bar so having screenshots help the discussion 3 - a cursory look at Zeeshan's implementation looks ok to me To address the first concern, I actually have an idea, but I am not sure if it is worth the extra effort, so I'll let Cosimo and the others comment on it: instead of extending PixbufRenderer and adding all the features to it, we could have an OverlayRenderer which takes another renderer as input (e.g. a normal pixbuf renderer) and then just call the "wrapped" renderer "render" method and then draw its stuff on top. Such renderer could then be the base class used to do the selection stuff, the new progress stuff, but also other things: e.g. I would use it in clocks to draw the time over a picture etc. I guess it all depends on how much effort we want to put into the IconView approach or if instead the plan is to use GtkFlowBox really soon...
(In reply to comment #6) > Since we were discussing this on IRC, here are my two cents. > > 1 - the idea makes sense to me and it is clearly useful for boxes, the downside > is that this small renderer is growing into a monster :-) Thanks. That was mainly what I was looking for in the short term (i-e I don't push something that I'll be hated for :)). > 2 - could you attach screenshots? Even better, I'll attach screencasts. :) The progressbar case is shown through a hack since currently I don't have any means to track progress of either installation or import. For that reason, the progressbar patch here can wait longer but I really wanted to get the spinner one in so I can get it out there together with "existing image import" support: bug#690757 (especially https://bugzilla.gnome.org/show_bug.cgi?id=690757#c21). > I can see how the spinner size with regard to > the icon size could be bikeshed in different ways and I can also imagine > different ways to draw the progress bar so having screenshots help the > discussion Sure, do suggest different values and I'll try. Jimmac suggested 22px but that seems too small and to me looks weird to have a tiny spinner in the middle of the thumbnail. > 3 - a cursory look at Zeeshan's implementation looks ok to me Cool. Unless someone objects before tomorrow's release, I'll push the spinner patch tomorrow then. > To address the first concern, I actually have an idea, but I am not sure if it > is worth the extra effort, so I'll let Cosimo and the others comment on it: > instead of extending PixbufRenderer and adding all the features to it, we could > have an OverlayRenderer which takes another renderer as input (e.g. a normal > pixbuf renderer) and then just call the "wrapped" renderer "render" method and > then draw its stuff on top. > Such renderer could then be the base class used to do the selection stuff, the > new progress stuff, but also other things: e.g. I would use it in clocks to > draw the time over a picture etc. Makes sense. yes but if there is no objection on this idea, I'll want to move forward with implementation here for now. Later we can remove this new API once we have something better to use. > I guess it all depends on how much effort we want to put into the IconView > approach or if instead the plan is to use GtkFlowBox really soon... Hopefully Cosimo knows more about that, cause I don't. :(
Created attachment 246971 [details] Screencast of spinner
Created attachment 246972 [details] Screencast of progressbar
Created attachment 247006 [details] Screencast of spinner Correct screencast this time
Comment on attachment 246775 [details] [review] pixbuf-renderer: Support for activity on top of icons Attachment 246775 [details] pushed as a1f7543 - pixbuf-renderer: Support for activity on top of icons
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/libgd/-/issues/ Thank you for your understanding and your help.