StageEvent served only redundant purposes:
- To detect whether the window has focus. That is covered by
key.FocusEvent.
- To detect whether the window is currently visible. That is covered by
the absence or presence of FrameEvents.
- To detect when the window native handle is valid. That is
covered by ViewEvent.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A uniform type allows convenient nil checks and for future window
backends on platforms other than Linux (which already had ViewEvent
as an interface).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This is mostly a refactor, but there are two user-visible effects:
- Window.NextEvent may be called even after DestroyEvent is returned.
- Window.Invalidate always wakes up a blocking NextEvent, even when a
FrameEvent cannot be generated.
As a nice side-effect, X11, Wayland and Wasm no longer require separate
goroutines for their window loops.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
In the early days of Gio, FrameEvent was part of package app. It was
moved to package system to enable layout.NewContext be a convenient
short-hand for constructing a layout.
However, it seems the better design to leave FrameEvent (and Insets) in
package app, and move layout.NewContext there as well. More importantly,
the move allows us to replace the event.Queue interface with a concrete
type.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
As described in https://devblogs.microsoft.com/oldnewthing/20150304-00/?p=44543
Windows extends maximized windows outside the visible display. This is
not appropriate for custom decorated windows, so this change implements
a workaround in the handling of WM_NCCALCSIZE.
While here, replace the deltas field from window state to fix issues
when switching between decoration modes.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit fixes a platform inconsistency that prevented custom-decorated windows
from being resizable on edges where their custom decorations placed a draggable
system.ActionInputOp.
The prior behavior always checked for this action type before
checking if the cursor was potentially in a window resize area, which meant that
for windows with material.Decorations, it was impossible to resize those windows
from their top edge. The system.ActionMove handler would always win. This is not
the case on platforms like macOS, so this commit makes the behavior consistent by
prioritizing resize over drag.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Some IME editors don't send explicit GCS_CURSORPOS messages, in
which case we should assume the cursor moves to the end of the
composition string.
Fixes: https://todo.sr.ht/~eliasnaur/gio/458
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Now, Gio will send one system.StageEvent with system.StageInactive when
the window is not active. It is implemented on macOS and Windows.
This change is not fully backward compatible, if your code compares
the Stage (`stage < system.StageRunning`), you need to consider
the new system.StageInactive.
Signed-off-by: inkeliz <inkeliz@inkeliz.com>
Previously, Gio doesn't reclaim the focus when they lose that to a
parent window. In such a case, the child window can steal
keyboard focus, and Gio will never recover it.
Now, Gio will recover the focus when clicked.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
The app.Window.Perform(ActionMove) is the wrong abstraction for
initiating a move gesture: Windows needs to know the move gesture
area at pointer move, and macOS needs to know the pointer button
down event that triggers the move gesture. This change replaces
Perform(ActionMove) with a new system.ActionInputOp that marks an
area movable.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the client-controlled system.Action machinery
for resize gestures initiated by the client. This is the replacement
implementation for Windows, where the behaviour is hard-coded to
mimic the decorated automatic handling.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
As I read the SetWindowPos documentation, SWP_NOZORDER is the correct
flag for keeping the z-order of the window.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the WS_OVERLAPPEDWINDOW style for undecorated
windows, in which case the fullscreen assumption will no longer hold.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Not only is the client guaranteed a ConfigEvent, but app.Window
can assume that an unsupported decoration change will be corrected
(by a ConfigEvent with Decorated forced to the supported value).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Previously, the window size is equal to the screen size. That doesn't
consider the size of the taskbar, causing the height be bigger than the
real height. Now, the maximized have the same behavior of windowed,
since both of them must include decorations and taskbar.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
It's now possible to directly user pointer.Cursor to add to the ops.
pointer.CursorText.Add(gtx.Ops)
This is an API change. Use pointer.Cursor directly instead of CursorNameOp.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
Add most of the common cursors defined by different systems.
Normalize cursor names to match CSS.
This is API change: some cursor names have changed, and the
underlying type is no longer a string.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
This change implements reporting of the caret position from Editor, as well
as Windows, macOS, Android support. As a result, the IME composition window
on Windows and macOS is now positioned correctly.
References: https://todo.sr.ht/~eliasnaur/gio/246
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This patch implements a mechanism for customizing window
decorations.
If a window is configured with app.Decorated(true), then
the widget/material.Decorations are applied. On Wayland,
the option is automatically set when the server does not
provide window decorations.
Server side decorations are no longer requested.
The Decorated flag is set according to the
server's requests.
Wayland is now the default driver for UNIX platforms.
References: https://todo.sr.ht/~eliasnaur/gio/318
Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
Commit #c4f98d3c1eab201419be255fafb139f7e10ad273 added
the Minimized and Maximized options for the Windows platform.
This change adds those for the remaining desktop platforms.
Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
The window modes are extended, following microsoft conventions.
We have Fullscreen, Overlapping, Maximized and Minimized.
These modes can be set via options when a new window is creates,
or modified later by calling helper functions like w.Maximize() and w.Center()
The window configuration is automatically updated when a user
modifies the window by dragging or clicking the icons on the window's title-bar,
minimizing or maximizing the window.
Any change, either by the user or the application will emit a ConfigChange event.
This is implemented and tested on Windows only.
API change. the app.Window methods Maximize and Center are replaced with similar
options. For example, to maximize a window use
w.Option(app.Maximized.Option())
Also, Maximize and Center implementations for X11 and macOS are left for a future
change.
Fixes: https://todo.sr.ht/~eliasnaur/gio/315
Signed-off-by: Jan Kåre Vatne <jkvatne@online.no>
Elias Naur