Use HWND_TOP instead of HWND_TOPMOST in ActionRaise so raising a
window no longer pins it on top.
Signed-off-by: qiannian <qianniancn@gmail.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Mark WM_IME_STARTCOMPOSITION as handled after positioning the IME
composition and candidate windows.
Passing the message on to DefWindowProc can let Windows create its default
composition window, which shows the first composing character below Gio's
caret.
Fixes: https://todo.sr.ht/~eliasnaur/gio/687
Signed-off-by: qiannian <qianniancn@gmail.com>
Keep custom move areas mapped to HTCAPTION even when the window is
maximized so custom title bars preserve the standard Windows behavior
where double-click restores the window.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Now, it's possible to launch one Gio app using a custom URI scheme, such as `gio://some/data`.
This feature is supported on Android, iOS, macOS and Windows, issuing a new transfer.URLEvent,
containing the URL launched. If the program is already open, one transfer.URLEvent will be
sent to the current app.
Limitations:
On Windows, if the program listen to schemes (compiled with `-schemes`), then just a single
instance of the app can be open. In other words, just a single `myprogram.exe` can
be active.
Security:
Deeplinking have the same level of security of clipboard. Any other software can send such
information and read the content, without any restriction. That should not be used to transfer
sensible data, and can't be fully trusted.
Setup/Compiling:
In order to set the custom scheme, you need to use the new `-schemes` flag in `gogio`, using
as `-schemes gio` will listen to `gio://`.
If you are not using gogio you need to defined some values, which varies for each OS:
macOS/iOS - You need to define the following Properly List:
```
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>yourCustomScheme</string>
</array>
</dict>
</array>
```
Windows - You need to compiling using -X argument:
```
-ldflags="-X "gioui.org/app.schemesURI=yourCustomScheme" -H=windowsgui"
```
Android - You need to add IntentFilter in GioActivity:
```
<intent-filter>
<action android:name="android.intent.action.VIEW"></action>
<category android:name="android.intent.category.DEFAULT"></category>
<category android:name="android.intent.category.BROWSABLE"></category>
<data android:scheme="yourCustomScheme"></data>
</intent-filter>
```
That assumes that you still using GioActivity and GioAppDelegate, otherwise more
changes are required.
Events are routed to a new app.Events, which are not linked to a specific window.
Signed-off-by: inkeliz <inkeliz@inkeliz.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to send messages between multiple instances of the same
program, and we need something to distinguish Gio programs. Use the
app ID.
Signed-off-by: inkeliz <inkeliz@inkeliz.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
According to @kkeybbs, pressing the maximize button on Windows only
resizes the window up to its maximum bounds. That means we can leave the
button available, and only hide it when the window has a fixed size.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Windows Pointer API
(https://learn.microsoft.com/en-us/windows/win32/api/_inputmsg/) was used
to allow the detection of events when interacting with touch screens. This
also opens the gates for supporting other types of input devices (e.g. pens
and touchpads). Mouse events are now part of the pointer events (primary
events trigger WM_POINTER<DOWN|UP>, whereas secondary ones vanilla
WM_POINTERUPDATE, and cancellations WM_POINTERCAPTURECHANGED).
A fourth and fifth button (usually found in modern mice) has also been added
for completeness, though their integration in other OS-es shall be the
objective of future patches.
Signed-off-by: Marc <marc.leroy@samantree.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
When the window is created position it *before* processing the actions
to perform (which may include system.ActionCenter). Note that the
actions are performed in the callback windowProc().
Fixes: https://todo.sr.ht/~eliasnaur/gio/646
Signed-off-by: Marcel Juffermans <mjuffermans@paradigmone.com.au>
Setting the callback handler to nil in DestroyEvent should have no effect,
but may help debugging #603.
Also don't call the default window handler for WM_DESTROY since we're
already handling it.
References: https://todo.sr.ht/~eliasnaur/gio/603
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Change f7aa4b5c8 changed the fullscreen implementation to no longer require
the position and size of the fullscreen window.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There may be a window of time from WM_DESTROY is received to the WM_QUIT
message is delivered by PostQuitMessage. If so, we must not call w.draw.
Fixes: https://todo.sr.ht/~eliasnaur/gio/603
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Custom rendering applications need to be prepared to handle empty view events,
as an empty view event is sent during window shutdown. However, the current
implementation requires applications to write a platform-specific helper
function for each supported platform in order to check whether a received
view event is empty. This commit provides a safe, convenient, cross-platform
method that applications can use to detect this special view event and respond
to it.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
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>
qiannian