uwestoehr wrote: ↑Sun Sep 18, 2022 10:57 pm
Sorry, I cannot follow you. How can you judge the UI "crap" (I don't like words like this, given the countless hours many volunteers spent) without knowing what it is for?
With respect, it was clearly written as an opinion felt at the time. It turns out many, many, others have faced a similar first experience with UI/UX. In fact I think it is probably the #1 criticism of FC.
uwestoehr wrote: ↑Sun Sep 18, 2022 10:57 pmAnd how can you judge at all how good/bad code it by saying you don't know what it is for.
As an experienced programmer, you surely know better.
It does not actually improve tghe readability
Really? You must have some massochism:
Code: Select all
std::map<std::string, std::string>::const_iterator ht = config.find("HiddenDockWindow");
is more readable than
Code: Select all
auto ht = config.find("HiddenDockWindow");
and the old code seems uses as few spaces as possible, add all the other issues ... and multiply this by thousands, it's way, way, more mentally taxing to read than necessary.
I am currently responsible for the backports and fear merge conflicts
Fair enough. But rather than block master for a year or two, what can be done to make this more efficient? Is it all down to you? Do you need help? Can the process be changed? Are these backports really so critical or important that they block development in master? Is it a wise use of your precious resources? Is it wise to try to please all the people all the time?
don't forget our goal for the next major release - toponaming
I understand that after three years in the wilderness, this code is to be merged. And that it comes with a whole bunch of other changes/improvements that make realthunder's fork so popular. I understand that he solved the one major problem that no-one here could (or would), but for whatever reason it was not accepted. I suspect some politics but have no idea. Now its going to be merged. Once again though, do you hold back master for an unknown time frame while this happens? I'm sure you guys thought this through when the decision was made. It has been on the back of my mind that loads of changes might be an issue, but hey, there's been a bunch of multi-line and multi-file modernization commits other than mine without drama. How will this merge be done. Is it staged to minimise the complexity? Do you need help? Can I help? Not that I've done a lot of merging.
I agree with all of that
Thank you. Is that to say you disagree with the other six points?
Code: Select all
I was only wondering why we need to invest manpower to change existing definitions
Its mainly my time. I don't mind spending hours and hours on this. My previous 30 or so commits went smoothly, with only a couple of minor hiccups. On this occasion the review process went awry. Nothing of consquence was found wrong with the code.
Going back to the beginning ..
I am not opposed, but want to have a discussion if we want to go this way.
Cool, so can we find a way to get on with it?