[chirp_devel] Updated UI? Port to WxPython?

[Aaron Traas]

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 at 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 at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20161229/c5730bdd/attachment-0001.html