Re: Tooltips patch [take 1]
- From: Tim Janik <timj gtk org>
- To: Damon Chaplin <damon karuna eclipse co uk>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Kristian Rietveld <kris imendio com>
- Subject: Re: Tooltips patch [take 1]
- Date: Thu, 22 Mar 2007 13:22:00 +0100 (CET)
On Thu, 22 Mar 2007, Damon Chaplin wrote:
On Sun, 2007-03-18 at 01:22 +0100, Tim Janik wrote:
the main reason for ::has-tooltip is efficiency, because the new tooltips
potentially do many tip checks currently (ca. on every mouse motion, however
we might implement some coalescing to limit the number of tip checks to
16-25 per second), and for each such tooltip check, multiple widgets maybe
queried (the innermost child widget and all its parents worst case).
"has-tooltip" is a bit kludgy though. It would be better if it wasn't
needed. (It will probably confuse people using GUI builders. Or GUI
builders will have to add special code to avoid showing it.)
well, for GUI builders, if they set the tooltip markup, the property
will be TRUE automatically.
only signal aware builders should know that ::has-tooltip needs to be TRUE
if signals to query_tips are connected.
Do we need to emit "tooltip-query" in the motion event? Why can't we
just setup/update the timeout handler in the motion event and only emit
"tooltip-query" when the timeout fires? That sounds more efficient
anyway.
completely true. the current code implements the necessary principles (or
is meant to do that), optimizations like the one you suggest are definitely
planned (i think i said that in my last email already, basically checking
for new tooltips isn't required more often than 16-25 times per second).
If we do that, and tell people who use "tooltip-query" that they must
set the event mask to get motion events, then we may not need
"has-tooltip".
gtk already takes care of the event mask. basically we need motion hints
everywhere, otherwise we'd not be able to receive the necessary motions
on the parent window for a NO_WINDOW child. (at this point, users can't
really be expected to take care of setting up the proper event masks them-
selves, the combinations of custom widget windows, NO_WINDOW widgets and
inpout-only windows would be too hard to get right).
also, current gtk motion event handlers needs to be updated anyway to
be motion hint aware if they aren't already.
Damon
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]