Tue 29th Jul 2008
As a class, we have the choice of what the focus of one of my topics this semester is going to be.
I’m voting for Compiler Construction. Even though we’ll be doing it in Java (ugh!), it is something I was disappointed to find wasn’t otherwise offered.
If you need convincing, read Stevey’s Blog Rants: Rich Programmer Food.
Now, if only I can convince the rest of the class!
I finally got around to updating Xcode to 3.1 yesterday.
There’s some great stuff in there. At last, the autocomplete of method names puts in tokens for the arguments, so you can just click on the token and then overtype - or just delete it in one go with (forward) delete.
Another cool thing is something that I’ve seen in NetBeans, but the default settings there for it are just annoying. Previous instances of the currently selected variable are highlighted. In Xcode it is a much subtler underline, much better than bright yellow.
This is better than NetBeans in another way - you can click on the item, and access a special contextual menu that allows you to edit every instance of the variable name in your current scope. Thus, refactoring is made much easier.
I’m sure there was something else I really liked too, but I can’t recall what it was.
I got tripped up by how C represents Boolean values today.
To save space, but more to make comparisons easy, I was storing a series of bits (representing hours in a day) as integers. I had built up some structure so that my sub-classed NSMatrix could use Cocoa Bindings and be connected to a Controller, so that changing the values in an NSArray of Integers in that controller would change the selected cells in the matrix, and changing the cell selection similarly affects the values stored in the array.
But, and it took me a while to figure this out, I was having problems getting the data back from the array properly. For some reason, numbers greater than 255 were not displaying properly. Basically, I seemed to be losing bits off the top. So I spent ages rewriting the code using longs, long longs, and unsigned long longs, but nothing seemed to work.
Eventually, I pinpointed the error to this: in C an integer with the lower 8 bits all set to 0 evaluates to FALSE.
It doesn’t seem to matter if the integer is a long, or whatever.
Thus, when I checked, using a bitwise AND (& operator), the stored value against a value representing the cell value, and stored it directly in a BOOL, and then used said BOOL to set the selection of that cell, it was evaluating to False for all values greater than 255.
All I needed was to change one line of code:
BOOL highlight = (value & bin);
becomes:
BOOL highlight = (value & bin) > 0;
All fixed.
Mon 14th Jul 2008
You can’t have a class with the name “Availability” in a project built with XCode 3.1.
You can with XCode 3.0, but CFNetwork, and I assume a heap of other classes use a class called “Availability” to define if objects are available in a particular version of the OS.
I’m trying to make a control that allows me to indicate when a record in my application is synced with the AddressBook person of the same name - I have made it so that I can only enable syncing when a person with the exact same name exists in both places, but to indicate it, I want to use a button that shows a pressed-in state, but also alters the image.
I want the image to be black-and-white by default, but when pressed in, it becomes coloured.
Apparently, this isn’t possible. You can either have a button which changes it’s image, or displays a pressed in look.
Might have to subclass it.
Update: You can subclass it, but there’s no need to. Just give yourself a reference to it (myButton, for instance), and then:
[[myButton cell] setShowsStateBy:NSPushInCell | NSCellLightsByContents | NSCellLightsByBackground];
Thu 10th Jul 2008
It’s not possible to directly hook up an NSSegmentedControl (or NSSegmentedCell) to a Core Data controlled NSArrayController (or any, for that instance). I wanted to be able to use one of these controllers to allow the user to select one, many or all items from the array.
To define the behaviour a little bit more: You can select the first item in the control (which will be called “All”), and it will select or deselect all of the other items, depending on what it’s state becomes. If you click on another segment, then it will toggle the selection of that segment. If all segments are ON after pressing a segment, then the first segment must also display ON, otherwise it will be OFF.
I did it by creating a new class: SegmentController. (I know, I should put on a prefix…)
SegmentController has two required IBOutlet variables, which refer to the NSSegmentedControl, the NSArrayController, and a property NSMutableIndexSet, which stores, sets and gets the selection indexes (I think this should be indices, but I’ll stick with Apple’s convention). I also have a sortDescriptors array, so that this object can sort the array controller.
There are a couple of limitations, which I might look at how I deal with - for instance, the NSSegmentedControl must have exactly one more segment than the NSArrayController has items. I’m using it to select one or more days, and this number doesn’t change. It should be possible to dynamically create the right number of segments, and populate them with values (I even have a readonly field called shortName set aside in my Day objects for this), but at awakeFromNib the NSArrayController is still empty, and I can’t figure out a nice neat way to force a fetch.
Hooking up the elements in Interface builder is easy. Create the NSArrayController, and set that up however you need to. Do the same with the NSSegmentedControl - at this stage you’ll need to put values in each of the segments. Now, create a new instance of SegmentController (you might need to add the class files to your XCode project first). Connect the two outlets up to the required objects.
Now, in the Bindings Inspector, connect up you’ll want to make the Selection Indexes parameter point to the selectionIndexes model key of your Segment Controller object.
Finally, make the selector of the NSSegmentedControl point to the selectSegment: action of the Segment Controller.
I did notice a slight delay between deselecting one segment and the “All” segment deselecting. A simple optimisation - moving the call to segmentCount out of the loop test and into a local variable made it much smoother.
That should probably do it. It might need a bit of tweaking. You should be able to have multiple instances of this in your project, if it is required. It’s been designed that you’ll need a seperate one for each Segmented Control, as it refers to the objects it is connected to, rather than the sender of the message.
My source code is here: SegmentController.zip
I’m enamoured with Mercurial for all of my version control needs. I’d like Versions to work with it, but the response I got from the developer suggests it never will. “UI of Versions is designed completely around the concept of centralized version control ” I can see that the same type of interface would work quite well with Mercurial, or another DVCS, without too many hassles.
Still, even just with the CLI, I’m coping.
A couple of days ago I started playing with Trac for bug tracking. I had used Bugzilla (not for my own projects, but I use it at work), and it doesn’t work properly with Mercurial. The good news is that Trac does, almost out of the box.
The trac-post-commit-hook works fine, and allows me to have a repository linked in with my trac store, and when changes are checked in that have “fixes ticket:X”, it automatically updates the trac for that ticket. It’s a bit of a repetitive process to set it up (you have to manually edit both the repo/.hg/hgrc file, and the trac/trac.ini file to add support for each other, but it’s easy enough to do).
The only annoyance is that the username isn’t quite the same in both - so changes made in Trac have the username matt, whilst those made in mercurial have the default username there - which includes my full name and my email address.
Tue 8th Jul 2008
I’m currently learning stacks (and maybe developing a useful application along the way) about Core Data and Cocoa Bindings.
I managed to hook up all of the “first level” Entities to UI elements, but was struggling a bit figurng out how to get the to-many relationships to work.
To make all elements of the type Person appear in an NSTableView, you can create an NSArrayController, set it to the Entity type, and put Person in the relevant field. Then all people will appear in the list.
If you have a manager, who might supervise zero or more people, then how do you get a sub-set of People. More specifically, how do you get a just the other side of a To-many relationship.
I thought I was going to have to resort to actually writing some code, and use a Predicate, or something like that. But there is an IB only method.
You can create an NSArrayController, and as well as putting in the Entity type (and hooking it up to the Managed Object Context), just put that it gets it’s Content Set from another object - in this case it would be People.selection.supervises (or whatever it is called).
This isn’t quite flawless - if you just hook up a button to the “add:” outlet, then it doesn’t quite add properly - the reverse of the attribute is not set. I had to make up an IBOutlet in my window controller that creates a new component, and sets the relationship up.
Which meant I ended up having to write two lines of code. For each relationship.
Sat 5th Jul 2008
Three languages. Three different Object Relational Mapping systems. One operating system.
Over the past couple of days, I’ve been madly learning how to create programs in Core Data, using Objective C and Cocoa. It’s given me plenty of food for thought, and made me perhaps think that it’s not that SQL Alchemy rocks my world, it’s just that J2EE/EJB is just ORM done wrong.
I actually got exposure to SQL Alchemy in detail before J2EE - I first came across them at the same time, but using SQL Alchemy was at work, and I basically had to learn in 2 days what a full semester worth of J2EE taught me. Perhaps that was just because learning the python stuff was so damn easy.
Now that I understand just how cool an Object Relational Mapping is, getting into Core Data was easy. Creating the same schema in SQL Alchemy (actually, using Elixir, so it was just object creation), and then in a Core Data xcdatamodel - basically the same process, was even simpler in Core Data: simply because it is a GUI tool, and you can see the whole model in one go, instead of having to scroll through a text file examining classes.
But doing GUI programming using the ORM is where Core Data really shines. Using Cocoa Bindings, you can just plonk down an NSTableView, and tell the object where it gets it’s data from. If you have two GUI widgets using the same data model, and you change selection in one, it even changes the selection in the other!
Core Data also helps look after Undo, Saving and all other sorts of goodness I haven’t even come across yet.
The only thing that Core Data isn’t good for is a multi-user system - or more precisely, a system where multiple users are accessing the data at the same time. I’ve used SOAP as the messenger format, where I had a rich client accessing services provided by my server, but this is cumbersome. I’ll just use Pylons, or perhaps Django to do a web application - where the interface is largely a Web Browser. In this instance, it will probably be best to just stick to a python-based approach. I’m tempted by WebObjects, but that would still require me to use Java.
If only Apple would release a distributed Core Data. I might be able to do something kind of cool with Distributed Objects, for a rich client, at least, but for Web, I may as well do the whole thing in python.
All of the cool kids are talking about Joel Spolsky’s post about disabling menus.
I agree with Gruber et. al., he’s dead wrong. Disabling a menu is a simple, yet powerful method of implicitly informing the user what she can or cannot do at the moment. Hiding menus, a-la Windows/Office “Show only recently used items”, however, it truly evil. This is not even hiding disabled items, just hiding ones that haven’t been used recently. Now, if I use one machine, and then go to another, it doesn’t know which ones I have used recently. Bullshit Incarnate!
Anyway, real users don’t use menus. Other than to learn the keyboard shortcuts.
The Old New Thing had a post way back in 2004, which has a mostly sensible answer: When do you disable an option and when do you remove it? Not strictly dealing with just menu items, but regardless, still logical.
