Robert Love <[EMAIL PROTECTED]> 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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list