GNOME Bugzilla – Bug 598446
Use GtkSpinner
Last modified: 2010-04-19 09:51:35 UTC
Instead of a copied around spinner widget. See https://bugzilla.gnome.org/show_bug.cgi?id=319607
http://git.collabora.co.uk/?p=user/jonny/empathy.git;a=shortlog;h=refs/heads/gtk-spinner Currently untested. The GTK+ dependency will also need to be bumped, but because GtkSpinner hasn't been merged or released, I've left it for now.
GtkSpinner *is* merged.
And removing the blocker bug...
But we need it to be released and packaged in most popular distro... Unless we have good reasons, I would like Empathy 2.29 stick on GTK 2.18.
(In reply to comment #4) > But we need it to be released and packaged in most popular distro... Unless we > have good reasons, I would like Empathy 2.29 stick on GTK 2.18. I'm not denying that. I'm just saying that the spinner is merged, and ready to be used. I'm happy for it to live in a branch until you deem a GTK+ version bump acceptable. I'd be happy to see whether GtkSpinner works well enough for you...
(In reply to comment #5) > I'm not denying that. I'm just saying that the spinner is merged, and ready to > be used. Gah, sorry, I misread the bug and because it was still open assumed it wasn't merged. > I'd be happy to see whether GtkSpinner works well enough for you... I'll try it out with GTK from git tonight, or something.
Okay, I tried it out. The spinner in the main contact list window is in a GtkToolItem with @expand=FALSE. The other item in the same toolbar is the presence chooser with @expand=TRUE. GtkSpinner appears to allow a width of zero, which meant that it didn't show up at all. I'm far from being knowledgable in GTK+, but shouldn't the spinner have some kind of minimum width/height, much like a label does if it has text in it? Anyway, I set @expand=TRUE on the spinner's GtkToolItem and got this: http://people.collabora.co.uk/~jonny/empathy-gtk-spinner.png I have a few points about it. It's obviously far too big, but maybe the above discussion will provide a fix for this instead of hardcoding width values. Secondly, it looks very odd when it's stopped because it's mid-rotate. It looks as if Empathy has crashed actually. The good thing about the EphySpinner was that the feet would wiggle when there was activity but show a nice GNOME foot when there was not. I'm not sure how to achieve that with this though... Lastly, for now, I got the following backtrace a couple of times. I can easily reproduce it if I set the widget to hidden when it's not spinning, and show it when it is spinning (to try and achieve something like the previous behaviour). Program received signal SIGFPE, Arithmetic exception. 0x00007ffff4ac2da4 in IA__gtk_spinner_start (spinner=0x669380) at gtkspinner.c:537 537 priv->timeout = gdk_threads_add_timeout (priv->cycle_duration / priv->num_steps, gtk_spinner_timeout, spinner); (gdb) bt
+ Trace 218320
Does everything work as expected with bug 598496 fixed? Or does it still cause problems? Any chance you could make a small test case, or tell me how to reproduce the problem? BTW, you removed calls such as: - ephy_spinner_set_size (EPHY_SPINNER (dialog->throbber), GTK_ICON_SIZE_LARGE_TOOLBAR); But didn't replace them by anything. I'd expect something like: gtk_widget_set_size_request (spinner, 12, 12); or something like that. As for the "rest" mode, you'd either need to use a sub-class of the widget, or tell us what it should look like at rest (see bug 319607 comment 50).
(In reply to comment #8) > Does everything work as expected with bug 598496 fixed? It works fine now, thanks. > BTW, you removed calls such as: > - ephy_spinner_set_size (EPHY_SPINNER (dialog->throbber), > GTK_ICON_SIZE_LARGE_TOOLBAR); > But didn't replace them by anything. > > I'd expect something like: > gtk_widget_set_size_request (spinner, 12, 12); > or something like that. I guess I thought the resizing would be done automatically. Maybe that was naive. > As for the "rest" mode, you'd either need to use a sub-class of the widget, or > tell us what it should look like at rest (see bug 319607 comment 50). Hiding the spinner when it is stopped is reasonable, so I guess this is not a problem. If we want to change it, we can always subclass it, as you say. So, does anyone have any thoughts on this: http://people.collabora.co.uk/~jonny/empathy-gtk-spinner-2.png When you're not connecting, the spinner disappears completely and the presence chooser fills up the space in the toolbar that the spinner was previously in.
(It looks a little better with a GTK theme too: http://people.collabora.co.uk/~jonny/empathy-gtk-spinner-3.png )
looks good :D
*** Bug 592441 has been marked as a duplicate of this bug. ***
I do not recommend toggling the visibility of the spinner this way; dynamically expanding the status dropdown will look totally unpolished. A slightly less unpolished alternative would be to put the spinner in a status bar at the bottom of the window, with the text "Connecting". Then you can toggle the display of the status bar without affecting the layout of other elements in a jarring manner. Perhaps even better is the behavior Pidgin uses, which I've described briefly here: https://bugzilla.gnome.org/show_bug.cgi?id=592441#c6
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.