Chomping at Chandler

Got this from editing a bit of application/Utility.py:

——parcelPath=s	Parcel search path ($PARCELPATH)
——webserver	Activate the built-in webserver ($CHANDLERWEBSERVER)
——profileDir=s	location of the Chandler Repository ($PROFILEDIR)
——prof	save profiling data
——testScripts	run all test scripts
——scriptFile=s	script file to execute after startup
——scriptTimeout=s	script file timeout (default: 0)
——catsProfile=s	file for hotshot profile of script execution
——catsPerfLog=s	file to output a performance number
——stderr	Echo error output to log file
——create	Force creation of a new repository ($CREATE)
——askCreate	Offer to create a new repository
——ramdb
——restore=s	repository backup to restore from before repository open
——recover	open repository with recovery
——nocatch	($CHANDLERNOCATCH)
——wing
——komodo
——refresh-ui	Refresh the UI from the repository during startup
——locale=s	Set the default locale
——encrypt	Request prompt for password for repository encryption
——nosplash	($CHANDLERNOSPLASH)
——logging=s	The logging config file ($CHANDLERLOGCONFIG, default: logging.conf)
——createData=s	csv file with items definition to load after startup
——verbose	Verbosity option (currently just for run_tests.py)
——quiet	Quiet option (currently just for run_tests.py)
——verify-assignments	Verify attribute assignments against schema
——debugOn=s	Enter PDB upon this exception being raised
——app-parcel=s	Parcel that defines the core application (default: osaf.app)
——nonexclusive	Enable non-exclusive repository access ($CHANDLERNONEXCLUSIVEREPO)

When writing cross-platform software in the past, the best architecture has usually been to write the core code in something like C, Obj C or C++ and have the UI be scripted.

This is how Maya is architected.

The other core architecture meme is to have common core code that is platform-agnostic, and then have separate UI’s for each platform.

Bringing this thinking to Chandler, I wonder how it would be to use two (or more) separate UIs on top of common code? On Mac we could use PyObjC, and on Linux we could use PyGtk, while wx would remain for Windows. I’ve done a bit of googling and there are a couple of other GUI toolkits for Python as well:
   PyGUI
   Venster

I dunno, wx seems awfully integrated into Chandler.

Just a thought..

If you are a Mac and you are feeling adventurous, you can download Chandler_osx_0.7alpha2.dev-r10378-rae.dmg [56.2 MB], which is a build I did with my changes. I haven’t checked it in because I want to check for sure to see if it has had a negative impact on Chandler’s speed. It feels like it has.

Also, it doesn’t quite work correctly. :-/

Feel free to download it and try it out. Let me know what your experiences with it are like. Well, aside from the crashes I described in my last posting, of course.

I published the dmg file on my DreamHost account, so downloads should be quite zippy. Feel free to leave comments about the speed, as I’m curious bout how zippy it is in fact.

I now have the new markup bar buttons up and rendering correctly, complete with rollover. However, when I click on any of the buttons, the app crashes. It looks like the wxPython class wx.lib.buttons.GenBitmapButton cannot handle “self”’s C++ class being deleted in the middle of OnLeftUp().

Here are some pictures (you can also just view the Flickr set):

My very first successful rendering of buttons.

Up until this point I was having a lot of problems with Python’s handling of __init() methods and their parameters. Specifically, keyword parameters vs positional ones vs default-value parameters (are they keywords? Are they positional? I think the answer to both questions is “yes”!).

As you can see, the buttons are way too big. But still, I wanted to try a rollover to see if it worked…

Rollover works!

.. and it id! Nice.

I fixed the size problem and also the read-only icon to be the right bitmap, and got this:

Now that looks more like it!

Note the button background is all white. That might be a symptom of using ContainerBlocks.BoxContainer as the parent block for the buttons.

I had to try rolling over the buttons (I already knew clicking would cause a crash), so here are the other buttons rolled over one-by-one..

rolling over contact

rolling over task

rolling over event

rolling over private

So what happens when you click? First all the buttons disappear, which I assume is a normal part of switching how things look:

What happens when you click Then the app crashes with this stack trace:

Traceback (most recent call last):
  File “/Users/rae/work/osaf/chandler/chandler/release/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx/lib/buttons.py”, line 315, in OnLeftUp
      self.Refresh()
File “/Users/rae/work/osaf/chandler/chandler/release/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx/_core.py”, line 12815, in __getattr__
      raise PyDeadObjectError(self.attrStr % self._name)
wx._core.PyDeadObjectError: The C++ part of the wxChandlerMultiStateButton object has been deleted, attribute access no longer allowed.
release/RunChandler: line 13: 1838 Bus error $CHANDLERBIN/release/RunPython -O $CHANDLERHOME/Chandler.py “$@”

The code in buttons.py”, line 315 looks like this:

   def OnLeftUp(self, event):
       if not self.IsEnabled() or not self.HasCapture():
           return
       if self.HasCapture():
           self.ReleaseMouse()
           # if the button was down when the mouse was released…
           if not self.up:
               self.Notify()
           self.up = True
           self.Refresh()
           event.Skip()

the crash happens in the second-last line. The C++ button is gone, so it cannot refresh.

So.. on with the show!

I was working on Yet Another Wx Build a few days ago and did an “svn diff” to make sure I was on top of all my changes. What should appear but some files I knew nothing about!

Fortunately, the top of the files contained comments saying they were autom atically generated by SWIG and that I shouldn’t edit them.

Well, that **really** confused me, since I thought there was no way that generated files would ever be checked into svn, would they?

Turns out, I should have spoken up earlier (maybe). Bear checked in revision 10315 with a comment that says in part:

Modifications to internal/wx/Makefile to enhance how the clean target removes generated and build related files.

Ah hah!

Ran across Mark Shuttleworth’s home page today via a link on the Ubuntu site. Found a number of interesting open source projects. One was BluePrint, which is a part of LaunchPad.

A blurb about LaunchPad:

Launchpad is a collection of services for projects in the open source universe. You can register your project, and then collaborate with the open source community on translations, bug tracking and code.

and here is a blurb about BluePrint:

Blueprint is the part of Launchpad that is concerned with tracking the development of new features in your software. It’s where you can map out your roadmap, and prioritise the cool things you want to put into your next set of releases. It lets you build a community view of what’s important, but it also lets individual contributors publish their own ideas and plans.

I dunno. I think maybe we could use something like this. I’ll look into it a bit more.

While scouting around some more I ran across a list of bounties for various LaunchPad-related projects, one of which was a UI for relationships in the database program Glom It’s actually at $400 since two more people pitched in $50 (maybe).

All the work is Linux-based, too. Interesting.

Another interesting find was SchoolTool Calendar. The SchoolTool project is designed to build open source school administration software, and SchoolTool Calendar is a part of that effort. Another potential cross-fertilization opportunity? There are so many..