Version: (using KDE KDE 3.3.0) Installed from: Debian testing/unstable Packages OS: Linux give us an option to remove system tray frame on hover -- comments to bug 69833 show I'm not the only one who doesn't like the frame at all. hey I happen not to like it, isn't this a wish? :) a simple patch could be made to remove it at all, but perhaps it could be made optional (like it was done with applet handles -- see, no more handles on my kicker! ;)
Created attachment 7826 [details] patch to kicker kControl applet (part 1 of 2)
Created attachment 7827 [details] patch to kicker kControl applet (part 2 of 2)
Created attachment 7828 [details] patch to SystemTray applet
not such an epic patch but it works just like I wanted it to work. KDE is such a great environment to work on -- it took me 30 mins from downloading kde source package to having a working patch.
please provide patches in unified diff form (-u). also, does the systray pick up the config change immediately when it's made in the control panel? i don't see that in the systray patch. address those two issues and i'll merge the change in.
which signal is raised when settings are changed? connecting to KApplication::settingsChanged(int) doesn't seem to do the trick :S
connect(Kicker::kicker(), SIGNAL(configurationChanged()), SLOT(...)));
accessing Kicker class requires linking against kdebase/kicker/core/kicker.so . I don't feel like I'm able to mess with kde Makefiles today... :( once this issue is resolved, patch should be working.
Created attachment 7847 [details] patch to kicker kControl applet (.cpp)
Created attachment 7848 [details] patch to kicker kControl applet (.ui)
Created attachment 7849 [details] patch to SystemTray applet sporting a brand new loadSettings() slot which shall be connected to Kicker::configurationChanged() (as soon as we have access to Kicker::kicker() ;)
i've committed the settings changes to the systray (created and connected to a DCOP signal from kicker). however, i won't be putting it in the UI as "Hide systray frame" is misleading at best as it only applies to when the handles are hidden/faded out, not at all times. i'm not really up to spending time on better wording or adding a whole System Tray Applet section to that dialog (it doesn't belong there; if anywhere, it belongs in it's own applet-specific config dialog ala the clock). this is really a tweakers delight sort of thing, anyways, and should just as well belong in KConfigEdit. so if anyone feels like getting their hands dirty, they can catalog all the KConfig options for Kicker and create a KConfigXT file for it. i'll get to this some time between now and KDE4, but please feel free to beat me to it ;-)
nice job :)
Why would one want to hide handles but keep this needless frame? Thus this should simply be bound to the hide handles setting. No handles, no frame.
because the frame isn't needless. one of the ways the handles get hidden is when locking down the panel via kiosk. in such cases, this isn't because the user wants a clean panel w/out handles, but because of a configuration limiting setting. the frame helps distinguish what is in the system tray from what is not; from what are status icons and what are app launching icons. it's configurable now, so those who wish to tweak away at their desktop can do so. but how much sense does it make to render the panel less usable just to satisfy the aesthetics of a few?
Well, everybody I know did not see any use in it. Some of them even have the smallest kicker-size, which is the _only_ case the frame makes any sense. I would argue that most people who have the small kicker are advanced users, so they know which icons are systray-icons anyway, further most people have the tasks in between normal and systray icons, so they do not need it either. If it is the way that this is mostly for kiosk-mode, enable it on kiosk-mode only, or are there that many people that use kiosk-mode? But anyway, fair enough. How do I tweak that frame away?
> How do I tweak that frame away add HideTrayFrame=true to your kickerrc
where? [general}? I guess it works only for 3.3.2?
yes, [General] and no, not 3.3.x. this is in CVS HEAD, which will be 3.4 ... if someone wishes to backport this to the KDE_3_3_BRANCH, they have my blessing.