Maul Window 0.13.0

Built on Maul Unicode 0.3.0, so that the family's latest releases share
one Unicode; the API is unchanged.

Changed

• Builds on Maul Unicode 0.3.0, found installed or fetched, whose encoding converters take their mode before the output.

Maul Window 0.12.0

A clipboard read's payload tied to its read, from an API audit after
0.11.0, keep rules for Android applications that shrink their code, and
touch exploration of a root that only has Explorer's method.

Added

• Android: java/proguard-rules.pro, what an application that shrinks its code with R8 or ProGuard must keep: the library's Java classes and members, which the native library finds by name, and a root's public virtualViewAt, found by reflection. The test applications are now built with R8 and these rules (mwin-0041).

Changed

• mwinGetClipboardText, mwinGetClipboardData and mwinGetPrimaryText take the read's request after the context, from its completion record, and answer mwin_errorStale for any request but a read answered done whose payload no later read replaced; before, a read could be answered with another window's read, or a superseded read's late bytes. Pass event.data.completion.request (mwin-0040).
• mwinRequestClipboardWriteData takes its item count as uint32_t, as the other requests with arrays do.

Fixed

• Android: touch exploration finds the node under the finger in a root that has a public int virtualViewAt(float x, float y) but does not implement maul.window.Explorer, as a provider of another library (Maul UI's) cannot; the library took such a root's hovers and announced nothing.

Maul Window 0.11.0

Touch screens on X11 and power facts on the web, the two gaps an audit
against the requirements found after 0.10.1.

Added

• Web: whether the device runs on its battery, from the Battery Status API where the browser has it (Chromium), with mwin_eventPowerChanged when it starts or stops charging; unknown elsewhere.
• X11: touch screens make touch records, through XInput 2.2 where the server has it, with an id per finger and pressure where the screen measures it; the server no longer turns the first finger into the mouse for the program's windows (mwin-0039).

Maul Window 0.10.1

Two fixes found by the Win32 and Android mutation sweeps.

Fixed

• Android: an activity started while the one before it was still finishing no longer loses the program. Android makes the new activity before the old one ends; the old one's stop and end then let go of the new one's parts, and the program ran no more frames. The old activity now ends as the new one joins, its window asked to close as before.

• Win32: a window made always on top is topmost from its creation. Windows did not take the topmost band from a SetWindowPos right after the window was made.

Maul Window 0.10.0

Test readers for text input and the on-screen keyboard, and Win32 monitors' physical size and exact refresh rate.

Added

• The test backend's mwinTestGetVirtualKeyboard and mwinTestGetTextInput tell what a window last had carried out of its on-screen keyboard and text input requests: whether the keyboard shows and for what purpose, whether the window accepts text and the caret it gave (mwin-0038).
• Win32 monitors report their physical size, from the EDID's preferred timing or its base block (a timing in centimeters, which some monitors give, yields to the base block), and their refresh rate exactly (59.94 Hz, not 59), from DisplayConfig's rational rate.

Fixed

• Under Visual Studio's ClangCL toolset every target is compiled as C23: a target made after another fetched project was compiled below it, the generator mapping its C standard to stdclatest.

Maul Window 0.9.1

A fix the mutation sweep of 0.9.0's additions found.

Fixed

• On Wayland a tablet's mouse or lens tool told tilt when the
  compositor named its type before its capabilities, as compositors
  do: pucks and fingers post pen records without tilt whatever the
  order (mwin-0037).

Maul Window 0.9.0

Monitors' HDR facts and variable refresh on every backend, Android's
display as a monitor, pens on Wayland and X11, Linux gamepads'
batteries and X11's refresh rate: the gaps the requirements audit after
0.8.1 found. mwinHdrFacts gains a field, so the ABI changes.

Added

• Linux gamepads report their battery where the kernel tells it: the
  power supply a wireless pad's driver (hid-playstation, hid-nintendo,
  xpadneo and others) registers beside the input device, read when the
  pad connects and every five seconds after, a change told as
  mwin_eventGamepadChanged.
• mwinHdrFacts.headroom, the peak luminance over SDR white the output
  can show now (1 where it shows nothing brighter than SDR white, 0
  where unknown), for platforms that tell headroom and no nits
  (mwin-0036).
• X11 monitors report their HDR luminances from the EDID RandR shows
  (HDR output never on) and variable refresh from the vrr_capable
  output property; a change of either is a monitor change. The EDID
  parser checks every checksum and block length and is fuzzed.
• Win32 monitors report whether HDR output is on and the SDR white level
  (DisplayConfig; wide color forced on an SDR display is not HDR), the
  luminances from the EDID in the monitor's registry key, and the
  headroom from both. The backend links setupapi.
• Wayland monitors report their HDR facts where the compositor offers
  the color manager (wp_color_manager_v1, vendored from
  wayland-protocols 1.45): HDR output on with a PQ, HLG or extended
  linear transfer function, the target content light levels, SDR
  white's luminance and the headroom, there from the first frame and a
  change of the output's image description told as a monitor change.
• macOS and iOS (16 and later) monitors report their extended dynamic
  range: the headroom the screen shows once content asks for EDR, and
  whether EDR is on now; Apple gives no nits.
• Android lists its activity's display as the one monitor, the window's:
  its name, size, physical size, scale and refresh rate, and its HDR
  facts (the desired luminances; HDR on and the headroom from the
  HDR/SDR ratio on Android 14 and later) and adaptive refresh on Android
  16 as variable refresh, read when an activity starts or its
  configuration changes and every two seconds after.
• On the web the screen's monitor reports whether it shows HDR
  (dynamic-range: high), with no luminance, and tells a change.
• Wayland posts pen records from tablets (zwp_tablet_manager_v2,
  mwin-0037): position, pressure, tilt, contact, the barrel button and
  the eraser, with the window's cursor shown for the tool, and no mouse
  record, as compositors emulate the pointer only for a client without
  the tablet seat.
• X11 posts pen records from tablets' XInput2 devices (mwin-0037): a
  slave pointer of X input type STYLUS or ERASER, or of type TABLET or
  none with an eraser in its name or a pressure valuator, gives
  pressure and tilt from its labelled valuators, contact from its tip
  and the barrel from button 2, and no mouse record.
• X11 monitors report their refresh rate, from the timings of their
  output's CRTC mode (0 where the mode has none, as Xvfb's).

Changed

• On Wayland and the web a monitor is told changed only when one of
  its facts changed, as on the other backends.

Maul Window 0.8.1

Fixes the mutation sweep of the Wayland and X11 backends found.

Fixed

• On Wayland, a compositor that announces the same selection twice
  keeps it: the clipboard used to let the offer go and then read from
  it, which crashed the program, and the primary selection forgot the
  type of its text and read none.
• On X11, a window manager counts as running only when the window the
  root's _NET_SUPPORTING_WM_CHECK names names itself, as EWMH has it
  (mwin-0006). The property a window manager leaves behind when it
  quits used to count, and mode requests then waited for a window
  manager that was gone, to be denied, instead of being answered
  unsupported.

Maul Window 0.8.0

Text from outside the program made safe to slice, and screen readers on
the web: a composition's offsets always fit its text, monitor and
gamepad names keep their whole characters when cut, and the focus and
keys stay the window's while a screen reader works the program's ARIA
elements (mwin-0035).

Changed

• A composition's offsets fit its text (mwin-0034): the caret, the
  selection and every segment lie on character boundaries within the
  text, the selection in order and no segment empty. The core fits what
  the platform's input method hands it, where it used to drop a
  composition whose offsets lay outside its text and let an offset
  inside a character through. A fuzz target checks the fitting.
• On the web, the focus on an element in the accessibility host is the
  window's and keys there reach the program (mwin-0035). A screen
  reader in focus mode moves the focus to the program's ARIA elements,
  and the window used to lose it and the program its keys. The page
  keeps those keys' default actions, and a field there keeps its typed
  text; a focus request leaves the focus there.

Fixed

• A monitor name longer than 64 bytes, or with ill-formed bytes, keeps
  its whole characters before the cut or the fault; it used to arrive
  empty when the cut split a character (X11, Wayland) or, on Windows,
  whenever it did not fit.
• Gamepad names likewise: a device's name cut inside a character by the
  backend (evdev, the web) keeps its whole characters instead of
  arriving empty.

Maul Window 0.7.0

Maul Window 0.7.0 closes the gaps an audit of 0.6.0 against the requirements found: input methods on X11, the keys the platform keeps as a typed fact, monitor hotplug tested on the platform, and the touch keyboard on Win32.

Added

• Input methods on X11 (mwin-0030): IBus through its portal and Fcitx 5 over the session bus, Fcitx first when XMODIFIERS names it. Keys go to the input method without stalling the frame and are held in order until it answers (at most 100 ms); a key it takes is dropped, compositions arrive as mwin_eventImePreedit with segments and caret, committed text as mwin_eventTextInput, and the candidate window follows the caret.
• Keys the platform keeps (mwin-0031): mwinGetKeyReach tells whether a chord, a key with modifiers, is delivered, shared with the platform, uncertain (the desktop's configurable shortcuts may take it) or never delivered, from a table per platform. On the web, Chromium's own chords (Ctrl+W, Ctrl+T, Ctrl+N) never arrive. mwinTestSetKeyReach sets the test backend's answers.
• The touch keyboard on Win32 (mwin-0033): mwinRequestVirtualKeyboard shows and hides it through the window's InputPane (Windows 10 1607 and later), denied where a hardware keyboard is attached; the purpose sets the window's input scope; the part of the window it covers comes as mwin_eventVirtualKeyboardChanged.

Fixed

• X11 reports monitors set or deleted through RandR (xrandr --setmonitor, a desktop splitting a wide display), which the X server tells only as the root window's ConfigureNotify. Platform tests now plug monitors in and out on Wayland and X11.

Recorded

• Input methods on Win32 stay on IMM32, which receives every TSF input method through TSF's bridge (mwin-0032).