After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 118991 - Some usability improvements
Some usability improvements
Status: RESOLVED FIXED
Product: gnome-applets
Classification: Other
Component: multiload
git master
Other Linux
: High enhancement
: 2.12
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-08-03 11:21 UTC by Dag Wieers
Modified: 2010-01-24 01:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Fixes drawing ("never get to 100%") (1.02 KB, patch)
2005-03-26 13:27 UTC, Martin Ejdestig
committed Details | Review
Original sysmon applet looks (10.48 KB, image/gif)
2005-08-06 22:54 UTC, Dag Wieers
  Details
Stretched to the same size as the Window List applet (10.58 KB, image/gif)
2005-08-06 22:55 UTC, Dag Wieers
  Details
Border removed too, 4 pixel (20%) gain on prev. 18 pixels (10.36 KB, image/gif)
2005-08-06 22:56 UTC, Dag Wieers
  Details

Description Dag Wieers 2003-08-03 11:21:55 UTC
Here are some changes I would make, feel free to use what you like:

  + Default Colors:
      Processor-colors: #0060a0 (system), #0090ff (user), #600000 (nice)
      Memory-colors: #ffa000 (user+shared), #ffff00 (buffers), #00ff00
(cached), #00a000 (free)

  + Borders:
      The applet is considerably smaller than the window list applet and
the    
      extra black and gray frame take away space that could be used by the 
      graph. (Every pixel counts)
      
  + If you hover over the graphs, and keep still when it says 100%, watch the
    tooltip frame break (the right corners) when the content changes. This
    happens both when shrinking and growing.
Comment 1 Dag Wieers 2003-08-03 12:39:48 UTC
I now also noticed that the CPU statistics never get to 100%, it's
always 1 pixel idle.

And I'm afraid that the way the rounding is done, free memory will
always be at least 1 pixel too. With about 18 pixels (on a X-Small
panel) 1 pixel is already 5.5%. That's why the tooltip always says
either 95% or 100%.
Comment 2 Danielle Madeley 2004-10-30 09:58:41 UTC
Any work done on this?
Comment 3 Michael Terry 2005-03-21 22:10:32 UTC
The third issue WORKSFORME.  The second issue there already seems to be some
code support for -- all you need to do to get rid of the border is:

diff -u -p -r1.48 load-graph.c
--- load-graph.c        12 Jan 2005 18:21:22 -0000      1.48
+++ load-graph.c        21 Mar 2005 22:08:15 -0000
@@ -279,7 +279,7 @@ load_graph_new (PanelApplet *applet, gui
     g->size   = MAX (size, 10);
     g->pixel_size = panel_applet_get_size (applet);
     g->tooltip_update = FALSE;
-    g->show_frame = TRUE;
+    g->show_frame = FALSE;
     g->applet = applet;

     g->main_widget = gtk_vbox_new (FALSE, FALSE);
Comment 4 Martin Ejdestig 2005-03-26 13:27:57 UTC
Created attachment 39281 [details] [review]
Fixes drawing ("never get to 100%")

Drawing was done so that it always started one pixel outside of the pixmap. I
hope it still applies (no net at home atm makes it hard to upd. my build env.)
Comment 5 Martin Ejdestig 2005-03-26 13:47:06 UTC
Default Colors:
I dunno about the suggested colors. I remember testing it out a while back
and didn't like it. I personally think what we have atm. is good. It's hard
to differentiate between e.g. User, System and Nice in the processor
monitor but I think that's the way it should be. Most people (ordinary users)
don't care or even know what the difference is. They just want to know if
their CPU is doing some work. Let the geeks modify the colors to diverge more
if they want to. :)

Borders:
I tested removing the borders but didn't like it. Some space is needed to
separate the different elements from each other. That's just one mans opinion
though. MAINTAINERs, please advice.

Tool tip frame break:
Unable to reproduce.

Tool tip always says either 95% or 100%:
I guess the right way to fix this one is to pass a char **tooltip_str to the
Get*() functions and have the value calculated for the tooltip be more exact
than what's placed in data[] (which really is the number of pixels to plot,
not %). MAINTAINERs, please advice.
Comment 6 Danielle Madeley 2005-08-03 17:07:09 UTC
Benoit, have you looked at this patch?
Comment 7 Benoît Dejean 2005-08-06 16:29:16 UTC
Sorry, i'm not able to test it, but i did and it was fine iirc.
Comment 8 Dag Wieers 2005-08-06 22:53:51 UTC
Here are 3 attachements. The first is how it is now, the second is a little
stretched so it is the same size as the window list applet and the third is
without the additional borders. This is a 4 pixel improvement (from 18 to 22).
Comment 9 Dag Wieers 2005-08-06 22:54:44 UTC
Created attachment 50334 [details]
Original sysmon applet looks
Comment 10 Dag Wieers 2005-08-06 22:55:29 UTC
Created attachment 50335 [details]
Stretched to the same size as the Window List applet
Comment 11 Dag Wieers 2005-08-06 22:56:31 UTC
Created attachment 50336 [details]
Border removed too, 4 pixel (20%) gain on prev. 18 pixels
Comment 12 Martin Ejdestig 2005-08-15 03:37:38 UTC
Is there any reason why the patch hasn't been applied yet? I just tested it with
an up-to-date CVS and it works fine. It isn't blocking by any freeze is it?

It fixes two quite obvious and common drawing mistakes:
* bottom of h pixels high bitmap is (h-1) not h (the "g->pos [i] =
g->draw_height - 1;" fix)
* h pixels high line should be drawn from y to y+h-1 not y+h (the gdk_draw_line
() fix)
and also, only do any drawing if height isn't 0.

Sorry for stating the obvious. :)
Comment 13 Danielle Madeley 2005-08-20 02:28:08 UTC
2005-08-20  Davyd Madeley  <davyd@madeley.id.au>

        * multiload/load-graph.c: Drawing was done so that it always started
        one pixel outside of the pixmap. Part of bug #118991. Patch from
        Martin Ejdestig <mejde@dtek.chalmers.se>.
Comment 14 Luis Villa 2005-08-24 19:40:48 UTC
Not a GNOME release showstopper, removing that mark.
Comment 15 Danielle Madeley 2005-12-21 06:29:23 UTC
Closing this.