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 http://twitter.com/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:
- Put up another tree somewhere that you can push to for a while
- Add the new UI in parallel to the old one and add some simple switch early in chirpw to select between them
- 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.
- 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