I don't regret the time spent exploring XUL or LSR as both have taught me a lot and I have faith the knowledge will be useful. More importantly I have got to know many of the great developers who are working on the projects.
I've started off with SVG as I feel declarative description of the OSKs is important not least as it allows viral style cut-n-paste reuse. You may bemoan the lack of engineering discipline of such thoughtless usage, but such easy leveraging is part of what made the web take-off and evolve so rapidly. A large part of the Jambu vision is to encourage innovation and such rapid prototyping of ideas is going to be important. Using SVG rendering adds several interesting issues, mostly with performance due to the need to parse and render. Having declarative and scaling (as apposed to zooming pixel replication) gives easily modified and attractive UI. Perhaps Inkscape or other design tools can be used to create the UI.
We can always add Cairo/Pango support later, perhaps in a similar way to the Firefox canvas rather than embedded in the Python. However that is more a feature for programmers than users so I'll probably put that low down on the priorities unless we hit a show-stopper with SVG.
I'm reusing some basic LSR code, taking advantage of the fact it was moved to a BSD license just before IBM pulled the plug. The logging code based on the standard logging module will be invaluable. When working on Real-time mobile data we found that a debug channel with everything logged saved the day on may occasions. I doubt I'll log everything but it's basic debugging infrastructure. My next plan is to use the POR and Adapters to provide an abstraction of the platform a11y apis thus allowing easier portage to windows. They are perhaps rather overkill for my simple needs but should cover any future a11y requirments.
Once of the problems I found with using pyGTK and FOSS development in general is the difficulty in quickly getting a grip on best practice. Any amount of Googling and searching Koders etc. throws up many examples that are variations of a few themes with little explanation of the issues and best practices. You need to investigate several layers of docs and source, trying to connect the concepts and apply them to your usage. To some extent this is a natural effect of Open Source which encourages 'release early' and much copying of tutorial examples or choosing the easy option to get something working. Proprietary practices mean you have to (at least attempt to) create good docs. The advantage is that you gain a better understanding at the expense of time and that suits my style in general. It is however very frustrating at times. I should probably use the ever helpful FOSS communities more and get on the right IRC channels. The problem I currently have is that I'm signing off work in order to do the school run just as the developers in the States are waking up.
An example I hit is in painting (expose) patterns for X windows and how to render SVG; should you draw on demand in the expose event handler as you do in Windows paint handlers or draw to a server-side pixmap and copy on expose in order to reduce traffic in networked situations? And then there's the configure, size-allocation, realize and map signals to think about at some time soon (after a X refresher). Perhaps it doesn't matter as most users will have clients and servers on the same machine. Anyway I picked the simplest solution in true FOSS/Agile tradition and it's pretty slow on resize. I'll optimise later if at all (a good practice in itself). As Aaron says it's easy to think too hard.
Another issue I hit was purely personal. Although I have programmed in Python, I have many,many years of C and C++ so my instincts still lie there. I keep finding I using C idioms which don't fit python, especially at the end of the day when I'm tired and more on auto pilot. For example I wanted to create various constructors to create rectangles from different primitives (e.g. 4 ints or a GDK Rectangle) as you would in C. After a digression into Python theory I scrapped the idea and used a much simpler helper function which is a better approach from several angles. I gained a better understanding of Python and simpler (and faster) code at the expense of time taken to code. I'm slowly re-reflexing myself into the Pythonic way as I enjoy re-immersing myself in deep coding after so much web and SQL stuff.
Whilst working on Jambu I've also been looking at Sensory Software's Grid2 communication program and OSK, and boy am I impressed by its maturity and richness of features. It also shows what can be done with the much maligned VB and how to use the OS's native features, services and concepts to great benefit. It's also show how much experience with users requirements that the Sensory team have amassed and poured into the Grid. Lots of inspiration there.
Keywords: Jambu