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>
For integrating with external window implementations (replacing
package app), access to the event router is required. Extract it
and put it into the new package router.
Router may belong in package io/event, but can't without introducing
import cycles.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The policy of rendering on a separate goroutine is separate from
the actual rendering. Reflect that by introducing the RenderLoop
type for driving a GPU from a separate goroutine.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
RegisterFragment creates an instance of a Java class and registers
it as a Fragment in the window's Context.
Signed-off-by: Greg Pomerantz <gmp.gio@wow.st>
The DestroyEvent ack allows the backend to release the window.
Ensure that the GPU associated with the window is done before that
happens.
Updates gio#67
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A frame ops buffers is tracersed twice: once for GPU commands,
and once for everything else. There is already a GPU goroutine for
concurrentl issuing of GPU commands; move the frame ops processing
to the goroutine as well. Both frame ops passed can then proceed
in parallel.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Record the time for generating a frame and submitting it as well
as the time for issuing the frame to the GPU and swapping buffers.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Sometimes it's useful to profile yet not continously re-draw. If the programs
wants the old behaviour, it can issue an InvalidateOp or call
Window.Invalidate.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
It was already true that the GPU wouldn't touch the frame after
calling GPU.Draw. This change makes FrameEvent.Frame block until
GPU.Draw is complete.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
If creating a GPU instance fails for some reason, we need to
receive the incoming frame from the application before reporting
the error in a DestroyEvent. If we don't, the a deadlock will occur
where the app is waiting for FrameEvent.Frame to complete, while
the Window waits for the app the receive a DestroyEvent.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur