Re: Callback based tooltips (Re: New tooltips API, continued)
- From: Tim Janik <timj imendio com>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Callback based tooltips (Re: New tooltips API, continued)
- Date: Tue, 25 Apr 2006 10:32:22 +0200 (CEST)
On Tue, 18 Apr 2006, Matthias Clasen wrote:
On 4/11/06, Kristian Rietveld <kris imendio com> wrote:
You sure did :). As I said earlier, I pretty much prefer your simpler
proposal once we find solutions for the keyboard handling (which will
probably automatically give us API for ondemand tooltips?), dynamically
changing tooltip texts and agree on how to handle custom tooltip
windows. I hope we can agree on these issues soon, so I can come up
with a patch before the middle of next week.
I have to agree with Owen's earlier comments on the callback-based approach
I'm not really enthused about a callback-based approach here. It
seems simple at first glance, but I think it would get pretty complex
for the case where tooltip texts or tooltip areas change dynamically.
(For tooltip areas, think scrolling in a GtkTreeView.)
can you try to be more specific please?
using a non-callback based approach will get very complex with a push-only
model. think of tracking the mouse position for dynamic tooltiping on an
insensitive widget. or think per mouse pointer position tips if you can
only set tooltip *areas*.
also, the popup/popdown logic will be more complicated if it is handled
by gtk internals *and* the user as in kris' proposal, there's a high
probability it'll be inconsistent even.
Unless we can find a way to handle
- Ctrl-F1 keyboard mode
i've adressed that in my last email to kris.
- programmatically triggered tooltips
can you provide a use case first here please?
when would a program popup a tooltip without the initial delay?
and, why isn't the tooltip delay set to something short like 1ms
in that case anyway?
- grouping (as for e.g. the toolbar example)
please read my last email to kris here. i'm still missing a
use case for having more than one group anyway.
- dynamic tooltips
do you mean more dynamic than the mouse pointer position relative tips
that my proposal allowes for? then, please elaborate.
Kris proposal (based on Owens ideas) seems more complete.
that is too vague of a statement. if you see a specific technical
issue that is covered by kris proposal but not mine, you'd be of
great help to all of us if you nailed it and pointed it out in detail.
if some of the items you raised have become obsoleted by kris' or
my recent emails, please just forgive me for my late reply ;)
] [Thread Prev