(re-adding the list since you dropped it)

Thanks Dan - Snark accepted, passion expected. 😊

\o/

I dug back through the archives for over a year and hadn't seen ay discussion around this, so while it may be a repeat, it's worth rehashing as technology trends change. Moving technology targets are a thing I have to deal with constantly, annd we often find that an idea that was discarded last year makes more sense this year as the technology evolves.

It's fine. It has come up and been discussed. People may just not be paying attention to to this thread as a result, is all.

While Python 3 may be a psychological thing (in my opinion) for attracting contributors, the ability to improve the UI is a user concern. Yes, you can use PyGObject with 2.7, you can also use it with 3.5. I'm not necessarily married to GTK as the sole framework for the UI when there are many other options out there. If you are, then I'd like to know, because if I start working on UI related work then I don't want to have it be throwaway.

Nope, I'm not married to GTK. I didn't know GTK before I started on chirp (and it probably shows), but it was the defacto framework for my platform, and worked elsewhere so it was an easy choice. Since then, I've spent plenty of time fighting with it (especially getting a native, non-X11, set of libraries compiled and working on MacOS, which I'm now afraid to touch). Thus, other frameworks that may be more cross-platform have certainly crossed my mind whilst waging said fights.

That's also why I thought it would be better to modernize the backend code before tackling the UI, because regardless of the future UI design, Python 2.7 is not going to be supported indefinitely, and if we do decide to go down a path that requires python 3.x (let's say 3.5 for now to avoide the XP quesiton, more on that below) then at least the rest of the code is ready. I realize there is less immediate gain in making that change, but that's my service engineering bias coming through - I like to focus on the fundamentals and worry about prettifying later.

The modernizing the backend benefits me regardless of the progress on the UI (so long as we don't modernize past 2.7 of course), so I'm happy for you to work on that. I just meant you may spend a lot of time working on that before you get to the point where you can work on the UI.

I also have gone down the path of working on UI first and been crestfallen when I realized that some assumptions I made about how things would work when I got the the functional code work required significant refactoring of the UI. The reverse is rarely true - if you write code that can be unit tested, it's rarely a major problem to get a UI framework to consume it, and in fact knowing what the functional code looks like can help inform UI decisions.

Thanks for including Jim and Rick. They are the other folks I was thinking specifically that I would like to hear from, but your opinion on who the key stakeholders are is more relevant than mine, which are based largely on reading the list for the past year or so.

"people show up all the time complaining about our process (or something else), having never submitted a patch" - Is that not indicative of a problem with the process 😊

No, because regardless of the process, someone will be comfortable with something else. In almost every community I've ever participated in, regardless of if it was patch-on-list, gerrit, github, launchpad, etc.. A certain slice of people show up and hate on the process. Purists who use text-based readers and refuse to use a web browser, and young kids who don't even have an email account.

Re gridview - that's one example, but its a big one. Maybe it's fixable in the current model, not sure. I seem to recall asking about this a couple of years ago and being told that it wasn't fixable because it was inherent in how GTK worked.

I think the "click to highlight, then click to adjust" behavior is somewhat inherent in the gridview, and I don't think GTK3 will change it, but I could be wrong. It feels very natural to me, so I'm not sure why it feels so unnatural to others, but I guess it's what you're used to.

Things like hitting tab which in most windows apps moves you to the next cell but in chirp moves you off of the grid vew,

This is just sloppy tab order handling in our code, AFAIK. GTK3 isn't going to do this for you by default and is fixable in the current stuff.

or how if I encounter an error (e.g. I type a frequency incorrectly) the entire grid reloads and I have to go find the memory I was working on again

This behavior is in chirp code and can be fixed. It's been a long time, but I think it's just because at the point when we detect that error, the easiest thing to do is to revert the value is reload the whole thing. It could be finer-grained, I've just never heard anyone complain about it.

(assuming that it didn't glitch out and completely blank the page which sometimes happens and I think is actually a GTK bug as I can't find anything in chirp which would cause it).

Yeah, I've never seen this, so maybe it's a GTK on windows thing I guess.

I'll look into fixing a few of my pet peeves that seem more manageable though (ctrl+c/ctrl+x in a cell does nothing, if I click on a frequency of an unused memory and do absolutely nothing then there's no need to throw an error, I *think* we can detect that nothing in that record was changed and decide it's still unused, but it would probably require moving the population of default options to a different point in the code).

The copy/paste in a cell is probably because I'm grabbing those keys at a higher level so I can copy a whole memory, perhaps preventing the inate plaintext behavior in the widget itself.

I won't submit via patchbomb though. I really don't like the idea of having a plaintext app password sitting on my hard drive. Yes, it's just an app password, but an app password is enough to start using my account as a spambot until google or Microsoft ban me if my PC gets compromised.

Heh, okay, that's what app passwords are for, but as you wish. You can email patches from your client if it bothers you.

As to the XP discussion, I am typing this and doing my chirp development on a PC that is now 11 years old. Windows 10 runs better on it than XP ever did. 7 and 8 were not great, but 10 is fantastic on old hardware.

I'm fine sticking with 3.5 for a time to keep XP support alive, but i'd like to at least do something to encourage people to upgrade (e.g. implement a new whizbang feature that only works on supported Windows versions). Especially if we continue asking people to store mail passwords in plaintext on an insecure, unsupported OS. 😊 I've yet to encounter something I can't get to work on Windows 10, I've gotten the full suite of MARS software running, used all manner of logging, sdr, antena deisgn, etc... software, and the only time I have had to make a special accomodation is when I was trying to run native dos apps, which I believe also requires workarounds on xp. I can't imagine that the people who have all kinds of special software setup on XP are the same people who are emailing you about how to download or how to submit a bug. I would suspect that the people who fall into those buckets are more likely to be users who just want to program their Baofeng to use GMRS frequencies.

Well, I doubt we're going to agree on this, but even if I /was/ interested in buying 10 for my spare machine that I use for random tasks, and even if I did find 10 anything less than maddening to use, it's the large XP userbase that is the important thing here. Assuming you're not going to be buying them memory and OS upgrades, we can just agree to disagree right? Punishing users that haven't upgraded just because we think they should change isn't something I'm into, just FYI.

I also just saw Jim's reply. Specifically to Jim's point, there are numerous guides that cover mapping mercurial workflows to git, however we could also move to git and allow you to continue using the mercurial client via a plugin for hg if you are more comfortable with that. I can personally help you with the move, if that's a path that we go down.

I will start submitting using hg, that's fine. I was suggesting GitHub for the modernizing process so that I can keep my hg repo setup for patching, and so that we can have multiple people working on the upgrade code without destabilizing the mainline code. When we have patches that are ready to go into the mainline code, then I will submit those patches via hg until and unless we move to git. This will also give me a good spot to start helping Jim and others who don't know git learn how to use git or use hg-git (or is it git hg, I lost track 😊).

I'll start doing some thinking and planning for a switch to git. I'm glad Jim is willing to try it, and I can keep a mercurial mirror of the tree for the foreseeable future if it helps the existing developers.

BTW - in git, attaching images to a patch should work just fine. By default, git will treat them as a binary file and just show that they are there without trying to diff them.

BTW - in mercurial, this works fine as well. Mercurial can even generate git-format patches with binary encoding. See 'hg export --git' when you start working on your patches :)

--Dan