Skip to content

Improve the Main Window Layout - #21

Open
EriaWalker wants to merge 2 commits into
HakuSystems:mainfrom
EriaWalker:codex/ui-window-layout
Open

Improve the Main Window Layout#21
EriaWalker wants to merge 2 commits into
HakuSystems:mainfrom
EriaWalker:codex/ui-window-layout

Conversation

@EriaWalker

Copy link
Copy Markdown
Contributor

Improve the Main Window Layout

Summary

This change makes the main window use a fixed 1207 by 918 size.
The user cannot resize the window.
The first start puts the window at the center of the screen.

The layout now stays horizontal at widths from 960 pixels.
The compact layout starts only below 960 pixels.
This prevents the main cards from becoming too tall at about 1000 pixels.

User Interface Changes

  • Reduce the top card padding from 28 to 20 pixels.
  • Reduce the logo from 128 by 128 to 110 by 110 pixels.
  • Reduce the main card padding from 34 to 24 pixels.
  • Reduce the drag and drop area padding and icon size.
  • Reduce spacing between the extraction header and the drop area.
  • Put the extraction header search area on a second row in compact layout.
  • Put queue action buttons on separate rows in compact layout.
  • Stretch the scroll content to the visible window width.

Window Size and Position

The XAML window now sets its width and height to 1207 and 918.
It also sets the same minimum and maximum values.
CanResize is false.

The window placement code now restores only a valid saved position.
It does not restore an old width, height, or maximized state.
The code sets the fixed size before the window opens.

Tests and Build

  • Add a headless test for wide, cozy, and compact layout classes.
  • Add the Styles directory as an Avalonia resource for the headless test host.
  • Run dotnet build in Release configuration.
  • Result: build completed with 0 errors and 0 warnings.

Output

image

Copilot AI lite review requested due to automatic review settings August 23, 2026 08:16

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4872e6ecc3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +19 to +21
MinHeight="918"
MaxHeight="918"
CanResize="False"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Let the main window fit the working area

On displays whose logical working height is below 918 pixels—such as a 1366×768 laptop or many 1080p displays using 125% scaling—the fixed minimum/maximum height combined with CanResize="False" makes part of the window extend beyond the desktop. Because the internal viewport still measures the oversized window rather than the visible portion, controls near the bottom can remain inaccessible; size the window relative to the working area or allow users to shrink it.

Useful? React with 👍 / 👎.

MinHeight="918"
MaxHeight="918"
CanResize="False"
WindowStartupLocation="CenterScreen"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Preserve restored positions after startup

For returning users with a saved window position, ApplyWindowPlacement assigns Position in the constructor before the window is shown, but CenterScreen applies the startup placement during the initial show and replaces that restored position. Use centered startup only when no saved position exists, and leave startup placement manual when restoring one.

Useful? React with 👍 / 👎.

@HakuSystems

Copy link
Copy Markdown
Owner

Thanks for this. The spacing and padding work is good and I want it, but I am not taking the fixed window size, and the PR needs a rebase either way.

Rebase first. #20 went in on main as 614a9b8, plus three follow-ups. EverythingSdkBootstrapper.cs lost about 380 lines and its test file changed with it, so this branch will conflict hard. Rebasing also drops the Everything64.dll commit out of this PR, which should shrink the diff to the UI change alone.

The part I want changed: CanResize="False" with MinWidth == MaxWidth == 1207 and MinHeight == MaxHeight == 918.

Two concrete problems:

  1. The responsive layout stops being reachable. ResponsiveWindowHelper classifies compact below 960, cozy from 960 to 1600, and wide at 1600 and up. A window locked at 1207 is cozy forever. Every Window.compact and Window.wide style in MainWindow.axaml, plus the isCompact branches this PR adds to MainWindow.Appearance.cs, become unreachable. The new ResponsiveWindowHelperTests still passes, because it drives a plain Window rather than MainWindow, but the transitions it asserts can no longer happen in the shipped app. That is a lot of new compact-layout code that nothing can execute.

  2. Small and scaled displays have no way out. Avalonia's Width and Height are logical units, so 918 becomes 1148 physical pixels at 125% display scaling and 1377 at 150%. On a 1080p laptop at 125%, which is the Windows default on a lot of machines, the window is taller than the work area and CanResize="False" means the user cannot fix it. I have not measured this on a scaled display, so treat it as a risk rather than a confirmed bug, but it is the exact configuration a good chunk of the crash reports come from (Windows 10 19045).

What I would take instead: keep everything else, and replace the six size properties and CanResize with just

MinWidth="960"
MinHeight="640"
Width="1207"
Height="918"
WindowStartupLocation="CenterScreen"

That gives you the intended default size and stops the layout from being squeezed into the shape you were fixing, without taking resizing away. If the goal was specifically that the cards stop growing too tall around 1000px, a MaxWidth on the content or a max height on the drop zone targets that directly.

Also dropping the saved size and maximized state in EnforceFixedWindowSize is a behaviour change beyond the layout fix. With a resizable window there is no reason to throw the user's placement away.

Happy to merge once the fixed size is gone and it is rebased on current main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants