Re: [Gaim-devel] GTK and parent widgets

[Decklin F. <de...@re...>]

Robert McQueen writes:

> I think this is because GtkImHtml extends GtkTextView, so it's struct
> should contain the entirety of GtkTextView's as the first element, which
> in turn contains GtkTextView's parent, all the way up to GObject.

Yeah, javabsp explain this to me too. I was reading a thread about
exactly this topic on linux-elitists all week, and it didn't dawn on me
that I was seeing it in practice until now. :-)

> Because we never actually added the tooltip to the textview as a child
> element, and nor is it sane or correct to,

My instincts say the same thing. On the other hand, although it's not a
child as far as layout goes, there is a relationship. Two questions:

- What does gtk itself do with "standard" tooltips? No parent?
- If we only need plain text here, can't we just use the toolkit instead
  of calling pango ourselves? How hard is that?

If all toplevel windows (even if they're tooltips) are supposed to be at
the top of their own widget hierarchy, I would be comfortable with just
letting it go, removing the blist kludge, and blaming cleanice (I assume
they'll release again soon to fix this bug, and I can just replace my
"broken for testing purposes" package with a correct one).

But if you want to kludge it, here's the patch. I should note that this
fixes another trivial bug: at the end of gtk_imhtml_tip, when the tip
window is actually mapped, the gtk_window_move and gtk_window_show calls
are in the wrong order. This means that the tooltip pops up at (0, 0)
for an instant and then moves itself to the right place. Very annoying.
Regardless of what is done about the parent issue, this should be fixed.
It's trivial enough to describe so I won't bother making a separate
patch without the kludgery.

Thanks for the GTK explanation, btw. Hopefully I'll be more active again
in the future...

-- 
things change.
de...@re...