GNOME Bugzilla – Bug 84961
Applets that do not honour tooltip gconf setting
Last modified: 2008-08-11 20:12:13 UTC
When tooltips have been unselected in gconf, some applets don't seem to honor the setting. Through gconf, I unselect /apps/panel/global/tooltips_enabled [ ] This is the status (in the context menu order). OK is disabled tooltips, bad is tooltips still present: menus OK Clock OK Dict bad Stock bad Weather bad Wanda bad Geyes bad mail mon. OK modem OK CDplay bad volume bad battery bad chara bad command bad disk bad keyborad bad lock OK logout OK Hope that helps
um, excuse my stupidity, where do tooltips appear in dict? I can't seem to see them, hence can't reproduce the bug :/
These are all in panel applets. Dict (used to be -a) is a stand alone app *and* a panel applet. If you put the panel applet in the panel, and scroll the mouse over the app, a tooltip should pop up next to the panel with the tooltip text, adrian
Sorry, now I stand corrected, gdict applet doesn't seem to have any tooltips. Makes me think I should double check my list above which I will do this afternoon, adrian
Mark: this is not clear for me: how should applets know they should enable/disable tooltips? AFAICT, there is no API for this in libpanel-applet. Should we add an API for this?
Hmm, I'm not sure there should be an API for this in libpanel-applet. Any other GNOME application that respects this key does it by reading the key directly. If there was to be an API for this it should probably be in libgnomeui or somewhere.
Mhhhh... Mark: the tooltip setting here is only for the panel: /schemas/apps/panel/global/tooltips_enabled. Btw, I wonder why it's not a key in profiles/<name>/general/ ...
I'd forgotten about that key. Pretty sure there's a desktop wide key as well, and the panel one should die ...
Created attachment 25393 [details] [review] proposed patch
I have worked on this bug and corrected the problem. A proposed patch is attached here which is for clock-applet. This corrects the problem in clock applet. A similar approach may be taken for other individual applets. i.e. Inidividual coding may be done for each of the applets. While setting up the gconf-keys in the clock applet I have included code which notifies the gconf-editor action to the clock applet and action according to that is taken in setup_gconf function. Before diffing I have updated the code of clock.c but in this code some error has already crept in which on trying to open the clock- preferences, crashes the clock-applet. One more problem is there in my code on which I need to work on. When gconf-editor changes the tooltips_enabled key, It notifies the event thus clock applet disables the tooltips. But when a new instance of clock applet is loaded, and tooltips_enabled key is already disabled, no notification is generated. Thus in the new instance of the clock applet tooltips are shown. But again checking and unchecking the tooltips_enabled key fixes the problem. It seems that some code should check the gconf keys on startup of every new applet without receiving notification. I will be soon attaching the new patch fixing the above problem.
Created attachment 25394 [details] [review] sorry for attaching the wrong file above this is my proposed patch
Any news on that? regs, Chris
I'll work on it further only if maintainers comment positively, and confirm the way this has to be fixed. Otherwise a lot of coding work may go in vain.
I could not find a desktop wide key... I see two solutions: * find the desktop wide key, or create one if it doesn't exist * add a libpanel API
Dumb question, but why do we have this option at all?
Because tooltips can be annoying, I suppose.
Requested in https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/31102 as well.
fixing every single applet to check for that key is the wrong approach, as it adds a lot of code replication. having a property in PanelApplet, controlled by the GConf key, inside PanelApplet makes more sense: attaching a callback to "notify::tooltips-enabled" and disabling the tooltips based on the value of the property would avoid code replication and would keep the GConf handling where it belongs.
this problem really annoys me and i can understand that patching every applet is not the best solution. but since this bug exists for that long, i have a question: would be patches for the individual applets included or would they be rejected ? since this really annoys me i would try to produce some patches if they could get included...
tooltips are now (gtk+ 2.14) enabled globally by the gtk-enable-tooltips setting. every gtk+ widget (and hence applets) will automatically have tooltips disabled if that property is set to FALSE inside a gtkrc file. it might require a XSettings key in case we want to be able to use GConf to toggle it - but that is for another bug. I'd close this bug as OBSOLETE.