I found a method that seems to effectively eradicate tooltips on a Fedora forum:
Create a file in your user directory called ".gtkrc-2.0"
The file should contain the following "gtk-enable-tooltips = 0"
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this
I'm looking at this bug right now in Lucid beta2. :-(
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Changed in: hundredpapercuts
Importance: Undecided => Low
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.u
happens to very regularly with opera and chrome.
don't know what triggers it exactly tough... it's usually a long and
screen consuming url on the tooltip.
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of U
>From the first comments in the bug filed upstream in compiz it seems
that they think the window manager is not responsible for the behaviour
of tooltips (http://bugs.opencompositing.org/show_bug.cgi?id=1232#c1):
...
Tooltips are override_redirect windows, which means that the window manager
does
If this is of interest for developers, I found that in libwnck-2.28.0 (karmic)
the persistent tooltips in the window list applet can be avoided by applying a
patch to 'tasklist.c' that disables tooltips only in
'wnck_task_update_visible_state'.
In libwnck-2.26.0 (jaunty) it was necessary to disa
I think Paul's point is well made. What if the Compiz guy looks at this
and says "The desktop switcher is the only thing that has tooltip
problems. Let them eat cake!" what then?
When I right click on the desktop switcher and go to preferences it
allows me to set columns and rows, how hard woul
As a quick guess I'd say libwnck isn't getting mouse events during the
viewport change animation so never realizes the mouse left the switcher.
That's why the tooltip appears and why moving your mouse over the
tooltip or the switcher gets rid of it. I'm not sure what it does
differently from other
Are we sure this is really a bug in compiz? It seems too early to
determine that and reassign the bug. There are plenty of other tooltips
that are used in other applications and I never see those hang up like
this using compiz. It seems to only be a combination of libwnk and
compiz that shows th
Thanks for sending it upstream
** Project changed: libwnck => compiz
** Changed in: compiz
Remote watch: GNOME Bug Tracker #578262 => Compiz Plugins / Config Bugs #1232
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you a
Filed a bug in compiz:
http://bugs.opencompositing.org/show_bug.cgi?id=1232
** Bug watch added: Compiz Plugins / Config Bugs #1232
http://bugs.opencompositing.org/show_bug.cgi?id=1232
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notificat
Argh. Can someone please look at this? I guess some people just have a
certain speed of moving the mouse that causes this to happen: it happens
to me about 80% of the time that I click on the switcher applet. I know
it sounds stupid and minor, but it is SO INCREDIBLY ANNOYING!
I can build/insta
upstream bug hint that the issue is a compiz one
** Package changed: libwnck (Ubuntu) => compiz (Ubuntu)
** Changed in: compiz (Ubuntu)
Status: Triaged => Confirmed
** Changed in: compiz (Ubuntu)
Assignee: Ubuntu Desktop Bugs (desktop-bugs) => (unassigned)
** Changed in: libwnck
unsetting the patch status since those are workarounds, disabling
tooltips use is not a fix to the bug, could somebody open an upstream
bug too?
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs,
Sure, once the package is installed you don't need the build directory
any more. Glad you got it working.
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
u
a its soo nice hahaha thanks jason, it worked amazingly well. can i
delete all of the files that were downloaded and the created libwnck
directory?
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubunt
ego-sum-deus, I put detailed instructions, and a link to a binary
package, on my bog here: http://blog.jlogday.com/2009/08/jaunty-tooltip-
annoyance/ . The binary does not include Renzo's patch, but you if you
build the package yourself you should be able to apply both patches, one
after the other.
could someone please explain how to apply patches? im trying to use the
libwnck-notooltip.patch and don't know exactly how to get everything
patched and compiled. so, that would be awesome if someone could say how
to do this. thanks
--
tooltips stick when they shouldn't
https://bugs.launchpad.net
** Changed in: hundredpapercuts
Status: New => Confirmed
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.u
The libwnck-notooltip.patch works for me, thanks.
However I get persistent tooltips also when switching applications with the
window list applet, so I don't think the issue is related to the workspace
switcher only.
The attached patch disables tooltips for the window list applet. I have simply
c
Here is a patch to disable all tooltips for the workspace switcher.
Sanity has been restored to my desktop, may it help yours as well.
** Attachment added: "libwnck-notooltip.patch"
http://launchpadlibrarian.net/30706015/libwnck-notooltip.patch
--
tooltips stick when they shouldn't
https://bu
This bug is not excusively related to tooltips about drag and drop of windows
between viewports, but also to other general type of tooltips.
For example, when I switch from a workspace containing a terminal windows to
one containing firefox (with this page open) I get a persistent tooltip on the
the said bot just update the GNOME task by reflecting the
bugzilla.gnome.org bug change, you will notice that the ubuntu task
didn't change, the reason is that the GNOME bug is a duplicate
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notificat
I think the bot might have done that by mistake, don't know how this
"Bug Watch Updater" is programmed.
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubun
Is that normal to change the status of a bug to invalid without saying
why?
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-
** Changed in: libwnck
Status: New => Invalid
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
h
** Summary changed:
- window switcher tooltips stick when they shouldn't
+ tooltips stick when they shouldn't
--
tooltips stick when they shouldn't
https://bugs.launchpad.net/bugs/356702
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
-
27 matches
Mail list logo
