with panel-background-images the cpugraph doesn't look very integrated, actually it's the main reason for me not to use any custom background. i know this is only a cosmetic enhancement, but it still would be a nice one.
Please define panel-background-images. Where is it set, where is it used, etc. If the plugin is using a GtkEventBox it may suffice to switch the visible-window property off, because it is the main reason why the plugin would paint an opaque background over the parent's window textured background.
i'm talking about setting a custom xfce-panel background image via adding a section like the one below to gtkrc: style "panel" { bg[NORMAL] = "#FFFFFF" bg_pixmap[NORMAL] = "background.ext" fg[NORMAL] = "#FFFFFF" } <a href="http://xubuntu.wordpress.com/2007/10/12/howto-set-a-background-image-for-your-panel/">source</a> this property is actually used (and set) by quite many gtk-themes.
Have you tried the version available on git? I normally don't use panel background images as you define them, but I just tried it out, and it seems to behave better than the released version. In addition, since there are now options to display or hide various parts of the cpugraph, it should be easier to get it to look the way you want. I'll close this as worksforme, since the new behavior is better than the old one, and seems fine to me. If that's not enough, please reopen with specifics about how you'd want it to look.
(In reply to comment #3) > Have you tried the version available on git? i did a while ago, even though the compiling (and building using checkinstall) didn't go too well for me (at times the panel wouldn't show the plugin in the list for adding and at other times the plugin would not seem to display the cpu load correctly, i guess something must've gone wrong with the compiling or so). > I normally don't use panel background images as you define them, but I just > tried it out, and it seems to behave better than the released version. In > addition, since there are now options to display or hide various parts of the > cpugraph, it should be easier to get it to look the way you want. hm, well, it's pretty easy what i'd like to see. e.g. in LED mode i'd like to be able to only have the activity-color shown and the other two hidden, basically the same result i get from using the panel-color for background color and color2. > I'll close this as worksforme, since the new behavior is better than the old > one, and seems fine to me. If that's not enough, please reopen with specifics > about how you'd want it to look. ok, i can try to recompile the panel plugin, since it wouldn't build with the new panel (4.7.1) i'll try again with 4.6.1. if you have any hints on why this maybe wouldn't work in a xubuntu 10.04 build environment let me know :)
(In reply to comment #4) > (In reply to comment #3) > > Have you tried the version available on git? > > i did a while ago, even though the compiling (and building using checkinstall) > didn't go too well for me (at times the panel wouldn't show the plugin in the > list for adding and at other times the plugin would not seem to display the cpu > load correctly, i guess something must've gone wrong with the compiling or so). Depending on when that "while ago" was, you might have better luck now. I did a lot of cleanups over the last couple of months, and that should help with the building too. But I haven't tried to get it to work with the 4.7 panel yet, so I can't comment on that part yet. If you run into build issues with a 4.6 panel, that's worth reporting. > > I normally don't use panel background images as you define them, but I just > > tried it out, and it seems to behave better than the released version. In > > addition, since there are now options to display or hide various parts of the > > cpugraph, it should be easier to get it to look the way you want. > > hm, well, it's pretty easy what i'd like to see. e.g. in LED mode i'd like to > be able to only have the activity-color shown and the other two hidden, > basically the same result i get from using the panel-color for background color > and color2. I led mode, my quick test shows that the background is properly replaced by you panel background image, so as far as I am concerned, that part is fixed. On the other hand, the color2, (and color 3 if you use gradients) is (are) drawn as foreground object(s), so your requirement wouldn't be satisfied here. Maybe using an RGBA color picker rather than an RGB one (with the necessary changes in the drawing code) would solve this problem without me needing to write one more rendering color mode for the LEDS. But this sounds more like a feature addition than a bug fix to me. If that doesn't have a significant impact on the performance or complexity of the drawing code, that might be a change worth doing.
> Depending on when that "while ago" was, you might have better luck now. I did a > lot of cleanups over the last couple of months, and that should help with the > building too. But I haven't tried to get it to work with the 4.7 panel yet, so > I can't comment on that part yet. If you run into build issues with a 4.6 > panel, that's worth reporting. I tried compiling again today from git and I have to say it works great! So I guess marking the bug "fixed" is appropriate :) Thanks a lot! With xfce4-panel 4.7 the main problem is the libxfcegui4 dependency (deprecated in xfce4.8 and replaced by libxfce4ui afaik)... > I led mode, my quick test shows that the background is properly replaced by you > panel background image, so as far as I am concerned, that part is fixed. On the > other hand, the color2, (and color 3 if you use gradients) is (are) drawn as > foreground object(s), so your requirement wouldn't be satisfied here. Yes that's true, would be cool if color2 and 3 would have the transparency option too. > Maybe using an RGBA color picker rather than an RGB one (with the necessary > changes in the drawing code) would solve this problem without me needing to > write one more rendering color mode for the LEDS. But this sounds more like a > feature addition than a bug fix to me. If that doesn't have a significant > impact on the performance or complexity of the drawing code, that might be a > change worth doing. +1