This CL implements the app.Main function as a blocking-forever function
for JS, Wayland, Windows and X11.
This works better for applications that can now programmatically close
windows.
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>
An interface for scaling dp and sp is overkill, at least for all
current uses. Make it a concrete struct type, and rename it to the
shorter and more precise Metric.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Then, make layout.Context.Now a field, copied from FrameEvent.Now.
API change:
gofmt -r 'gtx.Now() -> gtx.Now'
Signed-off-by: Elias Naur <mail@eliasnaur.com>
All accesses to the view map now happens on the main thread, so
there is no need for a sync.Map anymore.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Recent changes to the macOS threading exposed a problem where a
window's display link may fail to start after being started and stopped
in rapid succession.
Introduce a displayLink type that waits a while after the last stop
request before stopping its display link. That seems to be the way
other projects are using display links.
As a bonus, the new implementation avoids the potentially expensive
overhead of frequent starting and stopping the underlying OS thread.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The macOS redraw callback is not invoked on the main thread, so its
access to window fields must be synchronized.
An alternative would be to schedule the asynchronous redraws on the main
thread, but I believe frame callbacks are performance-sensitive enough
to warrant the extra locking complexity.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Only the synchronous draws from the main thread may involve changing
width, height and scale. Introduce cached window.width and window.height
fields and limits updates to main-thread draws.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, we had a viewDo that serialized a function on a view
on a single goroutine. For better or worse, most callbacks in Cocoa
happen on the main thread, so we might as well use that.
The only exception is the frame callback from the CADisplayLink.
We could force that through the main thread as well, but for
efficiency settle with making the view-to-window map synchronized.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Asynchronous drawing happens only in onFrameCallback, where we have to
check for disappearing views. onDraw however, is synchronous and should
always have a valid view.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
According to
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html#//apple_ref/doc/uid/20000738-125024
Cocoa is by default not multithread-safe for programs that use the posix
api for creating threads:
"
For multithreaded applications, Cocoa frameworks use locks and other
forms of internal synchronization to ensure they behave correctly. To
prevent these locks from degrading performance in the single-threaded
case, however, Cocoa does not create them until the application spawns
its first new thread using the NSThread class. If you spawn threads
using only POSIX thread routines, Cocoa does not receive the
notifications it needs to know that your application is now
multithreaded. When that happens, operations involving the Cocoa
frameworks may destabilize or crash your application.
"
That includes Go programs.
The fix, as discovered by Steeve Morin, is to create and launch
an empty NSThread.
Add a package that does that, and use it everywhere Cocoa is used.
Sigh.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Allows things like "ctrl-{" and ".".
All punctuation is returned as-is, e.g. "!" is "!", not "shift-1", and
"{" is "{", not "shift-[".
Also add the Enter key as a known key (fn-return on my Mac).
Signed-off-by: Larry Clapp <larry@theclapp.org>
Function keys don't have a natural rune representation so switch
Event.Name to be a string to fit "F1"-"F12".
Fixes gio#59
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, Gio tries hard to come up with a reasonable UI scale
factor on desktop OSes derived from the physical dimensions and
resolution of connected monitors. Gio also attempts to detect the user
specified system UI scale and apply it.
However, all that is complex and misguided:
- The UI scale should not depend on whatever monitor is connected at
program startup - For multiple monitors, it's unclear which one to base
the scale off. - Applying both a monitor derived scale *and* the user
specified scale is wrong, because the user scale is relative to some
fixed scale, not Gio's derived scale. - With an automatic scale, Gio
does not respect user preference and will not have a similar scale to
other programs on the desktop.
Get rid of the the automatic UI scale detection and rely only on the
user scale.
Updates gio#53
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Sebastien Binet