The app and app/internal/wm packages are tightly coupled, requiring
quite a bit of forwarding types, values and constants from the internal
package to export it. Further, no other package imports package wm.
This change merges the two packages.
While here, drop the pre-Go 1.14 SIGPIPE workaround.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Instead of handing the internal/wm driver a method to run code on the
(blocked) main thread, just run the necessary driver methods on the main
thread.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Releasing the renderer is fine, but releasing the underlying context
introduces flicker when restoring a Gio window on macOS.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The platform GPU context must be Refreshed on the window event thread,
but our rendering loop must not, because it may also want access to the
window event thread.
Fixes gio#236
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The NSViewGlobalFrameDidChangeNotification notification is documented to
be fired every time [NSOpenGLContext update] needs to be called.
However, the notification fails to fire on my setup when a window is
moved to a display with a different pixel scale, which leads to
incorrectly sized output.
This change gets rid of the notification and updates the context before
every frame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Previously, the on-screen keyboard always displays the text keyboard,
(QWERTY or equivalent).
For optimal user experience, it's possible to specify the keyboard type
using `InputHint`. The on-screen keyboard will provide shortcuts or
restrict what the user can input.
Due to some limitations (gio#116), only numeric and text keyboards are
supported on Android.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Instead of a single racy window.driver field, maintain a driver
reference for each goroutine that needs it: the window.run event loop
and the callbacks structure.
Fixes gio#230
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The previous change wasn't enough, because the `dead` channel wasn't
being closed in an orderly window close.
Add a close of the event output channel in the premature close code path
to match the orderly close.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The event input channel is closed after receiving a DestroyEvent, to
catch any events erronously delivered after window close. However,
the recently introduced WakeupEvent *may* be delivered after window
close. This change leaves the even channel open even after closure,
which effectively ignores such events.
Fixes#227 (again)
Signed-off-by: Elias Naur <mail@eliasnaur.com>
app.Window implements a method for safely running functions against the
underlying native window through the driverFuncs channel. However, the
functions still run in a different goroutine than the one driving the
native event loop, which forces the implementations in package wm to do
complicated synchronization.
A previous change added a mechanism to run functions in the native event
loop thread. The macOS port needed this functionality, but with some
care it can be generalized. That's what this change does through the
new Run method.
The advantage is that the thread switch dance is now confined to
app.Window, with the help of a generic wm.Driver.Wakeup method. All
other Driver methods can then assume they run on their event loop
threads.
Run is exported because it is also needed for programs that use
Windows configured with CustomRenderer to control their own rendering.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
CustomRenderer disables the construction and binding of a GPU
context to the Window. Combined with ViewEvent and gpu.New, a Gio
client can mix Gio UI and custom rendering.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
NSOpenGLContextView couples the window manager logic tightly with
OpenGL. Use generic NSViews, and attach NSOpenGLContext just like the
other platforms.
This change prepares for supporting GPU contexts created by clients as
well as a future Metal port.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A Window can now be requested to change its options after
it has been started via its Option method.
All options are supported on macOS, Windows and X11.
On Wayland, only the Size and Title options can be changed
at runtime.
Signed-off-by: pierre <pierre.curto@gmail.com>
Switching to pointer values in Options, including using window manager defaults for size and title, in preparation for updating options on the fly.
Signed-off-by: pierre <pierre.curto@gmail.com>
The option field WindowMode allows changing the window mode of an application in either Windowed or Fullscreen.
Only macOS, Windows and X11 platforms are currently supported.
Updates gio#89.
Signed-off-by: pierre <pierre.curto@gmail.com>
Package wm (for "window manager") is a better fit for the package, and
distinguishes it from the low-level package windows for the Windows API.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Add support to Router so that the cursor can be changed with CursorNameOp without any mouse movement.
Enter and Leave events are also delivered as areas change.
Signed-off-by: pierre <pierre.curto@gmail.com>
Using Window.Invalidate for animation with, say
var w Window
var e FrameEvent
w.Invalidate()
e.Frame(...)
stops and immediately starts animation mode which is inefficient
and may cause jitter in the redraw timing.
InvalidateOp is the efficient and sure way to achieve smooth animation,
and Invalidate only exists for external events where there is nowhere to
add an InvalidateOp.
We can do better, so this change makes Invalidate almost as efficient as
InvalidateOp by checking for Invalidates at the same time we check for
InvalidateOps.
Note that we can't avoid the inefficiency in all cases, for example
when the calls above are swapped,
e.Frame(...)
w.Invalidate()
the Invalidate may not be registered before the check during Frame.
While here, add a note to Invalidate that it's meant for externally
triggered redraws.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Previously, the only way to manipulate the clipboard (read or write) is
using the `app.Window`.
The new `clipboard.ReadOp` and `clipboard.WriteOp`makes possible to
read/write from the widget.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
API change. Update your code with gofmt rule and goimports:
gofmt -r "system.ClipboardEvent -> clipboard.Event"
goimports
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Window creates the context, and should also be responsible for
destroying it.
As a bonus, the wrong release ordering of loop.renderLoop is fixed.
Before this change, the context would be destroyed before the renderer
got a chance to destroy its resources.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The app.MinSize and app.MaxSize options restricts the window size:
w := app.NewWindow(
app.Size(unit.Dp(600), unit.Dp(596)),
app.MinSize(unit.Dp(600), unit.Dp(596)),
app.MaxSize(unit.Dp(600), unit.Dp(596)),
app.Title(APPNAME),
)
Signed-off-by: Jason <sourcehut@sweatyballs.es>
Recently support was added for multiple top-level windows. Add support
for closing those windows.
macOS only; all others stubbed out.
Signed-off-by: Larry Clapp <larry@theclapp.org>
Key had an unfortunate association with keyboard input.
This is an API change. The following rewrites were run to fixup
Gio code:
$ gofmt -r 'pointer.InputOp{Key:a} -> pointer.InputOp{Tag:a}' -w .
$ gofmt -r 'pointer.InputOp{Key:a, Grab:b} -> pointer.InputOp{Tag:a, Grab:b}' -w .
$ gofmt -r 'key.InputOp{Key:a} -> key.InputOp{Tag:a}' -w .
$ gofmt -r 'key.InputOp{Key:a, Focus:b} -> key.InputOp{Tag:a, Focus:b}' -w .
$ gofmt -r 'event.Key -> event.Tag' -w .
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The app.ReadClipboard and app.WriteClipboard can be used to interact
with the system clipboard. The clipboard may be asynchronous, so
system.ClipboardEvent is introduced to deliver the result of a read.
Updates gio#31
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Change gioui.org/commit/0e70fbc1262920a69c60409285795b6bb8701b09
added a note that app.Window.Queue must only be used during the
processing of a FrameEvent. The change was added because a Gio
user took the existence of app.Window.Queue to mean it was always
available.
This change reduces the scope of window Queues by moving it from Window
to FrameEvent, and minimizes the risk of misuse by not offering
Window.Queue at all.
Note that the gioui.org/commit/a937a7653439333b8c6fc30c7a6039b717339766
change moved Window's Frame method (named Update) to FrameEvent for the
same reason.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Some GPU APIs such as Direct3D can return an error after drawing
a frame indicating a transient device error. Recreate device and
retry if it happens.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur