-- Where a player keeps their windows.
--
-- The author, 19 August: "what's blocking us from having a player dynamically move windows around
-- the screen (ie, wants inventory on left side instead of right) - and it saving that position?"
-- Three of the four answers were arithmetic and live in Rules/Ui/WindowLayout.cs. The fourth was
-- that there was nowhere to put it: the project had no UI settings of any kind, and not one call to
-- PlayerPrefs anywhere in it.
--
-- KEYED ON THE ACCOUNT, NOT THE CHARACTER, and that is the one real decision in this migration.
-- The action bar is per character because it IS gameplay -- a mage's bar and a warrior's bar are
-- different arrangements of different abilities, and copying one onto the other would be wrong.
-- Where the pack sits on the screen is not gameplay. It is a fact about the person at the desk, and
-- somebody who moves their inventory to the left means it for every character they will ever roll,
-- including the ones they have not made yet. Filing it under the account gets all of that for free,
-- follows them to another machine -- which a local settings file would not -- and is readable before
-- a character has been chosen at all.
--
-- ONE ROW PER MOVED WINDOW. A window that has never been dragged has no row, and gets whatever
-- position the scene was built with. That keeps the table proportional to what somebody has actually
-- done rather than to how many windows the game has, and it means adding a window in a later slice
-- does not need a backfill: it simply has no row, like every window nobody has touched.
--
-- THE POSITION IS A FRACTION OF THE CANVAS, stored as a REAL, not a pixel count. PixelPerfectCanvas
-- runs the interface at a whole-number zoom driven by screen height -- 1 on a 1080p screen, 3 on a
-- 4K one -- so the canvas's own coordinate extent changes with the monitor and again with the zoom
-- step. A stored pixel figure would restore a window off the edge of a smaller screen, which for a
-- window there is no other way to move is the same thing as losing it. See WindowLayout's header.
--
-- NO CHECK CONSTRAINT ON THE RANGE, deliberately. A legitimate fraction can be slightly negative:
-- the figure is the panel's BOTTOM-LEFT corner, and a panel taller than the canvas is pinned by its
-- top edge, which puts its bottom below zero by construction. The client clamps on restore, where
-- the panel's current size -- which the database cannot know -- is available to clamp against.

CREATE TABLE IF NOT EXISTS account_windows (
    account   TEXT NOT NULL REFERENCES accounts (name) ON DELETE CASCADE,
    -- A WindowNames constant: 'inventory', 'skillbook', and so on. A name this build no longer has
    -- is dropped on load rather than refusing the layout -- see WindowNames.Known.
    window    TEXT NOT NULL,
    -- Fractions of the canvas width and height, of the panel's bottom-left corner.
    x         REAL NOT NULL,
    y         REAL NOT NULL,

    PRIMARY KEY (account, window)
);
