WIP: Fixed screen root style bug

[tuj]

Link to ticket

https://leantime.itkdev.dk/#/tickets/showTicket/7203

Description

Fixed screen root style bug: Columns and rows have been switched.

Checklist

• My code is covered by test cases.
• My code passes our test (all our tests).
• My code passes our static analysis suite.
• My code passes our continuous integration process.

[tuj]

Analysis of #389

What the PR changes: Only one functional file — assets/client/components/screen.jsx. It removes a swap in the rootStyle object:

// Before (current code on this branch, screen.jsx:29-30)
gridTemplateColumns: gridTemplateRows,
gridTemplateRows: gridTemplateColumns,

// After
gridTemplateColumns,
gridTemplateRows,

That looks like an obvious bug fix. But in this codebase it isn't safe in isolation — it will visibly break the existing layouts in assets/shared/screen-layouts/.

Why the current "swap" is load-bearing

The two halves of the rendering pipeline are both swapped, so they cancel out:

1. The JSON layouts use a non-CSS convention. In two-boxes.json (rows: 2, columns: 1) the regions are named "Venstre / Højre" (left/right), and three-boxes-horizontal.json (rows: 3, columns: 1) is titled "3‑delt horisontalt" (3 boxes side by side). So in these JSON files, rows
   actually means the number of horizontal cells (CSS columns), and columns means the number of vertical cells (CSS rows).
2. createGrid(columns, rows) in assets/shared/grid-generator/grid-generator.js loops for i in columns { for j in rows } and emits one CSS-row line per columns iteration. So its first argument becomes CSS rows and its second argument becomes CSS columns — also swapped relative
   to its parameter names. screen.jsx:28 calls it as createGrid(configColumns, configRows).
3. The buggy assignment in screen.jsx swaps a third time, which restores alignment between the explicit track sizes and gridTemplateAreas.

Concrete effect of the PR on each shipped layout

Walking through with configColumns/configRows taken literally from the JSON:

│ Layout │ JSON rows/cols │ gridTemplateAreas produced │ Buggy tracks (today) │ Fixed tracks (PR) │
│ full-screen │ 1 / 1 │ 'a' (1×1) │ 1×1 ✅ │ 1×1 ✅ (no change) │
│ four-areas │ 2 / 2 │ 2×2 │ 2×2 ✅ │ 2×2 ✅ (no change) │
│ two-boxes │ 2 / 1 │ 'a b' (1 row × 2 cols) │ 2 cols × 1 row ✅ │ 1 col × 2 rows ❌ │
│ three-boxes-horizontal │ 3 / 1 │ 'a b c' (1×3) │ 3×1 ✅ │ 1×3 ❌ │
│ two-boxes-vertical / …-reversed │ 1 / 5 │ 5 rows × 1 col │ 1 col × 5 rows ✅ │ 5 cols × 1 row ❌ │
│ three-boxes │ 2 / 2 │ 2×2 │ 2×2 ✅ │ 2×2 ✅ │
│ six-areas / touch-template │ 4 / 44 │ 44 rows × 4 cols │ 4×44 ✅ │ 44×4 ❌ │

Any layout where rows ≠ columns will get explicit-track counts that don't match grid-template-areas. The browser then falls back to implicit tracks for the area letters and leaves empty explicit tracks for the rest — i.e. regions render at the wrong size or position, often
collapsed.

So, will the PR change how existing layouts render?

Yes. Symmetric layouts (full-screen, four-areas, three-boxes 2×2) will be unaffected, but every asymmetric layout in assets/shared/screen-layouts/ (the two-boxes, the horizontal three-boxes, the vertical splits, six-areas, touch-template) will misrender. The PR fixes one of
three "swaps" without touching the other two; to actually be correct it would need to either also fix createGrid's argument order (or rename its parameters), or migrate the JSON files to use CSS-conventional rows/columns.