Switch back on stable old-ui branch about tbe HOT 30 CLOSED

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.

from tbe.

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

Done.

from tbe.

@kaa-ching what are your plans?

from tbe.

Could issue #331 be related to this one?

from tbe.

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.

from tbe.

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.

from tbe.

@DjSlash, will you give me commits rights?

from tbe.

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 ;-)

from tbe.

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.

from tbe.

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

from tbe.

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

from tbe.

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.

from tbe.

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.

from tbe.

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

from tbe.

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

from tbe.

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.

from tbe.

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?

from tbe.

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.

from tbe.

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.

from tbe.

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.

from tbe.

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:

• old UI -> master
• current master -> new-ui-devel
• old UI development -> devel, which will be merged to master when it is tested on Windows, Linux and macOS.

I can test Linux and macOS.

Which versions can you test @glixx and @Wuzzy2?

from tbe.

old-ui branch works. master doesn't.

from tbe.

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.

from tbe.

Let's switch.

from tbe.

Pull requests need to be created to make this happen.

from tbe.

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:

• some texts are unreadable, e.g. white text on a yellow postit note
• the explanation texts when you start a level are not readable, maybe also white text on a white background?

Is this also the case on Linux and Windows?

from tbe.

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?

from tbe.

Qt 5.14.0 on macOS Catalina 10.15.2

from tbe.

Qt 5.9.9

from tbe.

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

from tbe.