Dev-Picayune

It appears that wxPython’s wxTreeListCtrl is not quite 100% correct. I am still new at the wxPython and wxWindows deal but apparently the wxTreeListCtrl does not fully implement either the wxListCtrl or the wxTreeCtrl. The first problem is that there is no way to edit a field inline (natively) other than the first column. That’s a problem because I only want the user to edit the second column. The other problem is that even if I was going to allow a double-click or right-click of a modal edit window, the wxTreeListCtrl seems to be trapping all of those events and not allowing them to flow through to the handlers that I activated. Not good. Therefore, I have retreated to a regular standard wxTreeCtrl and I will have an edit field at the bottom of the screen to change the value. I have already managed to get the system to store the actual DOMNode context with each element in the tree in the “data” property of each node. Because the context really just operates on a referenced version of the DOM as a whole, changing the data element of a node ultimately is changing the full DOM right then. Very simple. So, all I have left is to regenerate the DOM as XML (a single method call) and then I can write the string out to a file. Obviously, I still have some UI issues to deal with but my purpose for doing the configuration this way was primarily for the additional exposure to XML rather than languishing in a sea of UI issues which is pretty much what I have been doing lately. I really want to wrap up this project fairly quickly because I would like to start on my blogging application rather quickly. Plus, I have got to get back to my Nevada project.

Burried in what appears to be a valid official Sun Memo is a brief mention of a comparison between several languages including an emphasis on Python versus Java. Once it again it reaffirms that Python kicks butt. I don’t know what the minimum requirements currently are for a Swing Library based GUI Hello World program in Java but I would bet it is more than for either a Tkinter or wxPython based version in Python.

Ah the power of XML Path Language (XPath)! Thanks once again to Brandon for his advice to look into the xpath stuff. As it turns out, it is going to be perfect for my configuration tree. At first, I saw it as just a slightly quicker way to narrow down the big DOM to something specific I was looking for, but as it turns out, I believe I’ll be able to use xpath and some wrappers to manage almost all of my config stuff. The attached screen shot shows the configuration tree that has been dynamically created from my cfcard.config (xml) file.

Obviously, I still have editing within the tree list to handle and then the subsequent writing out of the data back to the config file. That should be interesting… but at least I have something to show for my work.

So far with my compact flash copy program, CFCopy, I have managed to get a ton of things working. I have changed the main list box to use a wxListCtrl instead so that I can show the file name, date, archive bit status, and the camera model. I am pulling the camera model from the exif data imbedded in a jpeg file. I still need to implement .crw (canon raw file) reading at some point but for now I am planning on setting up two option groups. One group is the destination directory based on the exif read camera model. The other option will be a “default” destination for certain file extensions. So I could specify the .crw and .thm files generated by the canon rebel to be put into the same root folder structure as the jpeg files that were generated by that camera. This will be fine for me until I have two different canon model cameras that can produce the raw files.

My current problem is the design of the configuration system for the program. At first, I was just going to do a standard .INI file setup with a couple of groups of options and put them on the config tab of the program. Instead, I decided it would be more fun and “flexible” to make the options a little more dynamic. My current plan is to save and restore the options via XML. The initial plan is to read and display the options in a wxTreeListCtrl… and then I eventually need to make the tree editable…. and then be able to save the options back out to the file. I think the biggest trick I am dealing with right now is how to make accessing the options easy. My current plan for accessing the options is something involving python dictionaries. Essentially, when the system is looking at a file, it needs to decide which root destination it should go in. That means that if it needs to find the destination root for a Canon Rebel Digital model camera it needs to be able to know whether a destination root option exists in Config–>Destination Options–>Camera Specific Destinations–>Canon Rebel Digital. My concern is how to make looking for that data easy or at least straight forward. To some degree it comes down to how much hard coding I want to do… how many temporary or permanent variables I want to setup… whether to write wrapper functions or access the data directly. I’m sure I will choose poorly, but at some point I need to choose in order to get it done.