the-butterfly-effect / tbe

The Butterfly Effect, a realistic physics simulation game
http://the-butterfly-effect.org
GNU General Public License v2.0
96 stars 13 forks source link

Switch back on stable old-ui branch #340

Closed glixx closed 4 years ago

glixx commented 5 years ago

Current master is fully bad and unstable, no developing many years. Suggestion: switch back on stable old-ui branch and continue developing only this branch.

glixx commented 5 years ago

@kaa-ching what are your plans?

angus73 commented 5 years ago

Could issue #331 be related to this one?

glixx commented 5 years ago

Old ui branch has different translations with master. I'm thinking to support translations of old ui branch by transifex too. I'm waiting for @kaa-ching answer about his plans first. If no answer then needs to think about fork, developing here was died. Noone has commit rights to commit even translations, patches in old ui branch and @kaa-ching is not active.

DjSlash commented 5 years ago

There are a few people who can commit too, tho. I can create extra permissions if needed.

I've pinged kaa-ching on Signal, so I'll wait a bit to see what his response is.

glixx commented 5 years ago

@DjSlash, will you give me commits rights?

kaa-ching commented 5 years ago

Hi, I'm back from a few weeks of traveling. Sigh. too much to do and too little time. I think there's a lot wrong with the new UI, including that there's no collision detection, so users can place any object anywhere. Switching back to the old UI is also not a sustainable option anymore - Qt has changed a lot. I'm afraid that most of the code has been rotting for a while. Right now, I cannot free enough time to devote to the project. This may change in the July time frame.

I'm not really happy if you'd switch branches, but I will take patches ;-)

amarsman commented 4 years ago

I see 95 open issues, are they all still valid for current master?

I won't work on the old ui but have nothing against having two branches active for the near future if we make sure that all levels will work with both. In the end the old version will die I think.

Is the old version still more stable? We will need to flag in the 95 issues if they are valid for which branch and we need to have the priorities right. We have a limited number of resources and it would be nice to spend them where it makes most sense.

I will create a pull request within a couple of weeks to make sure that the macOS version will also build with Homebrew which is what I'm using for a long time already but doesn't build out of the box.

glixx commented 4 years ago

Current master is fully not workable. Old branch is stable.

amarsman commented 4 years ago

How about all the fixes for levels that were done on current master, will they work with the old branch?

glixx commented 4 years ago

I do not see future if to develop nothing. Better to develop old branch, than absolutely nothing. Fixes should work. Nice idea to backport them.

amarsman commented 4 years ago

I created my first pull requested yesterday and intend to create more.

We can use two branches for now: old (old-ui?) & new gui (master).

I would welcome other pull requests for either branch.

If we can keep them compatible w.r.t. levels then improvement of levels will benefit both.

amarsman commented 4 years ago

The master and old-ui branch can now build again on macOS.

angus73 commented 4 years ago

(How) will this change affect the problem I reported (issue #331)?

Wuzzy2 commented 4 years ago

Here's a suggestion: Turn the old (but functional) code to master, and move the current broken master branch to some branch like “new_ui_rework” or whatever. That way, master will become fully functional again and will no longer (in theory) block releases while still keeping the new UI code. New UI code can be merged back into master as soon it's ready.

IMO, it was a big mistake to start the major UI rework directly on the master branch as it was too risky. Instead, it should have been on a separate branch from the start and only merged back to master as soon it was stable.

amarsman commented 4 years ago

Did you try if the branch with the old code still works?

Are you willing to merge the improved levels from current master back to the old code?

I would like to see that both old and new UI use the same levels but I don't know if that's feasible. If that's possible we need to move them to a sub repository that is used by both branches. That way fixes on levels done by either branch also work for the other branch. @kaa-ching: could that work or are the engines incompatible?

Any opinions?

Wuzzy2 commented 4 years ago

No, I did not test it. Wait, both branches differ in levels? Uh-oh. That's annoying. Moving them to a intermediate repo sounds like a nice workaround, however.

I will not push any code, sorry. I'm just thinking aloud.

amarsman commented 4 years ago

Before we could do what you would like we need to make sure the new situation is better than what is currently on master. So we need somebody who has tested the old ui branch and say: yes, this is far better from an end user point of view than what is currently on master.

I think the reason why @kaa-ching put the new UI on master is to have it tested by a wider audience but I could be wrong

As development work was done on the new ui branch fixes in levels are done in that branch, those are not in the old ui branch.

You don't want to push because you don't know how to use git well enough? No need to adapt the source code, only to merge the level improvements to the old ui branch.

glixx commented 4 years ago

Old ui branch is ok. New ui master cannot be tested, it is fully not workable. Let's develop old ui branch and merge levels from master there.

amarsman commented 4 years ago

That sounds like a good plan, we at least have 2 people who would like to bring the old UI forward which keeps the project alive. I can also contribute but not at a predictable pace. Let's wait for the verdict of @kaa-ching.

My proposal:

I can test Linux and macOS.

Which versions can you test @glixx and @Wuzzy2?

Wuzzy2 commented 4 years ago

old-ui branch works. master doesn't.

angus73 commented 4 years ago

I am also interested in helping to keep the project alive, by doing some test if anyone give me some detailed intructions because I am not a developer.

glixx commented 4 years ago

Let's switch.

amarsman commented 4 years ago

Pull requests need to be created to make this happen.

amarsman commented 4 years ago

I just did a checkout of old-ui on macOS and build with Qt 5.14.

I got warnings during the build and have some usability issues:

Is this also the case on Linux and Windows?

amarsman commented 4 years ago

I just did a checkout of old-ui on macOS and build with Qt 5.9.9.

There the colours are different so no issue. This needs investigation, a different Qt version gives a different UI.

Is this also the case on Linux and Windows?

amarsman commented 4 years ago

F2A69EFE-4100-43F2-8494-36A6021A2E0F

Qt 5.14.0 on macOS Catalina 10.15.2

amarsman commented 4 years ago

CD4258EC-4F22-4CEC-8269-F8F4C0F724F7

Qt 5.9.9

amarsman commented 4 years ago

I'm using dark mode on macOS, that could explain it maybe?

kaa-ching commented 4 years ago

I'm not going to have a lot of free time any time soon. So, by popular request I'm going to revert to the old UI. Secondly, I'm going to add at least one other person to manage the repo.

kaa-ching commented 4 years ago

I renamed master to be new-ui I renamed old-ui to be master I made the new master the default repo.

Done.