2008-04-08

Bugfixes and Refactoring; Xcode Goes Bananas

Loads of updates today. First of all, almost all of the classes are now javadoc commented. I’ve just got the skinned classes left to do, but as I might revist those I’m not documenting them for now. I need to document each class’ members, too. The autodocs generated by doxygen now look quite good, although there’s a lot of scope for more detail.

Next up, bugfixes. John spotted an overflow problem in the Font and MonoFont scanGlyph() function which was preventing font bitmaps with dimensions >=256 pixels from working properly. The MultiLineTextBox restores its visible/invisible property properly after being resized. The ContextMenu crash I found earlier seems to have been a bug in the PacMan demo rather than the ContextMenu itself, which I’ve also fixed.

On to the big changes now. There are two big API changes in the latest SVN code. I’ve refactored the active/inactive/focused/blurred system. The “active” flag has been replaced by a “hasFocus” flag, “setActiveGadget()” has become “setFocusedGadget()”, “_activeGadget” has become “_focusedGadget”, and the “setActive()” method has been absorbed into the “focus()” and “blur()” methods. There isn’t a huge number of differences, but it has made the whole thing much easier to follow.

The next big change is the visible/invisible system. This has bugged me for a while. If I call “gadget->setVisible(false)”, the gadget stays on the screen. I have to call “gadget->erase()” to make the gadget go away, but that doesn’t make “gadget->isVisible()” return false. What is going on?

The problem is that the “visible” flag and access methods don’t refer to gadget visibility; they refer to whether the gadget’s drawing methods are enabled or not. What I’ve done is give this block of functionality more sensible names. The “visible” flag has been replaced with a “drawingEnabled” flag. The “setVisible()” and “isVisible()” methods have been removed, and “enableDrawing()”, “disableDrawing()” and “isDrawingEnabled()” methods have taken their place. As an added bonus, “isDrawingEnabled()” only returns true if the gadget is neither deleted nor hidden, which makes working with it a little easier.

It’s now possible to determine if a gadget is hidden or not by calling its “isHidden()” method. The hidden status is stored in a new flag. There’s another new flag, too - I’ve moved the “visibleRegionCacheInvalid” bool into the flags struct.

Another thing that’s been bugging me is the spelling of “closable”. All occurrences of “closeable” in the flags, flag enum and getter methods are now spelt correctly.

Lastly, I’ve split the PacMan demo up into separate files for each class. Much easier to read now.

All of this has the potential to cause mayhem for people who are upgrading…

In other news, I decided to try and fix the ContextMenu crash bug last night by using the SDL version of Woopsi in Xcode. Synced the two versions in SVN, pulled down the latest copy in OSX, loaded up Xcode. Or tried to. Xcode crashed before it had finished loading. It refused to start up.

Had a look around on the internets, which recommended that I try repairing permissions in the Disk Utility. That didn’t work. The other suggestion was that it could be a corrupt setting in my user’s library folder. Tested this by moving everything out of the library to another folder. No luck. Started copying everything back, but due to the incompetence of the user stupidity of Finder I found that I’d copied some of the folders into other sub folders, and didn’t have any way of getting them back. Nuts.

Unfortunately, my Time Machine backup was a week out of date due to the incompetence of the user way Airport Extreme disks have to be mounted manually before Time Machine can back up to them. After a hell of a lot of fighting with Time Machine I got it to restore most of my settings. The bookmarks I’ve lost can’t have been all that important as I can’t remember what they were.

Xcode still didn’t work.

However, I tried to load it up this morning and it worked fine. Madness.

Comments

Jeff on 2008-04-09 at 00:28 said:

One thing to look out for with Xcode is that it has a couple of “user-specific” files. If you look inside the xcodeproj

http://woopsi.svn.sourceforge.net/viewvc/woopsi/WoopsiSDLXCode/trunk/WoopsiSDLXCode.xcodeproj/

you can see

antonydzeryn.pbxuser antonydzeryn.perspectivev3

Personally, I would try deleting those before loading the project into XCODE. It should have little impact since those are your “xcode preferences” rather than “project information” - ie, they don’t get read if I download the SDL project and try to use it.

I doubt highly that they should even be in the svn repository, but they are difficult to avoid because you don’t check in the components of the .xcodeproj, you just do the whole package.

Stupid design on Apples part, if you want my opinion.

ant on 2008-04-09 at 07:36 said:

Yeah, I was a bit dubious about those files. Visual Studio at least makes its user prefs separate from the project file.

In this case, though, I was just trying to load Xcode, not trying to load a project. Very odd.