Tracking issue for different implementation between winit

[wusyong]

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.

• [ALL] system tray - tauri-apps/tray-icon
• [ALL] menus - tauri-apps/muda
• [ALL] global-hotkey - tauri-apps/global-hotkey
• [Windows] Transparent Windows don't work unless we draw to the window surface Transparent example not working rust-windowing/winit#2502, use softbuffer to clear the window surface
• [macOS] 1359fcc - Default cursor will not set to arrow cursor only
• [ALL] c0d5a53 - monitor_from_point REJECTED: use available_monitors() and compare bounds with the point.
• [ALL] 5d8bf51 - cursor_position - Add cursor_position getter API rust-windowing/winit#2648
• [macOS] 045b768 - call nextResponder in key_down
• [iOS] 651137c - iOS proxy Send
• [Windows] 62db431 - focus hack
• [Windows] c5d606d - auto-hide taskbar with maximized undecorated window
• [macOS] 8132901 - fix the unexpected shifting of the window when dragging after closing the share dialog
• [ALL] 3b7e0d9 & baa0297 - progress bar support
• [ALL] ea14c6b - split min and max sizes
• [iOS] 8f361f0 - Universal links
• [macOS] 093d8fb - openURL, openFile, openFiles
• [Windows] 4d0e186 - RTL
• [ALL] baa0297 3b7e0d9 - Progress Bars
• [Windows] 6df56c2 fce9d26 29b01bf - app-wide dark mode theme for context menus (and other controls)
• [macOS] 5eb2124 - applicationSupportsSecureRestorableState
• [Windows] c0278d8 - Remove WS_CLIPCHILDREN - Add option to enable/disable WS_CLIPCHILDREN window style rust-windowing/winit#3212
• [macOS] f7e4991 - Inset macos traffic light

[luffyfly]

There is no clipboard implementations in winit.

[luffyfly]

There is no global-shortcut implementations in winit, too.

[amrbashir]

clipboard will be replaced with arboard and globalShortcut will be replaced with DeviceEvents

[luffyfly]

clipboard will be replaced with arboard and globalShortcut will be replaced with DeviceEvent

Happy to hear that and is there any plan to merge tao to winit?

[FabianLars]

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.

[fgimian]

clipboard will be replaced with arboard and globalShortcut will be replaced with DeviceEvents

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 like RegisterHotKey does; for example if I bind Volume Up with RegisterHotKey, I will no longer see the original volume slider as my app completely overrides it, with DeviceEvents the original action from the OS is still performed in addition to our own
• Setting the device_event_filter to DeviceEventFilter::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

[amrbashir]

• 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 like RegisterHotKey does; for example if I bind Volume Up with RegisterHotKey, I will no longer see the original volume slider as my app completely overrides it, with DeviceEvents 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 to DeviceEventFilter::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.

[fgimian]

• 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.

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 like RegisterHotKey does; for example if I bind Volume Up with RegisterHotKey, I will no longer see the original volume slider as my app completely overrides it, with DeviceEvents 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

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

[declantsien]

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);
    }```

[amrbashir]

our current key handling was just a merge of new-keyboard branch from winit which winit plans to roll out soon in rust-windowing/winit#2662

[declantsien]

Amr Bashir ***@***.***> writes:

our current key handling was just a merge of [new-keyboard](https://github.com/rust-windowing/winit/tree/new-keyboard) branch from winit which winit plans to roll out soon in rust-windowing/winit#2662

Good to know. Thanks.