The Chirp UI has been mature for many years and very little work goes into it now. That means you probably would not disrupt anybody with a UI overhaul. Moreover, I don't believe any of the active Chirp developers have much experience or interest in UI development, so if you want to "own" this that would be a great complement to the team.
Yeah, I hate having to work on the UI. I like the idea of using wx for it, if it gets us a more native look on all the platforms. Double good if we can make our OSX payload more integrated.
There is a lot of workflow in the UI that will either have to be replicated or generalized, which makes me think this is likely a pretty large project. I think the way I'd want to see it go is:
1. Put up another tree somewhere that you can push to for a while 2. Add the new UI in parallel to the old one and add some simple switch early in chirpw to select between them 3. Once a reasonable amount of functionality is there, we can see about merging it into the main tree, and make it optional somehow for regular users to try it. 4. Continue iterating until we can make the new one default, and then eventually remove the old one.
For #3, I will have to do some stuff to the windows build system I imagine. We also need to figure out what the OSX path looks like if we're going to bootstrap downloading and installing things during app run.
The setup.py process is super non-standard on all the platforms because of all the gorp I have to pull in to make the build work on windows. It would be great if this ends up with that being far simpler and more conventional.
--Dan