Apparently, darwin/arm64 cgo doesn't match the types of YES and BOOL:
os_macos.go:235:40: cannot use _Ciconst_YES (type untyped int) as type _Ctype__Bool
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Building an iOS results in errors about missing NSCursor:
$ gogio -target ios -o app.app ./kitchen
gogio: go build -ldflags=-s -w -X gioui.org/app/internal/log.appID=org.gioui.kitchen -buildmode=c-archive -o /var/folders/_7/lnt35k555hl2bs7fjygkhgx00000gp/T/gogio-770783182/gio-amd64 -tags ./kitchen failed: # gioui.org/app/internal/window
os_darwin.m:26:10: error: use of undeclared identifier 'NSCursor'
os_darwin.m:32:10: error: use of undeclared identifier 'NSCursor'
os_darwin.m:40:14: error: use of undeclared identifier 'NSCursor'
os_darwin.m:43:14: error: use of undeclared identifier 'NSCursor'
os_darwin.m:46:14: error: use of undeclared identifier 'NSCursor'
os_darwin.m:49:14: error: use of undeclared identifier 'NSCursor'
os_darwin.m:52:14: error: use of undeclared identifier 'NSCursor'
os_darwin.m:55:14: error: use of undeclared identifier 'NSCursor'
os_darwin.m:58:14: error: use of undeclared identifier 'NSCursor'
NSCursor is supported under mac catalyst; disable NSCursor support while
figuring out how.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
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>
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>
pierre