Re: [gimp-devel] About Box, Part III
- From: Nathan Carl Summers <summersn cs byu edu>
- To: The Gimp-Developer Mailing List <gimp-developer scam xcf berkeley edu>
- cc: gtk-list redhat com
- Subject: Re: [gimp-devel] About Box, Part III
- Date: Thu, 20 Nov 1997 20:05:36 -0700 (MST)
On Thu, 20 Nov 1997, Nathan Carl Summers wrote:
> I upload a patch that fixes the other drawing bug. It was rather large.
> I don't have time to talk about how I fixed it, as the lab officially
> closed seven minutes ago and I will be kicked out any second.
First I would like to thank all of the people who helped me find these two
bugs. Without all the information other people who suffer from this bug
sent me, I still would be scratching my head.
My first thought was that when the pixels in the logo were drawn, they
went over the edge of the drawing widget, causing some nasty business with
signal handlers. I quickly added the ability to control the size of the
pixel blocks via a #define. It handled overruns quite fine. I kept that
feature in the patch because it was such a cool little feature, but I set
the #define to what was hardcoded in before.
Then I remembered that the picture was fully drawn when the window was
last dismissed via a click, but not when last dismissed via the wm or on
the first time. So I inspected the code to find the difference between
dismissal via a click on the client area and dismissal via the wm. It
turned out the window is actually destroyed when dismissed via the wm, but
only hidden when dismissed via a click on the client area. So I looked at
the initialization code to determine what it does differently in these two
It turns out the initialization code had a local variable that shadowed a
static global one. This isn't bad by itself (except it makes reading the
code kind of confusing and is against the GNU coding standard), but the
code was trying to use both variables. The compiler didn't say a thing
because C never complains about assigning 0 to a pointer because that is
NULL (even if NULL isn't really represented by the address 0.) I renamed
the local variable. This didn't completely fix the bug, although it
Finally, the idea occured to me -- what if it's being drawn on while it's
still 1x1? Subsequent verification showed that that was the case. While
all this time we thought it was the last frame we weren't seeing, it was
really the first frame. It was drawn, all right, but on a 1x1 drawing
area, which was then resized properly.
I'm begining to believe that widgets shouldn't get expose events before
they are allocated a size, if this is plausable and there isn't any
justification for the current behaviour. In the mean time, I added a size
check in the drawing code. It's not an elegant solution, but it works.
The locking-up bug in GTK I discovered when debugging still happens with
even all these changes. I'll see how small I can dice it down to and send
the program to the GTK list.
Another GIMP bug zapped!!!
] [Thread Prev