Shared publicly  - 
gtk drives me mad sometimes.
More so since I try to use it to write an application :-)

Latest example - GtkTooltip. How can I influence the position and delay of the tooltip? All the googling I've tried shows me either nothing or references to the old deprecated GtkTooltips (with an 's' at the end) APIs.
Mind you, overall documentation for GtkTooltip leaves a lot to experimentation, but with lots of trial and error I got that working... why does this have to be so hard?
Øyvind Kolås's profile photoDirk Hohndel's profile photoEmmanuele Bassi's profile photoJavier Jardón's profile photo
+Ulf Hofemeier: That sets the area that the tooltip reacts to. It doesn't set where the tooltip actually shows up, or how long of a delay until it shows up..
+Ulf Hofemeier what Linus said - plus this whole thing gets much more complicated if your tooltip is supposed to be in front of a larger cairo canvas and you want the tooltip only in small areas of that canvas, and with different text depending where...
Think (random example) the profile plot of a dive where you want to mark events with little warning triangles and have a tooltip show the text of that event if the mouse hovers over that triangle...
You're encouraging me to finally work on perf --gui :-)
ahh. gtk_settings_set_long_property should allow me to override the timeout just for subsurface... that is "discouraged", but it's worth playing with :-)
+Dirk Hohndel nah, app-wide it is, but it is usually synced to XSETTINGS. if you override that you won't upload that to other gtk apps, so everything is fine.
Positioning seems to me a job better done outside the app by something with knowledge of the surroundings. It is related to applications messing with window positioning and, worse, stacking order, something I totally loathe (and thankfully can be blocked with a good window manager).
I am wondering though whether a tooltip is really what you want. Maybe just take a GtkWindow and mark it as tooltip or so. Am pretty sure the friendly folks on #gtk on gimpnet have the right solution for you.
+Måns Rullgård: yes, you'd like to have positioning done automatically.

BUT. If the tooltip area is pretty small (which is the case here) and there are potentially several ones close-by, putting the tooltip equally far away as for a big widget is just very ugly. The tooltip ends up being closer to - or indeed on totally the other side of - some other widget than the one that you want it to trigger for!

That's also why a quicker reaction ends up being nice. Something that just shows up when you hover above it without having to wait for a second (or whatever the default tooltip timeout is). Very useful when you want to find the one you care about, and there are several to choose from.

And yes, clearly tooltips weren't designed for that particular use, but they seem otherwise very close to what that case really wants.
+Lennart Poettering well the gtk_settings_set_long_property does the trick for the timeout, so that works now - thanks for the hint.
+Linus Torvalds seems like your crystal ball is better than mine; I don't know what +Dirk Hohndel is working on. You're right too, that consistent placement of tooltips for a row of buttons (or whatever) is desirable, and the algorithms usually used for automatic placement are poor (to put things politely). I still think a mostly automatic placement should be possible, perhaps guided by some hints provided by the application.

In many cases I'd actually prefer not having tooltips in the usual sense at all, instead displaying an explanation in a fixed location (status bar) as is done in some apps. Someone will probably tell me this is old-fashioned and popups are the "modern" way of doing things (despite having been around for decades). I don't care.
+Måns Rullgård Don't feel bad that +Linus Torvalds has a better crystal ball than you do - he and I are working on subsurface together, so he knows exactly what I'm trying to do...
And yes, I'd love to be able to give some hints... something like "ideal position right-aligned text ending 10 pixels above and to the left of the mouse pointer" - and have the algorithm deviate from that where it doesn't make sense.
In the specific program we're talking about there are little markings along a graph that are explained with a tooltip if you hover over them - feels like a natural interface to me.
Culture clash. Good to see that happening, it was about time. Should teach both cultures something interesting.
+Dirk Hohndel: the faster tooltip reaction time definitely helps the experience. It also makes it a bit less disturbing that the tooltip then sometimes shows up in crazy locations - because at least now the "tool tip shows up" action itself is so closely related to the "you moved the mouse over it" that there is that temporal association, even if the spatial association is broken.

I've been trying to figure out what the gtk logic for tooltip location is, and I can't. It's crazy. It seems to depend on what else is around it, and which side of the tooltip you entered, so the tooltip sometimes shows up on the left, sometimes on the right etc.

Sometimes gtk places the tooltip quite nicely close, but that's usually only the case when it has to (because the edge of the screen is fairly close). So there's clearly some logic there that explicitly tries to keep the tooltip away from the widget.

I suspect it does that exactly so that the tooltip wouldn't cover any part of the widget that it's a tooltip for - but if so, the code really should have taken the size of the tooltip area into account. As it is, the default placement really is "too far away", even if it under some circumstances ends up being quite nice.
One could reconsider the approach and probably attain better control by drawing the labels with cairo as part of the graph widget, using knowledge of the graph and text sizes together with mouse position.
+Øyvind Kolås I think that's what I'll end up doing after all...
It just seemed so obvious to do this with a tooltip :-( — it'll give you the coordinates of the pointer, or if the tooltip was activated through the keyboard. if you need to show a complex tooltip, then use using the GtkTooltip object passed to the signal.

as others have said, calling:

g_object_set (gtk_widget_get_settings (widget), "gtk-tooltip-timeout", new_timeout_in_msecs, NULL);

will change the tooltip timeout setting for the current process.
Add a comment...