Re: [patch] making the applet stetic.

[Jonathan Blandford <jrb redhat com>]

Robert Love <rml novell com> writes:

> As we all know, being stetic is of the utmost importance:
> 
> 	http://primates.ximian.com/~peter/stetic.html
> 
> The current NetworkManager applet is not as stetic as it deserves to be;
> it has potential, it dreams of a world in which it is the most beautiful
> applet ever, but it is not yet there.
> 
> The progress bars immediately jump out as low-hanging fruit.
> 
> The attached patch replaces the current gtkcellrenderprivate magic with
> Gtk Progress Bars--but not just any progress bars.  Progress bars that
> are dynamically sized based on the font size.  Beautiful, lovely, public
> progress bars.
> 
> The benefits:
> 
> 	- Follows the system theme.  The current Gtkcellrender thing
> 	  is not correctly themed.
> 	- Uses a public API instead of the private in-tree gtk code.
> 	- Nicer looking size.
> 	- Dynamically-sized based on the current language and font
> 	  ascent, to five ascents long and one high.  This elegant
> 	  code is c/o Joey Shaw.
> 	- Net code reduction of -1532 lines, four files.
> 	- Oh, it is sooo stetic.
> 
> The cons:
> 
> 	(this list is empty)

Hi Robert,

I was on vacation when this email went by, but I'd like to see some of
this reverted.

First, a bit of history on GtkCellRendererProgress.  NetworkManager was
started against GTK+-2.4, before the cell renderer made it into GTK+
itself.  Since we were trying to get NM into FC3 at the time, we
cut-n-paste the code from gtk+-HEAD into NM.  It really should have been
conditionally compiled in a configure check based on the version of GTK+
you had, but apparently this didn't happen.  Versions of NM against
GTK+-2.6 and greater really shouldn't use that code at all.

Now for the rationale for using the cell progress bars.  The primary
purpose of the cell renderer is to provide a progress bar suitable for
rendering in menus and lists.  It is supposed to be 'flat', as opposed
to GtkProgressBar, which is supposed to be suitable for general
embedding.  Some themes draw GtkProgressBar in a flat manner, and thus
the progress looks fine in the menus.  However, themes such as Bluecurve
draw this widget beveled, which makes them look odd in a menu.
Bluecurve also draws the progress cell renderers badly.  However,
Clearlooks does a significantly better job, as it sets its x/y thickness
to 1.  I put a screenshot up here comparing the two:

http://www.gnome.org/~jrb/files/progress-comparison.png

There's no reason this progress bar should look so bad on other themes,
and we should fix the themes to make them look better.

There are a couple of other issues that you listed:

> 	- Follows the system theme.  The current Gtkcellrender thing
> 	  is not correctly themed.

I'm not 100% sure what you mean by this?  Do you mean that it doesn't
honor theme changes?  Or is it getting some things wrong.

> 	- Dynamically-sized based on the current language and font
> 	  ascent, to five ascents long and one high.  This elegant
> 	  code is c/o Joey Shaw.

This code seems fine, and chould easily be propagated to the
CellRendererProgress.  If you want it to adjust in changes to the system
font or theme (which would be pretty cool), you should do it in a
"style-set" signal callback.

Thanks,
-Jonathan