Chomping at Chandler

I am probing the class hierarchies of Chandler, and I gave doxygen a shot.

You can see the results in Doxygen/html. It’s not quite optimized for Python, obviously. It also doesn’t seem to get all the class inheritances.

I tried to include wxPython, but it died with an error:

input buffer overflow, can't enlarge buffer because scanner uses REJECT

I figure I have to massage the Doxyfile config file a bit to get it to handle wxPython.

Almost there…

downloads.osafoundation.org/chandler/milestones/0.7alpha2 will be the destination URL for the new release of Chandler.

Woo hoo!

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]

CPIA (Chandler Presentation and Interaction Architecture) is the means by which Chandler renders the user interface to the screen. In my view, its central class, Block, acts as a “controller” in the model-view-controller paradigm. The “model” is the database of items and collections of items where information such as calendar events are stored. The “view” would be the UI widgets that are manipulated by Blocks or, in turn, which manipulate the Blocks. It is the Blocks that manipulate the model; widgets never directly do this, if I understand correctly. I think it would make things clearer in the Chandler code if everything that derives from Block had a name ending in Block, and all items that are widgets had names ending in “Widget” or something. For instance, the MarkupBar code involves the following classes:

MailMessageButtonBlock
CalendarStampBlock
DetailStampButton
Button
wxChandlerMultiStateButton

Now the first two are blocks, but so are #3 and #4. #5 is a pure UI class. Better names for these might be:

MailStampBlock
CalendarStampBlock (already has a good name!)
DetailStampBlock
ButtonBlock
wxMultiStateButtonWidget

In this way, you can surmise more accurately when control is transferring between these very different class hierarchies.

 

I had a talk with John about an hour ago that hilighted the need to refactor the Markup Bar’s code, as it apparently uses some “old ways of doing things”. But for now, just to get the functional tests back on track, I’ll just be doing small tweaks.

When I committed my new Markup Bar code yesterday, I had to disable any functional tests that interacted with the Markup Bar, since the whole way it works is different now. What follows is something of a rambling that is intended to help me keep things straight about who inherits from whom, and why.

Before, The Markup Bar used wx.Toolbar and its attendant wx.ToolbarItems, but now it’s a simple ControlBlocks.ContentItemDetail, which is a ContainerBlocks.BoxContainer, which is a Block.RectangularChild.

On the wx side, ContainerBlocks.BoxContainer uses a ContainerBlocks.wxBoxContainer, which is a Block.wxRectangularChild with extra logic for handling foreground colours and layout. Hm, maybe one of my problems with the buttons is that they don’t inherit from this class? Food for thought..

Now Block.wxRectangularChild is just a wx.Panel, so it doesn’t have all the methods that wx.Toolbar does for pressing buttons and such. I have to somehow search through the child blocks of the Markup Bar and find them by name. Then I have to send them events that make them think they are being pressed.

I played around in PyCrust inside Chandler last night for a while, trying to manually do this with App_ns.markupbar, but it seems to be a BlockProxy and has no children through whom I could search at all. I suspect this is the nature of its “proxy”ness, so I will have to talk to John about how exactly BlockProxy’s work.

I think once I have a handle on the children of the Markup Bar i will be able to send them the required event to press themselves, and the functional tests willbe restored to their full good health.

One thing I am wondering about though, is how the performance tests are faring? I think they manipulate the Markup Bar as well, but I didn’t see any red in the tinderbox last night. Perhaps they are not run automatically? I should ask Bear, but maybe he will just answer here in a comment.