Better portrait city-screen UI

[tuvus]

This PR aims to improve the portrait experience by improving the city-screen UI, but is more of an attempt than an actual solution.

The main problem with the city-screen is that there isn't enough space for the two panels and to actually see the tiles as well.
As a solution I created a tab system to only show one of them at a time. It might look nicer if these buttons were rectangular, the same size and took an entire width.
As you can see from the pictures it's still a little rough, especially with the tile selection in the bottom right. And that add to queue button might be a little off.

Also, I want to put the multiplayer status button in line with the AutoPlay status button instead of on a completely new row but I haven't been able to figure it out.

Any thoughts?

Pictures

[SomeTroglodyte]

Any thoughts

Thought sounded like "Been there tried that". There's a TabbedPager Widget - older work, and at times I wish I had done a lot of stuff differently, but it's used often. Getting the city into that proved a nightmare as many of the current components are placed on the stage, they do not support the Layout interface - even if it's implemented, they don't cooperate.

Another thing - ExpanderTab. The current one doesn't animate properly - only the arrow, not the 'content drawer'. Ages ago I fixed that after I finally learned how to do that properly - shot down because - the CityConstructions content doesn't cooperate properly with layout, which then looked like container failure -> ExpanderTab's fault. Dunno where the experiments went... OK, got a local branch on this box I never finished ¹.

The tabbed one should be on the other workspace.... Yup, found it ²
Of this second one there were screenshots in some issue, but can't find it atm. #10500 - but the visuals were video, and gh seems to have deleted it. Another edit: It's even pushed and thus accessible (NewCityScreen).

If you want to inspect any of these, ask. Their base is quite old, however. Meaning Gradle 7, which would cause some work and bloat just to run it. Or merge forward and suffer the incomprehensible diffs git produces when the going gets tough. Or use winmerge / meld which is easier to grok but more micromanagement.

Footnotes

1. Stopped work 2023-06-18, commit names:

   • Refactor CityConstructionsTable - code reorg and new layout logic - 2
   • Refactor CityConstructionsTable - code reorg and new layout logic
   • ExpanderTab - predictHeaderPrefWidth for CityConstructionTable
   • Fix ExpanderTab content not aligned and not sized to width
   • ExpanderTab redone
   ↩

2. Stopped 2023-11-27, all commits just numbered "TabbedCityScreen interim 00#" ↩

[SomeTroglodyte]

Actually, I did merge the TabbedCityScreen forward (to 4.11.14): NewCityScreenMerge - y'all know how to debug-run another dev's branches? Just add my fork as remote and checkout. Lotsa layout problems, but also a hidden gem in there... From the other discussion: Shift key switches from old to new. Mind I might have not seen a merge error, so regressions are still possible.

[tuvus]

Wow, you seem to actually clean up your remote branches. Maybe I should do that too.

[tuvus]

For reference, here are some pictures I took of SomeTroglodytes branch:

Pictures

This UI seem a bit better than the one I proposed. Here are a few notes:

• I think the construction menu should be just one column with current queue on top, then we have more space for each button and just the little info panel on the side.
• The buildings tab looks a little empty, but that isn't nessesarily a bad thing.
• The stats table could look a little better but it works.

[SomeTroglodyte]

you seem to actually clean up your remote branches

Everyone should - but I don't 100%. Some are meant as backups I don't want to keep local, some as transport vehicle from one workplace to the next - means without PR nobody reminds me to delete. My workflow is probably documented in my Scratchpad repo - involves making sure I don't accidentally delete a wrong local by deleting the remote from github from the "PR merged" mail first, then fetching from the branches tool in Studio - you can see the backing reference disappear, that's the right line. Was better before Iguana - since with the introduction of the "recent" thing it often jumps around madly.

Cleaned branches also mean other devs will have an easier time checking out my branches!

Here are a few notes

Remember - I did the bare minimum to force the existing UI elements into that framework. Nothing is really finished. (Ugh - No idea where that white background comes from, why the assigned one doesn't fill its space. Yes idea: violating the Layout contract will lead to these things...)

Also, I operated under the self-imposed constraint to keep the "old" CityScreen operational and unchanged, while not cloning everything but getting both into some structure and reuse as much code as possible. Idea: Doing so would illuminate which elements are well-behaved which not, and how the 'frontier' is structured best would illuminate how the thing can be modularized for easier maintenance.

The only place that got more investment than necessary was the "you got n unassigned population left to distribute" thing on the map (cuz in master you see the number on the right but in that branch that's a different tab) - that got more energy because it was more fun. But the layout quirks were no fun at all.

[yairm210]

You're both better UI-ers than I am, so if you both agree on a direction I'll go with it
Not sure if you want me to merge this 🤔

[SomeTroglodyte]

Up to @tuvus. I feel my old branch wasn't production-ready, but this isn't either. Umm... current state of the CityScreen isn't either... So, ...

• either Oscar goes small steps, takes this and takes into consideration my ideas and what he likes from my branch ¹, then endorses or updates this PR.
• or Oscar goes big, takes my branch, rebases it so git forgets the association with my branch, and sees if he can get it to run with less hitches, then PR's as new and takes credit, no attribution required. I'm ears for questions - if need be on the discussion pages of my fork.
• or cop out and postpone, leaving time to ruminate

I'll just be so bold and convert this to draft with my super powers in the meantime.

Footnotes

1. (please also another: I once made the map shift under cramped conditions so chance is higher the center is actually visible and not covered up by the big fat block on the left - that's dubious right now and likely obsolete with your tweaks. Look for it, has a comment...) ↩

[tuvus]

either Oscar goes small steps
or Oscar goes big, takes my branch

Woah, I'm busy working on the AI. Your the one who can actually design good UI. I just hack things together until the result is slightly better than the original to get your attention. Then you swoop in and make it look good.

I'll probably choose option 3 until I build up my courage to go fight the layouts again... Unless you have some spare time and motivation?

[SomeTroglodyte]

motivation

Exactly.

hack

Exactly! Felt like that for me too. But that need not be bad - I would not be surprised if option 1 with negligible work makes things better without drawbacks, but I haven't pulled your branch and playtested it, so it's your brain can answer that question - after my tickling sinks in.

[tuvus]

@SomeTroglodyte Could you merge master of your branch and deal with the merge conflicts? You made a big change that makes it hard to resolve without context.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR was closed because it has been stalled for 10 days with no activity.