Re: What happened to the code freeze?

[Doug Simons]

Hello,

Fred wrote:

As far as I can tell none of the recent commits in gui or back is
related to any reported bug.

[snip]

I am referring to the ongoing changes to gui by Eric and Doug. All of
these are valid changes as far as I can tell. They surely fix some
behaviour that was annoying enough for them. But all these changes may
and did also introduce new issues to others. This is fine in normal
development mode, while trying to come up with a stable release it wont
help.

It's true that the changes I've been submitting aren't in response to bugs in the GNUstep bug system. We are actively fixing bugs in our own application. As an illustration, when we have a bug that affects only the Windows version of our product, I'm pretty sure that it's caused by a problem somewhere in GNUstep, but I don't know for sure until I dig in and debug exactly what's going wrong. This typically takes several hours of debugging, at which point I can see what the problem is, so I fix it.

Now, at that point I suppose I could enter a bug on savannah and then mark it as fixed, but I don't really see the point of doing that (and I'm under a lot of time pressure right now, as we are scheduled for a release next week!). So I've just been careful to review my own fixes and try to describe what I'm fixing when I check it in.

Since we're in 'code freeze' mode, I hope that someone (maybe more than one someone?) is looking at any changes that are checked in to make sure they look sane, and perhaps think about whether they might have unintended consequences.

I'm about to check in a significant fix, that substantially improves performance on Windows (with in-window menus). The change dramatically reduces the frequency of rebuilding the Windows menus. They were rebuilding with every event rather than only when needed. The resulting drag on performance wasn't just an "annoyance" -- it basically made editing text in an NSTextView almost unusable.

I've checked my code over carefully, and believe it won't have any negative consequences. As part of this fix, I corrected a bug in NSMenu which was never setting its supermenu ivar correctly, and improved NSMenuItem to only notify its menu that it has changed when something actually changes. It's conceivable that that could impact some other code, but is clearly more "correct" now than its former behavior.

The main impact of this change will only be on Windows for applications that use in-window menus. For those applications, there is a small chance that I missed something such that menus will fail to update when they should, now that they're not updating all the time (I don't think so, but it's worth watching out for).

I could hold off on submitting this change, but it seems to me like exactly the kind of fix that I (at least) would like to see going in right now. So I plan to check it in as soon as it's validated by some other people here. Please let me know if you see any problems with this change or any others that I submit.

We really appreciate the timing of this "feature freeze", by the way, since we are in the middle of a release. Knowing that things are relatively stable and only getting bug fixes is perfect for us right now. 

And while I'm at it, I'd like to say "THANK YOU" to everyone on the GNUstep team! The more I dig into the code, the more I'm reminded of what an incredible amount of work has gone into it, and despite the bugs (which are frustrating, and are the cause of my digging into the code in the first place) there is an amazing amount of functionality here that is working really well. Hopefully our small contributions will help GNUstep to be even better.

Cheers,

Doug