Re: cool stuff in cvs head

["muppet" <scott asofyet org>]

Bjarne Steinsbø said:
> BTW, it compiles cleanly on my
> system, but not all tests run successfully in Gtk2.

which tests fail?


>   - The current renderer code gets some unexpected parameters when a dnd
> operation is started.  It looks to me as if the renderer in this case is
> used to render the selected row to a pixmap instead of a window, the
> pixmap is then dragged around following the cursor.  I haven't looked
> into fixing this problem, it was too easy to work around it by just
> ignoring the rendering request...

this is an API thing, it looks like.  all of the gtk_paint_* functions ask for
a GdkWindow*, but pass those on to gdk_draw_* and gdk_drawable_* functions. 
note that a pixmap and a window are both GdkDrawables.

so, i can fix this problem by changing all of the Gtk2::Style->paint_whatever
xsubs to ask for GdkDrawables instead of GdkWindows.  i haven't heard back
from the gtk+ guys on whether this is valid (i only asked five minutes ago),
but i think it will be the fix.


>   - After using the popup to select a new entry, the treeview will
> consider a dnd operation to have started as soon as the cursor enters
> the window.  Looks really weird...  The "workaround" is for the user to
> do the drop outside the window...  I've tried various stuff to try to
> track this one down, but no luck so far.

i can duplicate this.  it has something to do with how the mouse events are
being handled, which is something that i tend to figure out only by trial and
error, but appears to be related only to app code, not the bindings.  i'll get
back to you on that.


> Anyway,
> the problem is that the window doesn't update correctly when expanding
> the list.  This causes the renderers to put data the data at the
> position they used before, not to the new position....

i think this is a side effect of the fact that your columns are resizable.


> Does anybody have some working code of how to listen in to all the
> signal activity going on in a Gtk2 app?  There seems to be a way to
> listen in to the signals using g_signal_add_emission_hook(), and this
> certainly could be useful for debugging purposes.  But the xs-code is
> commented out.  What's the full story?

most of that sort of thing is unwrapped because of either lack of interest
(yet) or the thought that "gee, that's esoteric, let's look at other stuff
first."

you may be more interested in monitoring all events, rather than single
signals (some don't allow hooks, you see).  you should be able to uncomment
the necessary functions and play with them as you like; if you have any
problems, email me offlist and i'll help you out (some of them require
callbacks, which aren't straightforward if you aren't used to C).

-- 
muppet <scott at asofyet dot org>