Chomping at Chandler

Well, I’ve turned off spell checking, so no more crashes. However, still no search bar!

The control is created and is getting called on occasion (e.g. to get its size when the window changes size). It’s just not visible.

One thing I had to do to the control before adding it to the toolbar was to remove it from its superview. When the control was created its “Window” was set to be the Chandler window. However, the toolbar API doc specifically says that the control should be created with a NULL Window parent. I thought the best I could do (since I have no control over how the control is created) was to call HIViewRemoveFromSuperview() on it. From the debugger, I could tell it certainly set the control’s window to NULL, so I think it’s the right thing to do.

However, whenever I do a dump of the control, I now see that its “Visible” value is always “no”. And indeed, it is not shown at all. I’ve added code to explicitly make the control visible, but it makes no difference.

So tomorrow I’m going to look into trying things like putting another (non-text) control in the toolbar and see if it’s another text-field-specific thing. I’ll just put a button in or something.

*sigh

I am listening to episode 29 of the Inside the Net podcast and the topic of the episode is “Calendar Swamp”, which is the name of a website run by Scott Mace.

Chandler is mentioned 4 minutes and 11 seconds in.

I seem to have all the code working correctly, but Chandler crashes on startup.

You can see the stack traces here in both C++ and Python. It’s weird, as if it’s failing when it tries to start up a Cocoa runtime environment. Very frustrating too, because it’s the last thing that stands in the way of the search bar on Mac OS. :-/

I “filled in” the code for embedding any arbitrary control in a toolbar on the Mac. It’s a little tricky, because I was unable to pass the toolbar item down through the code as user data or a refcon or what have you. So instead, I use a static fifo (a C++ queue) to make the pointer available at the lowest level.

It’s a little frustrating becuase it *looks* like you can pass arbitrary data all the way down, however the OS seems to parse the data because it crashes if I try to do it. It may be that I need to wrap the pointer in a CFDataRef or something. But for now the static fifo is doing the job just fine.

I’m still working on them. Thought you’d like to see what the data structure looks like.

wx toolbar UML diagram

I made it using OmniGraffle, and excellent app for doing all sorts of diagrams. It’s the Visio equivalent for the Mac.

What follows is a rant. Don’t take it very seriously. It is based on my admittedly incomplete understanding of how Chandler works. Still, I need to vent and maybe it will result in something useful.

It recently struck me that all the collections in the Chandler sidebar are what I would normally call “smart” collections. Especially the “My Items” collection.

My persistant feeling is that I prefer the UI of iCal where collections are “dumb”, and are enabled/”checked” by default, so that they are all always visible.

I think that any “smart collection” (e.g. “My Items”) should have a strikingly different UI, similar to how iTunes uses a different UI for “Smart Playlists”.

Chandler’s UI should be a mashup of iTunes and iCal. In this context, having a “Trash” collection is not useful. Undo obviates the need for it. So we should replace “Trash” with “Undo”. I think we *are* planning on actually implementing undo, but I’m not sure when. Actually, it may be the case that this is already the plan for Chandler. I’m not sure. (See “incomplete understanding” note above).

I am surprised that the functionality of collection unions and intersections are not implemented in the database layer, but rather in Python. Andi has done many tests showing that the database layer is not the bottleneck for Chandler anywhere. However, even so, I would prefer using an SQL database (defaulting to SQLite, but allowing other SQLs), simply because it would be easier to understand and maintain the database code.

Instead of requiring knowledge of the Berkeley DB API, knowledge of SQL — which is much more widespread — would allow developers to tinker I think we would be able to push more of Chandler’s functionality down into the database layer by using SQL’s higher-level semantics, giving less code for the same or better functionality.

Having an SQLite database would also allow us (and third parties) to view, understand and make use of the database much more easily.

Okay, Andi’s going to kill me now, so I’ll shut up.

Given /Applications/Chandler0.7.app:

cd /Applications/Chandler0.7.app/Contents/Resources/Library/Frameworks/Python.framework/Versions
sudo rm -rf Current
ln -s 2.4 Current

That’s it.

In all Mac frameworks, “Current” is a symlink to the actual directory.

I am hoping there are other space savers to find. My first attempt at using symlinks for multiple dylib’s with the same size failed.

Ah well.

Blender is an open source 3D modelling program based on Python. A new version was just released: version 2.4.2

Being a former Maya developer, I’m always curious about how 3D apps are progressing. Having a scripting language is very useful for 3D apps, and Blender’s got a good one in Python.

Woo hoo! An alpha 3 candidate is now available. I would say the major feature of this release is improved speed. Check it out, and be sure to give feedback by filing bugs.