This commit adds support for the commonly-used XCURSOR_THEME and
XCURSOR_SIZE environment variables. Wayland lacks a protocol-level
way to standardize cursor size right now, but these variables are
used consistently by many applications and compositors. Many users
(including me) will find that their environment is already configuring
these for them, and will get consistent cursor sizing for free.
I explored a lot of ways to tackle this, but it looks like nobody has
ever gotten around to implementing the cursor theme protocol discussed
here:
https://wayland-devel.freedesktop.narkive.com/VuMSOO55/possible-wayland-extension-to-publish-mouse-pointer-size
Given that it doesn't seem to be resolved anytime soon, supporting a
widely-used convention to tweak these things seems reasonable to me.
I say that it fixes issue 382 because it enables the user to make
Gio's cursor size match the rest of their system.
Fixes: https://todo.sr.ht/~eliasnaur/gio/382
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.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>
Allowing clients to initiate resize gestures is a waste: macOS
doesn't support them, and the only reason we added them was to
implement client-side decorations for Wayland. Now all desktop
platforms implement resize gestures as needed, and we no longer
need the system.Action actions.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the system.Action machinery for initiating resize
gestures. This is the Wayland implementation that hard-codes the border
drag gesture for resizing.
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>
Until now, fallback decorations were only needed for Wayland client-side
decorations. We're about to support app.Decorated(false) one some platforms,
where Window should not fall back to drawing its own decorations.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to enable platform support for switching native
window decorations on and off. However, the Wayland platform
only supports server-side switching of decoration mode, not
(yet) client-side. Thus, don't switch mode even when asked to.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, client-side decorations for Wayland were drawn
before client content, which was prevented from drawing over
decorations with a clip. While visually correct, resize handles would't
work as long as client listeners are near the window edges to swallow
pointer input.
This change makes app.Window draw decorations last, fixing resizing
and saves a clipping operation. This is an alternative to the original
fix for #361, commit 20d4bc2.
References: https://todo.sr.ht/~eliasnaur/gio/361
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The xdg_toplevel expects the min/max window size in DP rather
than pixels. The scaling factor would be applied twice because
we supplied pixels that we scaled ourselves, resulting in windows
twice the expected size on HiDPI screens. This bug probably went
for so long without being detected because it only manifests if
you actually set a minimum or maximum size.
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
Not all wayland compositors advertise the global registry events
in the same order. In particular, river and sway differ in that
sway advertises the data_device_manager before the seat, and river
does it after. This commit updates our code to correctly bind
the data_device so that we can work with the clipboard regardless
of the registry event order.
Special thanks to Isaac Freund (river maintainer) for helping me
find the root of this problem. You can see Isaac's extremely helpful
and detailed analysis here:
https://github.com/riverwm/river/issues/554#issuecomment-1059750874
Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
There are no public API that uses f32.Rectangle anymore. Move Rectangle
to an internal package for internal use.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The unit.Value is a struct and thus more inconvenient to use than its
underlying float32 type. In addition, most uses don't need a general
value, but rather a specific unit given by the context. This change
replaces unit.Value with two float32 units, Dp and Sp. It also changes
variables and parameters of unit.Value to a specific unit type matching
the context. That is, unit.Dp everywhere except for text sizes which are
in Sp.
Switching to typed float32s has multiple advantages
- They can be constants:
const touchSlop = unit.Dp(16)
- Casting untyped constants is no longer necessary:
insets := layout.UniformInset(16)
- Calculation with values is natural:
func (s ScrollbarStyle) Width() unit.Dp {
return s.Indicator.MinorWidth + s.Track.MinorPadding + s.Track.MinorPadding
}
The main API change is that calls to gtx.Px must be replaced with either
gtx.Dp or gtx.Sp depending on the unit.
Idea by Christophe Meessen.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
op.Offset is a convenience function most often used by layouts. Layouts
usually operate in integer coordinates, and the float32 version of op.Offset
needlessly force conversions from int to float32. This change makes op.Offset
take integer coordinates, to better match its intended use.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The OpenGL backend needs it, but I keep forgetting to test it when
rearranging the window rendering code. The gogio X11 end-to-end test
tests this issue, but unfortunately it is disabled because of flakiness.
Fixes: https://todo.sr.ht/~eliasnaur/gio/412
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A recent change broke custom rendering by not allowing the client
to continue after calling FrameEvent.Frame. This change makes sure
the client is allowed to continue regardless of rendering mode.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Android doesn't distinguish between the arrow keys on a keyboard and the
directional keys on a remote control, so there's no way to move the caret
in an Editor with arrow keys. This change updates the Android port to map
Android's DPAD_* key codes to the arrow key names, fixing caret movement.
The change also updates Editor to only request arrow keys that actually move
the caret, to keep directional focus movement working.
Fixes: https://todo.sr.ht/~eliasnaur/gio/410
Signed-off-by: Mearaj <mearajbhagad@gmail.com>
Instead of cmpletely replacing the IME snippet for every update, expand
the old range if there is overlap. This change avoids never-ending
restarts of the IME on Android where snippets are expanded in two
calls, one for expanding before the selection and one for exanding after
the selection.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
It's much simpler to map the Android back button to a key.Event and
let the usual key filtering determine whether to block its default
behaviour.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change adds key.NameUp/Down/Left/Right and maps the Android TV
remote directional keys to them. As a side-effect a key.InputOp can
now receive directional keys (and block their focus movement).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, Tab and Shift-Tab would always result in focus
movement. This this change, a key.InputOp with a matching Keys set
will block focus movement and deliver the events to it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We should return as soon as possible from FrameEvent.Frame to allow the main
goroutine to continue processing other tasks. Whereas GPU.Frame may touch
the frame ops, GPU.Present will not, so this change moves Present to after
returning from FrameEvent.Frame.
This is a variant of 38ff78df5d that
works on OpenGL where context locking is required.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We should return as soon as possible from FrameEvent.Frame to
allow the main goroutine to continue processing other tasks.
Whereas GPU.Frame may touch the frame ops, GPU.Present will not,
so this change moves Present to after returning from FrameEvent.Frame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur