Re: Callback based tooltips (Re: New tooltips API, continued)

[Tim Janik <timj imendio com>]

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
> here.
>
>   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.

> Matthias

if some of the items you raised have become obsoleted by kris' or
my recent emails, please just forgive me for my late reply ;)

---
ciaoTJ