Menu
▾
▴
pidgin-devel
|
From: Decklin F. <de...@re...> - 2003-04-06 13:49:31
|
Cleanice (the GTK theme) was segfaulting whenever gtkimhtml popped up a tooltip. I tracked it down to a line like this: strstr (g_type_name (GTK_WIDGET_TYPE (widget->parent)), "CheckButton") where widget->parent was NULL. This is the only widget I've seen this problem with, but I'm not familiar enough with GTK internals (or used to sort of vaguely be, but then 2.0 came out) to understand who's at fault here. Is it a bug in gaim, for not giving the widget a parent? (It was not immediately apparent how to fix that.) Or should cleanice not assume there will be one? This happens inside the gtk_paint_layout call on line 1327. -- things change. de...@re... |
|
From: Robert M. <rob...@de...> - 2003-04-06 16:40:36
|
On Sun, Apr 06, 2003 at 09:49:18AM -0400, Decklin Foster wrote: > Cleanice (the GTK theme) was segfaulting whenever gtkimhtml popped up a > tooltip. I tracked it down to a line like this: > > strstr (g_type_name (GTK_WIDGET_TYPE (widget->parent)), "CheckButton") > > where widget->parent was NULL. This is the only widget I've seen this > problem with, but I'm not familiar enough with GTK internals (or used to > sort of vaguely be, but then 2.0 came out) to understand who's at fault > here. Is it a bug in gaim, for not giving the widget a parent? (It was > not immediately apparent how to fix that.) Or should cleanice not assume > there will be one? > > This happens inside the gtk_paint_layout call on line 1327. Funny, we fixed the exact same problem with the blist tooltips. It's a bug in both Gaim and in Cleanice. Our bug for making tooltip windows without setting the parent like Gtk does on it's tooltip windows, and Cleanice for not checking parent was a valid pointer before dereferencing it. Cleanice's problem is fixed in their CVS, so it shouldn't crash, and we fixed it in the case of the buddy list so it doesn't tickle that bug in released Cleanice versions anyway. See: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gaim/gaim/src/buddy.c.diff?r1=1.463&r2=1.464 I'd guess we just need to do the same with our GtkIMHtml tooltips too. Regards, Rob |
|
From: Decklin F. <de...@re...> - 2003-04-06 23:45:03
|
Robert McQueen writes:
> Funny, we fixed the exact same problem with the blist tooltips.
Yeah, I thought I remembered seeing something about it being fixed, so I
wasn't sure if I was going crazy for a minute :-)
> Cleanice's problem is fixed in their CVS,
thanks, I'll update my local packages.
> I'd guess we just need to do the same with our GtkIMHtml tooltips too.
This seems to not be quite as simple. I tried the obvious (OK, not that
obvious... why text_view is not a pointer escapes me):
diff -u -r1.170 gtkimhtml.c
--- gtkimhtml.c 5 Apr 2003 03:06:55 -0000 1.170
+++ gtkimhtml.c 6 Apr 2003 23:37:58 -0000
@@ -1354,6 +1356,7 @@
imhtml->tip_timer = 0;
imhtml->tip_window = gtk_window_new (GTK_WINDOW_POPUP);
+ imhtml->tip_window->parent = GTK_WIDGET (&imhtml->text_view);
gtk_widget_set_app_paintable (imhtml->tip_window, TRUE);
gtk_window_set_resizable (GTK_WINDOW (imhtml->tip_window), FALSE);
gtk_widget_set_name (imhtml->tip_window, "gtk-tooltips");
But that crashes when we try to destroy the widget. I don't get this
either, because we in buddy.c that tip window get destroyed and there's
no crash. I could kludge around it by doing this:
@@ -379,6 +379,7 @@
}
/* We've left the cell. Remove the timeout and create a new one below */
if (GTK_IMHTML(imhtml)->tip_window) {
+ GTK_IMHTML(imhtml)->tip_window->parent = NULL;
gtk_widget_destroy(GTK_IMHTML(imhtml)->tip_window);
GTK_IMHTML(imhtml)->tip_window = NULL;
}
@@ -403,6 +404,7 @@
{
/* when leaving the widget, clear any current & pending tooltips and restore the cursor */
if (GTK_IMHTML(imhtml)->tip_window) {
+ GTK_IMHTML(imhtml)->tip_window->parent = NULL;
gtk_widget_destroy(GTK_IMHTML(imhtml)->tip_window);
GTK_IMHTML(imhtml)->tip_window = NULL;
}
But that's just icky. What should I be doing here? My GTK-fu is
extremely rusty.
--
things change.
de...@re...
|
|
From: Robert M. <rob...@de...> - 2003-04-07 05:24:41
|
On Sun, Apr 06, 2003 at 07:44:16PM -0400, Decklin Foster wrote: > This seems to not be quite as simple. I tried the obvious (OK, not that > obvious... why text_view is not a pointer escapes me): 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. This is easy to rectify, set the parent to the imhtml widget itself. > But that crashes when we try to destroy the widget. I don't get this > either, because we in buddy.c that tip window get destroyed and there's > no crash. I could kludge around it by doing this: The crash is more interesting. GtkTextView's parent turns out to be GtkContainer, for the purpose of embedding widgets like images and such, which means the removal of a child usually means shape-changing and stuff is necessary. When Gtk goes to free up the tooltip it winds up calling gtk_text_view_remove with the tooltip window as the parameter. This function implements gtk_container_remove in the textview special-case. Because we never actually added the tooltip to the textview as a child element, and nor is it sane or correct to, this function's sanity check (that it actually iterated through any child widgets) fails if the GtkImHtml has no smileys/images/HRs in. The best fix for this I can't really fathom. I don't even know why Cleanice calls any methods on the parent of the tooltip. Gtk2's default theme engine doesn't seem to. The Gtk2 tooltip code doesn't ever seem to set the parent on it's tip windows either. Maybe what we're actually doing is hacking around a bug in Cleanice that we tickle because we paint pango directly into our tip window, rather than using a GtkLabel like the real tooltips do, so maybe the NULL-setting hack is the best we can hope for. > But that's just icky. What should I be doing here? My GTK-fu is > extremely rusty. > > -- > things change. > de...@re... Regards, Rob |
|
From: Decklin F. <de...@re...> - 2003-04-07 20:00:29
|
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... |
|
From: Ka-Hing C. <kh...@ja...> - 2003-04-07 20:10:53
|
On Mon, 2003-04-07 at 13:00, Decklin Foster wrote: > 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. I did that because (start quoting from gtk-doc): void gtk_window_move (GtkWindow *window, gint x, gint y); Asks the window manager to move window to the given position. Window managers are free to ignore this; most window managers ignore requests for initial window positions (instead using a user-defined placement algorithm) and honor requests after the window has already been shown. So it is possible for Window managers to ignore the gtk_window_move call if the window is not actually shown. But well, none of the wm seem to do this, so I guess it doesn't really matter. - Ka-Hing Your depth of comprehension may tend to make you lax in worldly ways. |
|
From: Decklin F. <de...@re...> - 2003-04-07 21:24:50
|
Ka-Hing Cheung quoted the following from gtk-doc: > void gtk_window_move (GtkWindow *window, gint x, gint y); Asks the > window manager to move window to the given position. Window managers > are free to ignore this; most window managers ignore requests for > initial window positions (instead using a user-defined placement > algorithm) and honor requests after the window has already been shown. I think the docs are confused here as well. They're talking about how WMs honor hints, but gtk_window_move doesn't touch any hints, as far as I can tell -- it actually calls XMoveWindow, or just changes the coords that the window will initially be mapped at (which are different from PPosition or UPosition geometries) -- at least, override-redirect windows wouldn't work unless it did this (and they do work). I guess I'll check the source and file a bug report with them or something. -- things change. de...@re... |
|
From: Decklin F. <de...@re...> - 2003-04-07 20:01:32
Attachments:
tip.diff
|
Er, helps if I actually attach the damn thing. -- things change. de...@re... |
|
From: Adrian D. <adr...@gm...> - 2003-04-07 14:52:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I wonder why nobody noticed but there are only win0.60-alpha files on the servers. Not a single .bz .rpm or anything for 0.60 on linux. Hope that cvs works. Adrian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+kawAFyp8AaAsy0wRAkyJAKCnc6E3vxufk2X1WD3RHAjpsv/F5ACfbjgH M4VSutWryTSRX1IcjsiBbS4= =c9Yd -----END PGP SIGNATURE----- |
|
From: Decklin F. <de...@re...> - 2003-04-07 21:19:30
|
Ka-Hing Cheung writes: > So it is possible for Window managers to ignore the gtk_window_move call > if the window is not actually shown. But well, none of the wm seem to do > this, so I guess it doesn't really matter. This is because it's created with GTK_WINDOW_POPUP, so, it has override-redirect set on it. WMs cannot intercept ConfigureRequests for any such window (or reparent it into a WM frame, or anything like that), and ordinarly will not even be notified of its existence by the X server unless they do something evil. Not handling ConfigureRequests properly for iconified windows would just be a bug, not a violation of the ICCCM. :-) Being more familiar with Xlib than GTK+ 2.x, I find it kind of odd that I can't just make a window and specify its x and y co-ords (I noticed a function for geometry hints, but that doesn't affect anything for windows that aren't managed by a WM). I suspect that I'm supposed to just call move before show like this and that'll tweak the values that eventually get used when something calls XCreateWindow. It feels counterintuitive, though. In that case, the problems with different WMs (for managed windows, obviously) probably have do do with conflicting ideas about how to interpret a MapRequest with a non-(0,0) position set on the actual window as well as a (perhaps incomplete) geometry hint, and not ConfigureRequest (which is a whole different can of worms). I don't really know. At any rate, the blist tooltips do it my way already. :-) -- things change. de...@re... |
|
From: Ka-Hing C. <kh...@ja...> - 2003-04-08 00:13:57
|
I think that says how much I know about Xlib/WM spec - Ka-hing We don't know one millionth of one percent about anything. |
Thanks for helping keep SourceForge clean.
X