Chomping at Chandler

I think..

I just realized today that not everything has to be a block. Attribute editors are really just (relatively) lightweight wx widgets. So the email address field/overflow indicator thingee that has been causing me so many problems doesn’t have to be two separate blocks that talk to each other. I can put both wx widgets inside a sizer and hand that off as the “control” for the editor. i.e. the CreateControl() method can return the sizer.

Now, when that sizer is handed back in later methods, I will need to get the two child controls out of the sizer. Hopefully that won’t be too hard.

I’ve been spending a lot of time in there.

(make your browser window wide enough to see the 778-pixel-wide picture below…)

AttributeEditors.py class hierarchy Can you tell?

I was in a meeting about stamping where we discussed certain items in the detail view (notably the “from” and “to” fields and what is legal to put in there. I kind of threw a wrench into things when I mentioned people using email addresses without “@” in them inside large companies. Reading page 7 of RFC 2822 makes it clear that an “@” sign is required for legal email addresses. So I think it’s okay to say that email addresses need to be formatted like user@bar.foo.

One thing that caught my eye is the “sent by”/”updated by” field, which is a read-only field. My first thought was that this should be a (perhaps subtle) popup that allows the user to access the history of the item. e.g. a popup might say:

sent by rae@tnir.org Mon Sep 11 2006, 11:56
updated by luisa@luisa.org Tue Sep 12 2006, 13:45
updated by rae@tnir.org Tue Sep 12 2006, 14:23

and selecting any of the past versions would change all the fields to show the old version. This allows the user to revert to an old version easily. It’s kind of Wiki-ish. And since the history is linear like this, someone else can re-revert back to the previous version, and we can have our own Chandler-wars a là Wikipedia-wars.

Hah!

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.

Hmm, amongst a new version of Xcode, a new technote on building universal open source projects, and the PyApplicationStub Framework, I forsee interesting times ahead..

[not to mention an alternative malloc we can check out]