Re: cool stuff in cvs head

[Bjarne Steinsbø <bosteins broadpark no>]

muppet wrote:

> Bjarne Steinsbø said:
>  
>
> > BTW, it compiles cleanly on my
> > system, but not all tests run successfully in Gtk2.
> >    
>
> which tests fail?
>
>  
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" 
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00.Gtk2.................ok
t/01.GtkWindow............ok
t/02.GtkButton............ok
t/03.GtkGammaCurve........ok
t/04.GtkSocket-GtkPlug....ok 3/4Gtk-CRITICAL **: file gtkxembed.c: line 
188 (_gtk_xembed_send_focus_message): assertion `GDK_IS_WINDOW 
(recipient)' failed at t/04.GtkSocket-GtkPlug.t line 87.
t/04.GtkSocket-GtkPlug....ok
t/05.GtkListStore-etc.....ok
t/06.GtkLabel.............ok
t/07.GtkBoxes.............ok
t/08.GtkCombo.............ok
t/09.GtkRadioButton.......ok
t/10.GtkProgressBar.......ok
t/11.GtkStatusBar.........ok
t/12.GtkDialog............ok
t/13.GtkTooltips..........ok
t/14.GtkToolbar...........ok
t/15.GtkHandleBox.........ok
t/16.GtkMenu-etc..........ok
t/17.GtkItemFactory.......ok
t/18.GtkNotebook..........ok
t/19.GtkSimpleList........ok
t/20.GdkColor.............ok
t/21.GtkContainer.........ok
t/22.GtkListStore.........ok
t/23.GtkTreeStore.........ok
t/24.GtkTreeView..........ok
t/25.GtkTreeSelection.....ok
t/26.GtkSimpleMenu........ok
t/27.GtkClipboard.........ok
t/30.GtkCellRenderer......ok 29/21# Looks like you planned 21 tests but 
ran 8 extra.
t/30.GtkCellRenderer......dubious
       Test returned status 8 (wstat 2048, 0x800)
DIED. FAILED test
       Failed 0/21 tests, 100.00% okay
Failed Test            Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/30.GtkCellRenderer.t    8  2048    21    0   0.00%
Failed 1/29 test scripts, 96.55% okay. -8/855 subtests failed, 100.94% okay.
make: *** [test_dynamic] Error 2

I'm running perl-5.8.0 (haven't upgraded yet), Gnome-2.4 with associated 
libraries, and gcc-3.2.2.  (It's starting to show that it's several 
months since I last update the tool-chain....).  Compiled with "-O3 
-march=athlon-mp", and my perl is compiled with threading support.

> >  - 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.
>  
I'll keep looking also, just don't expect me to find anything...

> > 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.
>  
I hadn't tested that...  (clickety, clickety...) But nope, that's not 
it.  I turned off resizable, and even dropped reorderable and the 
center-alignment, but no change.

Does that mean that you don't see it?

> > 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).
As I feared then.  I'm on my own...  No promises on me spending much 
time on this, but I still feel that it could be useful.  (Going away to 
read some more documentation....  Ahhh!  So *that's* where the 
ocumentation about events have been hiding) Ah, I see what you mean by 
listening in to the events and not the signals.  It seems that Gdk has 
some useful functions, provided Gtk is compiled in some kind of debug 
mode.  I might have a go at this, probably combining it with setting up 
a test-environment for 2.5.

Off the top of your head, do you know if signals are implemented by 
stuffing artificial events back on the event-queue, or do they take a 
more direct route?  Please don't bother spending time on this, just in 
case you should happen to know...

Bjarne