Re: [gtk-list] Re: GTK Crash

[Owen Taylor <owt1 cornell edu>]

> > Is the problem reproducible? Could you say a bit more about
> > how you had the tooltips/widgets/windows set up and what
> > you did?
> 
> I've only ever had it happen to me once. Or at least, once that I know
> about. Occasionally I get mysterious crashes, but since it's not dumping
> core (is that the GTK startup capturing the core-dump facility or
> something?) I can only track it if I happen to be running under a debugger
> at that moment.

Yes, It looks like GDK catches fatal signals by default. If, after
calling gtk_init(), you do something like:

#include <signal.h>
signal(SIGSEGV, SIG_DFL);

I suspect it will dump core as expected (assuming, as always, you
haven't set ulimit -c 0)

> I'm still somewhat new to the GTK method of doing things, and so I expect
> that I'm doing some dumb things. For example, when I get an EXPOSE
> message, I actually get something like 4-6 of them. (Just as a wild guess
> - when I'm getting these expose events, is it possible that the widget is
> getting the expose event directly, and then its parent is sending an
> expose, and the parent's parent is sending an expose? It would explain a
> lot).

It might be because by default X sends multiple events for some
exposures. If you aren't paying attention to the event->area but just
redrawing your whole widget, then you can look at event->count and
ignore any exposure events that don't have event->count == 0. (Count
is the number of remaining exposure events to be set.) 

If, on the other hand you are getting multiple exposure events with
count == 0, then either you're doing something wrong (maybe calling
gtk_widget_draw() unecessarily), or there is a bug somewhere in GTK.
(Not at all unlikely.)

> The window that I'm having the strange behaviour in is a window divided
> into a top & bottom half via a 'paned' control, and each of those halves
> is divided into a left & right. Within those divisions is a frame, and
> inside that is an eventbox. Is this a good way to implement things? 

Well, if what you want is a 4 panes grouped in that way, and to 
receive events in all 4, then, yes, that sounds reasonable. On
the other hand, if you were going to put, say DrawingArea's in the
panes, then the EventBoxes would be unnecessary.

> (By the way - could you point me in the direction of some docs or
> something that would tell me how to deal with the mouse more fully?
> Right now I get a button event for both the left & right mouse
> buttons, but no mouse movement events. How do I distinguish between
> left & right...?)

Quick answers:

  gtk_widget_set_events (widget, GDK_POINTER_MOTION_MASK |
			 GDK_BUTTON_PRESS_MASK |
			 GDK_BUTTON_RELEASE_MASK)

  if (event->button == 1)    /* A button event */
    {
      do something for left button
    }

  if (event->state & GDK_BUTTON1_MASK) /* A motion event */
    {
      do something for left button down
    }

I don't know of any docs yet. As of right now, the best thing to
do is probably read the source.

Some possiblities: (biased toward things I've written myself)

  gtk/testinput.c 
    (unfortunately, complicated by XInput and motion history)

  KanjiPad, available from
    http://www.msc.cornell.edu/otaylor/kanjipad/
  If you ignore the functionality, and just pretend it's a drawing
  program, (all in kanjipad.c), it's probably a reasonably simple
  example. It probably won't run unless you have Japanese fonts
  installed, but you can still look at the code.

When I get the opportunity, I should use testinput.c as the basis
for a tutorial on:

  - DrawingArea widgets, and using offscreen backing pixmaps
  - Event handling
  - XInput support (after showing how to do things normally)

These are all things that aren't really covered yet in the GTK
tutorial.

> One last question - I've had my vertical pane (the one that goes across
> the whole window) suddenly stop allowing me to adjust vertically. It's
> acting as though the top & bottom children don't want their size adjusted,
> but I never put code in to keep them at a particular size. This was
> working for several days before it just stopped. I can see the pane
> control moving up & down a few pixels when I drag it, but no more. Any
> ideas what might cause this?

No idea. (The paned widget doesn't care about the children's resizing
desires - a concept which doesn't exist in GTK, except for toplevels,
so it's definitely a bug somewhere in the paned widget code. If
you figure out how to reproduce it, and can work up a short example,
I'd appreciate it.

Regards,
                                        Owen