Dan, I already have another tree here: 

https://bitbucket.org/adt6247/chirp-wxwidgets

No commits to it yet. I'm trying to get my build environment working. The upgrade to Sierra seemed to break pip for me, so I need to figure out what's going on there before I can do Python projects. 

My strategy was going to be what you suggested. I'll do a separate implementation of the `chirp.ui` package, and try to keep it as code compatible with the GTK. I'm probably going to start by renaming the ui package to `ui-gtk`, and have a parallel `ui-wx`. Once we decide to merge, we can rename it back to `ui`. 

I also noticed that setup.py doesn't use setuptools. I was thinking about refactoring that as well. But that can come after the UI. It would be nice to have this have a more standard layout, but there's no reason to do this all at once. I'm of the opinion that refactoring a project should be done in such a way that the commit history can really illustrate the migration. But that's probably me being a bit persnickity. 

I am able to follow the code fairly easily. Not a whole lot of comments, but it's well organized, and there's very little fluff. 

--
Aaron Traas | https://traas.org/ | @aarontraas


On Thu, Dec 29, 2016 at 10:56 AM, Dan Smith via chirp_devel <chirp_devel@intrepid.danplanet.com> wrote:
> 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
_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers