kettle11 / kapp Goto Github PK

• Windows

• Web

Windows and Web should report MouseDelta events in addition to PointerMoved events. MouseDelta events should be sent even when the mouse cursor position is locked.

https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/platforms/web/src/application_web.rs#L30

set_mouse_position should set the mouse position relative to the current window (or canvas?)

Investigate pointer lock API here:
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API

Perhaps other platforms should be implemented to have a similar API, as "locking" the pointer seems to be the most common use case for moving the mouse.

The events_mac file expands with cargo expand to ~3300 lines due to macros when the non-expanded version is ~660 lines.

I partially began a transition away from using the objc macros in 0d96c59 however I did not fully complete the transition. The partial reduction of the macro shaved ~6% off the build time.

However I'm now having second thoughts. Now to use new classes and selectors code must be declared in multiple additional places instead of one macro that handles it all. It makes kapp's code base aesthetically a bit messier and adds a little friction to implementing new changes.

https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/platforms/web/src/application_web.rs#L42

set_mouse_position should be implemented here:
https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/platforms/macos/src/application_mac.rs#L259

The function accepts an x and y value expressed in physical screen coordinates.

The coordinates should be converted to the appropriate coordinate space for the mouse's current screen.

This function call should only move a mouse within the current screen, which is what most games would need.

The README states:

kApp strives to be unsurprising, quick to build, and straightforward to maintain.

Now, of course at this point in time kapp is nowhere near as production-ready/battletested as SDL2, winit/glutin, etc. However, to me it's unclear if it's a project goal in the first place to eventually be production-usable. To me, an unsurprising, production-usable windowing library is one that "just works" on Windows XP+ & OSX Mountain Lion+ or something along those lines. Will kapp ever fit that bill or does it have a smaller scope in mind? Clarifications in the README would be appreciated.

• Windows

Presently Windows works in logical coordinates and MacOS works in physical coordinates. Both should work in physical coordinates.

'Physical' isn't exactly the right term as the scale may not be physical, but it is unscaled and more similar to the native resolution.

The license file is great, but rust tooling also looks at the license entry in the Cargo.toml file.

Borderless fullscreen is a useful and common feature for games.

Investigation is needed to find common implementations for Windows and MacOS.

Why exactly are we creating a second dummy window here?

Perhaps IME text entry mode needs to be toggled on and off somehow instead of always being available.

Presently it's annoying to work with timestamps on events as there's no frame of reference to compare them to.

There should be a mechanism to get the current timestamp. It could be exposed as a function on application, or perhaps a function more globally available.

Right now key events are received, but they are a poor substitute for platform native character input.

• Mac
• Web
• Windows

In addition setting the text box for IME input may need to be supported as well, probably as a function that can be called on a window. Presently on Mac it appears in the lower left corner, which isn't ideal.

Windows in particular may not be reporting modifier keys at all.

On Windows MapVirtualKeyW(scancode, MAPVK_VSC_TO_VK_EX) needs to be used.

Mac may be missing some modifiers as well.

Some investigation is required here to see which keys work properly and which do not.

To reproduce create a window and move the cursor in and out over the lower right corner.

@lunabunn I know you said it in the chat, but just to get a record of it here, do you allow relicensing your changes as " ZLib or Apache 2.0 or MIT"?

https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/platforms/web/src/application_web.rs#L39

set_cursor should change the cursor on the canvas for web.

The cursors from the cursor enum must be supported (or approximated with something comparable): https://github.com/kettle11/kettlewin/blob/6fb7ae5d463d8efb42a4cf164c685bd98ab41f01/platform_common/src/cursors.rs

Simply wiggling a mouse while kapp is launching causes the window to launch without focus requiring an alt-tab.

Makepad's version of the fix is here: https://github.com/makepad/makepad/blob/master/render/src/cx_cocoa.rs#L225

Winit's version of the fix is this file (which also includes some great contextual info): https://github.com/rust-windowing/winit/blob/1ddceeb0630994e4960493b1fe92bc72f8c5a54b/src/platform_impl/macos/activation_hack.rs

wasm-bindgen and it's ecosystem is massively useful but also very complex.

It is possible to interact with web APIs with a thin wrapper API instead of wasm-bindgen

Pros:

• Cut web build times dramatically (Web would become the fastest platform to build)
• May unblock WebWorker and AudioWorklet capabilities that wasm-bindgen cannot currently handle.
• More kapp logic can exist on the Javascript side, instead of trying to awkwardly put it into Rust.
• Much simpler stack
• Potentially better performance by reducing back and forth between Wasm and JS (but may be insignificant)
• More control over destiny: wasm-bindgen leadership has been focused on other things over the last year, development might slow down.

Cons:

• Web APIs are not automatically wrapped. There are a ton of them and kapp would have to add them as needed. Adds more friction to new features.
• Losing expertise of wasm-bindgen.
• Harder to integrate with other Rust crates that use the Rust ecosystem standard of wasm-bindgen
• wasm-bindgen-cli performs some optimizations that would be lost.
• Potentially more difficult to integrate with Javascript libraries.
• Obviously it takes time to port libraries to the new thin wrapper. In particular glow depends on wasm-bindgen so new GL bindings would be needed, which would not be hard but would take some time.

Some of this work is already started on the kwasm branch: https://github.com/kettle11/kapp/tree/KWasm
I intend to investigate / continue work on the branch in the near future.

Does kapp plan to add Linux support for the future? Wayland? X11? Both?

Tracking issue for investigating (not necessarily actually implementing) an SDL backend for kapp. This should be a separate crate (kapp-sdl) within this repository that is exposed through kapp via a feature-gated dependency.

Benefits:

• Have a portable, production-ready, and battle-tested alternative implementation for production builds
• Verify that kapp's API is sensible and matches certain "expectations" set by SDL
• Easier to implement features that aren't yet available in core kapp (more freedom to play around with the API if stuff is actually implemented, we can aim for eventual feature parity)
• Act as a nice, Rusty wrapper around SDL

Points for consideration:

• This would obviously be more work to maintain
• #44 mentions smooth window resizing as one of kapp's goals, but SDL can't do this
• Which set of SDL bindings should we use? fermium? sdl2? Own set of bindings?

Thoughts?

It is useful to query for the actual properties of the GLContext backbuffer after it's been initialized.
The method is stubbed out on each platform but is not yet implemented.

• MacOS
• Windows
• Web

This behavior was introduced in order to avoid resizing / lag issues on MacOS. For now it's fine that disabling Sync is broken, but it should be fixed eventually.

Implementation should go here:
https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/gl_context/src/windows/mod.rs#L193

EDIT:

Add an srgb flag to GLContextAttributes and implement it for different platforms.

• Windows
• Mac

Web currently doesn't support specifying the color space, see: https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md

Original Issue:

Currently, I'm using a fork that changes

Why is that a false, anyway? Is it a placeholder? Shouldn't there be a flag for this in GLContextAttributes?

Presently neither Windows or Web issue MainEventsCleared. This is an inconsistency that makes it hard to use the event.

Presumably web will just not handle a 'maximum' window size, but it should be possible for Windows and Mac.

What does kapp do differently than alternatives like winit or (probably the most similar) miniquad?

Right now another event must awake the program async callback if it's awaiting something.

For example if an asset is loaded the parent callback won't be woken until another event (like user input) occurs.

Launched windows remain behind all windows. Investigation is needed to figure out why.

Does this impact other windowing libraries?

WM_SYSKEYDOWN and WM_SYSKEYUP should be matched on as well to handle the additional keys.

Right now it’s very easy to click, move the mouse outside the canvas, release, and return never receiving a mouse up event.

Resizing a window can produce slight stuttering.

This is seen in the platformer.rs example.

It appears the redrawing of the window becomes out of sync with the presentation of the window. I don't remember this always being the case, and it should be possible to fix it.

rustc 1.45.0-nightly
kApp 0.1.0

    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/examples/hello`
[1]    24666 segmentation fault  cargo run --example hello

• Windows (Thanks @lunabunn !)
• Mac
• Web

kapp's IME support should make it easy to implement correct behavior. Proper IME input is critical for inputting characters in most non-English languages.

Probably events need to be emitted when the intermediate results change and when a final text input occurs.

Previously the CharacterReceived event handled the latter. Instead a TextInput (or a better name?) event with a String should be sent as it's closer to the platform native behavior. Allocating a String shouldn't be a problem for these events as they're relatively infrequent.

The various constants here should be 'const':

Right now the window_builder::maximum_size and window_size functions claim Sets the maximum size of the window's content area (excluding the titlebar and borders), but on Mac the titlebars are actually included in the size.

Are the titlebars definitely excluded on Windows?

Should specifying the size include any titlebars?

@lunabunn Do you have thoughts here?

The NSView class used in the Window needs to be overridden to implement: acceptsFirstMouse:. See Apple docs here: https://developer.apple.com/documentation/appkit/nsview/1483410-acceptsfirstmouse?language=objc

The following properties need a function call to change them:

• Title
• Minimum Size
• Resizable

And potentially other properties?

restore_window should be implemented here: https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/platforms/web/src/application_web.rs#L22

restore_window on web should exit fullscreen.

The GLContext creation part of this crate is mostly incomplete, a good first step would be to allow the GL version to be specified.

restore_window should be implemented here:
https://github.com/kettle11/kettlewin/blob/e0bb32b4e9083493bafcc53e5e97f00a24978536/platforms/macos/src/application_mac.rs#L245

resture_window should return the window to a "Windowed" state that is neither minimized or fullscreen.

• Windows (However no "Double Click Up" event is sent)
• Web

Note that double click on web by default triggers on the second up, which is different than other platforms. Perhaps this should be reconciled.