tao
tao copied to clipboard
Tracking issue for different implementation between `winit`
This is an issue to track which PR or commit we add that's not in winit yet. We should either add to winit too or adjust the behavior in tao, so they are consistent.
- [X] [ALL] system tray - tauri-apps/tray-icon
- [X] [ALL] menus - tauri-apps/muda
- [X] [ALL] global-hotkey - tauri-apps/global-hotkey
- [X] [Windows] ~~Transparent Windows don't work unless we draw to the window surface https://github.com/rust-windowing/winit/issues/2502~~, use
softbuffer
to clear the window surface - [ ] [macOS] https://github.com/tauri-apps/tao/commit/1359fccfe5b95de9a28afb92e9ac3adfc331fb3c - Default cursor will not set to arrow cursor only
- [ ] ~~[ALL] https://github.com/tauri-apps/tao/commit/c0d5a5307cd6625622989ef529f3189967f3a76f -
monitor_from_point
~~ REJECTED: useavailable_monitors()
and compare bounds with the point. - [ ] [ALL] https://github.com/tauri-apps/tao/commit/5d8bf51d7ea2ea89feb4e8b003e583fed69bf300 -
cursor_position
- https://github.com/rust-windowing/winit/pull/2648 - [ ] [macOS] https://github.com/tauri-apps/tao/commit/045b768e30b4dc261edcaba4b8ed8ec9fee8305e - call
nextResponder
inkey_down
- [ ] [iOS] https://github.com/tauri-apps/tao/commit/651137ce9ec5bf37593e6641d8f6ab79fc9d6f3c - iOS proxy Send
- [ ] [Windows] https://github.com/tauri-apps/tao/commit/62db431338636dd0adafca15d636c08f68941984 - focus hack
- [ ] [Windows] https://github.com/tauri-apps/tao/commit/c5d606dffeb1733ab06fd8c43eb3b9e7b2f553fe - auto-hide taskbar with maximized undecorated window
- [ ] [macOS] https://github.com/tauri-apps/tao/commit/813290130ea255b2cb45a66234a422519d13f667 - fix the unexpected shifting of the window when dragging after closing the share dialog
- [ ] [ALL] https://github.com/tauri-apps/tao/commit/3b7e0d9af3dd258f1cb8d0df65893a0fb6bdd28f & https://github.com/tauri-apps/tao/commit/baa02977483c9da21451d65bde0a64230778a034 - progress bar support
- [ ] [ALL] https://github.com/tauri-apps/tao/commit/ea14c6b104cecf131ab5e7ba320bc52373efa3d1 - split min and max sizes
- [ ] [iOS] https://github.com/tauri-apps/tao/commit/8f361f0c19014e6ef647fe7fa8adc47718796984 - Universal links
- [ ] [macOS] https://github.com/tauri-apps/tao/commit/093d8fbc20954d51c96c94618479ff465ca55888 -
openURL
,openFile
,openFiles
- [ ] [Windows] https://github.com/tauri-apps/tao/commit/4d0e1862b6a2a7580631d637ef937d217f0797bf - RTL
- [ ] [ALL] https://github.com/tauri-apps/tao/commit/baa02977483c9da21451d65bde0a64230778a034 https://github.com/tauri-apps/tao/commit/3b7e0d9af3dd258f1cb8d0df65893a0fb6bdd28f - Progress Bars
- [ ] [Windows] https://github.com/tauri-apps/tao/commit/6df56c2dd1b0f4695dd40b70f75a22d1ba32c384 https://github.com/tauri-apps/tao/commit/fce9d2603e55f2b37ff69acfbbd484de6298351e https://github.com/tauri-apps/tao/commit/29b01bff2b547ca5b6bba57584c9c7cc2b93c098 - app-wide dark mode theme for context menus (and other controls)
- [ ] [macOS] https://github.com/tauri-apps/tao/commit/5eb2124e706b57f236a42503d530f9671cd0a2cf - applicationSupportsSecureRestorableState
- [ ] [Windows] https://github.com/tauri-apps/tao/commit/c0278d83f93d8ee18d1e9eeee88e71d84c12357a - Remove
WS_CLIPCHILDREN
- https://github.com/rust-windowing/winit/pull/3212 - [ ] [macOS] https://github.com/tauri-apps/tao/commit/f7e4991c665f6cd1b5217dcfeaa9689c230447b1 - Inset macos traffic light
There is no clipboard
implementations in winit.
There is no global-shortcut
implementations in winit, too.
clipboard will be replaced with arboard
and globalShortcut
will be replaced with DeviceEvents
clipboard will be replaced with
arboard
andglobalShortcut
will be replaced withDeviceEvent
Happy to hear that and is there any plan to merge tao
to winit
?
That's the idea Amr and Yu-Wei are creating PRs at winit non-stop to get stuff we need implemented in winit so that we hopefully can switch at some point.
clipboard will be replaced with
arboard
andglobalShortcut
will be replaced withDeviceEvents
I'm testing DeviceEvents
on Windows as compared to a native implementation using RegisterHotKey
as is performed by tao and sadly the results with DeviceEvents
are inferior for the following reasons:
-
DeviceEvents
seems to only send an event when a key is released, not when a key is pressed - Even when releasing the key as fast as I can, I see at least a 50ms difference between seeing the event registered with
RegisterHotKey
which is noticable in use -
DeviceEvents
doesn't take over the original shortcut likeRegisterHotKey
does; for example if I bind Volume Up withRegisterHotKey
, I will no longer see the original volume slider as my app completely overrides it, withDeviceEvents
the original action from the OS is still performed in addition to our own - Setting the
device_event_filter
toDeviceEventFilter::Never
will now also process all other device events including any keybord presses and mouse movements which is much less efficient than capturing a particular set of hotkeys
Perhaps it may be worth evaluating these differences on Windows and reconsidering this?
Cheers Fotis
DeviceEvents
seems to only send an event when a key is released, not when a key is pressed- Even when releasing the key as fast as I can, I see at least a 50ms difference between seeing the event registered with
RegisterHotKey
which is noticable in use
There is two separate events, Pressed
and Released
, I can see both so please double-check that otherwise it is a bug.
DeviceEvents
doesn't take over the original shortcut likeRegisterHotKey
does; for example if I bind Volume Up withRegisterHotKey
, I will no longer see the original volume slider as my app completely overrides it, withDeviceEvents
the original action from the OS is still performed in addition to our own
I am aware of that, and I think it is a fair trade off for the flexibility of device events
- Setting the
device_event_filter
toDeviceEventFilter::Never
will now also process all other device events including any keybord presses and mouse movements which is much less efficient than capturing a particular set of hotkeys
That is true and might be a good reason to stick with the current implementation especially since handling these events resulted in a slower webview rendering in WRY.
Perhaps it may be worth evaluating these differences on Windows and reconsidering this?
Nothing is set in stone yet so thanks for your feedback.
DeviceEvents
seems to only send an event when a key is released, not when a key is pressed- Even when releasing the key as fast as I can, I see at least a 50ms difference between seeing the event registered with
RegisterHotKey
which is noticable in useThere is two separate events,
Pressed
andReleased
, I can see both so please double-check that otherwise it is a bug.
Ah I didn't realise this was a bug and I do see that it was fixed on a slightly newer revision than I'm using so this is likely due to an older version of winit on my end 😄
DeviceEvents
doesn't take over the original shortcut likeRegisterHotKey
does; for example if I bind Volume Up withRegisterHotKey
, I will no longer see the original volume slider as my app completely overrides it, withDeviceEvents
the original action from the OS is still performed in addition to our ownI am aware of that, and I think it is a fair trade off for the flexibility of device events
Totally understand. I think there are use cases for both. For example, I'm building a volume control app which needs to take over the volume keys. However in most cases, this won't be needed.
Appreciate the reply Fotis
Linux platform's WindowEvent::ModifiersChanged(state)
in inconsistent with winit.
winit maintains the ModifiersState for me.
for tao I have to maintain the state my self with some hacky code like this
...(&mut self, state: ModifiersState) {
if state.is_empty() {
self.modifiers = state;
} else if state.shift_key() {
self.modifiers.set(ModifiersState::SHIFT, state.shift_key());
} else if state.control_key() {
self.modifiers
.set(ModifiersState::CONTROL, state.control_key());
} else if state.alt_key() {
self.modifiers.set(ModifiersState::ALT, state.alt_key());
} else if state.super_key() {
self.modifiers.set(ModifiersState::SUPER, state.super_key());
}
log::trace!("modifer changed {:?}", self.modifiers);
}```
our current key handling was just a merge of new-keyboard branch from winit which winit plans to roll out soon in https://github.com/rust-windowing/winit/pull/2662
Amr Bashir @.***> writes:
our current key handling was just a merge of new-keyboard branch from winit which winit plans to roll out soon in https://github.com/rust-windowing/winit/pull/2662
Good to know. Thanks.