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>
Inspired by the discussion at golang.org/issue/70089, this change makes
our particular NSApplicationDelegate implementation optional.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There are two max window size settings on macOS, `contentMaxSize` and
`maxFullScreenContentSize`. Set the latter to avoid a window being
resized larger than its maximum in full screen mode.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
An IME session must be discarded when its text content no longer matches
the underlying text component content. However, the check for matching
was too pessimistic; the IME session would be discarded if the new
snippet from the text component was not equal to the snippet reported to
the IME. This change implements a refined check that only discards a
session if the content of the overlap between the new and old snippets
don't match.
Fixes an IME issue reported by Zhang Zj.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
By propagation, we restore the system behaviour for shortcuts the program
don't want, for example the system beep.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The fix for #616 went to far by attempting to support macOS key bindings
through doCommandBySelector. Issue #625 is a consequence, but more
fundamentally, key bindings does not work with support for key.Release
events.
Remove key binding translation and fix#626, and add a check whether an
IME swallowed a key event, keeping #616 fixed.
While here, replace the KEY_ constants with ASCII codes.
Fixes: https://todo.sr.ht/~eliasnaur/gio/625
References: https://todo.sr.ht/~eliasnaur/gio/616
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change generates keypress and release events for modifier keys in macOS.
Specifically the Control, Alt, Shift and Command keys.
Signed-off-by: Jeff Williams <kanobe@gmail.com>
Widgets such as Editor use certain key events such as the backspace key
to implement text editing. On macOS, such key events are sometimes used
by an input method, and in those cases the key effect would be applied
twice: first by the IME and then the Editor.
Report such key events through the doCommandBySelector callback, which
receives key events not handled by the IME.
References: https://todo.sr.ht/~eliasnaur/gio/616
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, the window state was explicitly updated whenever
Window.Option was called. However, the system may also change window
state as a result of user gestures, but those changes did not result in
ConfigEvents reflecting them.
Remove the explicit state updates and track them when the system tells
us it has changed.
This is a step towards fixing #600 which require accurate window state
tracking.
References: https://todo.sr.ht/~eliasnaur/gio/600
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>
Don't call eventLoop.FlushEvents which in turn applies Options and
executes Run functions before the window is fully initialized.
References: https://todo.sr.ht/~eliasnaur/gio/575
Signed-off-by: Elias Naur <mail@eliasnaur.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>
Instead of sending ViewEvents once at construction and once at destruction,
it's better to send them when the underlying NSView changes attachment.
The main advantage is that we're about to move the destruction and
emitting of DestroyEvent to the NSView's dealloc method. However, the
dealloc will not be called if user code has a strong reference to it
through a non-empty ViewEvent. By sending an empty ViewEvent when the
view is detached, well-behaving users will remove the strong reference.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Their absense didn't make a practical difference so far, but we're about
to refactor the macOS event processing loop where the pools do matter.
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>
Calling window.Perform(system.ActionRaise) does not show the window on
the top if the app is currently not active. This can happen for example
if the app integrated with systray (https://pkg.go.dev/fyne.io/systray)
where the menu item launches a window, the window is not showing at the
top. It is fixed by activating the current app if necessary.
Signed-off-by: Siva Dirisala <siva.dirisala@gmail.com>
The NSWindow.zoomed property is not reliable when a window is being
constructed. Only call it when necessary.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
NSView only has events for left, right, and other. Also, the Go side
wasn't actually checking for buttons other than left and right.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
The windowWillClose callback is too soon to destroy our Window:
at least draw callbacks may be called after windowWillClose but
before the window is gone. This change moves cleanup to the
viewDidMoveToWindow callback where we're sure the NSView is no longer
active.
Fixes: https://todo.sr.ht/~eliasnaur/gio/466
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>
The Nix version of the macOS toolchain has difficulties compiling
Objective-C modules; disable modules instead of figuring out why.
It also doesn't include any frameworks automatically; add them explicitly.
While here, move suppression of OpenGL deprecation to a GL-specific
file.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We used to track the pressed pointer buttons through the global function
[NSEvent pressedMouseButtons]. However, it's possible that at the time a pointer
press event is delivered, the pointer button is up again. To ensure a consistent
view of the pointer press state, track it through the buttonNumber property on
delivered events.
Signed-off-by: Elias Naur <mail@eliasnaur.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>
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>
inkeliz