This reverts commit 8afeb910bd.
Reverting because this change made Pinyin input unusable
(only latin characters showed even after selecting the
desired Chinese character)
* In MacOS, only disable menu bar in exclusive fullscreen
* Save and restore fullscreen options in set_fullscreen
* Don't always cache presentation options when entering exclusive fullscreen
This commit caches presentation options when entering exclusive fullscreen
only if we're coming from borderless fullscreen.
Then, when transitioning from exclusive -> borderless, if no cached presentation
options are present, then the default borderless options are applied.
This fixes the menu bar being unavailable when taking the following path:
[not fullscreen] -> [exclusive fullscreen] -> [borderless fullscreen].
Without this commit, the presentation options from [not fullscreen] were being
cached and then applied to [borderless fullscreen].
* Restore the window level when switching to exclusive fullscreen
The hack of using `CGShieldingWindowLevel() + 1` in borderless fullscreen needs
to be undone when switching from [borderless] -> [exclusive] fullscreen,
otherwise there are menu bar glitches when following a path through
[borderless] -> [exclusive] -> [borderless] modes.
Now, this might appear to conflict with the 'always on top' feature which uses
the 'floating window' level, but this feature appears to be broken anyway when
entering and exiting fullscreen with an always-on-top window. So, rather than
introducing logic to attempt to restore to the 'floating' level here, I think
it's better to do the simple thing for now and then introduce logic for
always-on-top windows when fixing the overall fullscreen behaviour.
* Update the changelog
Co-authored-by: Ehden Sinai <ehdens@gmail.com>
Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com>
* macOS: Ignore all events while in the callback
Previously all native dialogs, such as [rfd](https://github.com/PolyMeilex/rfd), would cause the event loop (event_loop.run) to freeze.
* Update changelog
* spelling
* Fix merge mistake
* Add link to issue in the code
Co-authored-by: Poly <marynczak.bartlomiej@gmail.com>
While winit was always using dlopen for opening system libs, it
provides a way now to disable dlopen feature helping with linking
on some targets.
Fixes#2037.
Some video drivers could set display metrics to odd values, which can result in
extra large scale factors (e.g. winit is sending 720 for 5k screen on nvidia
binary drivers), so let's just drop them to prevent clients from using them.
The value 20 was picked, because the DPR for 8k @ 5 inch is ~18.36.
Fixes#1983.
When disconnect the only monitor, scale factor is reset to 1.0. We need
to set it back when the monitor is reconnected.
We previously assume current window must be on an existing monitor, but
that's not true in case of reconnecting the only one monitor.
This commit also drops 'Theme' trait with its support types
in favor of 'FallbackFrame' meaning that winit will use some
predefined frame for the time being, since porting 'ConceptFrame'
will require adding font rendering librarires right into winit,
which is not desired.
Fixes#1889.
Fixes#1488.
`is_key_down` was only set to true when `insertText` was called.
Therefore `is_key_down` was actually meant to store whether the most
recently pressed key generated an `insertText` event, at which, winit
produces a `ReceivedCharacter`. The issue is that `insertText` is *not*
called for "key repeat", but winit wants to send `ReceivedCharacter`
events for "key repeat" too. To solve this, the `is_key_down` variable
was then checked in the `key_down` function to determine whether it was
valid to produce repeated `ReceivedCharacter` events during "key
repeat". However this check is not needed since `ReceivedCharacter` must
always be called if the key event has a non-empty `characters` property.
Furthermore `is_key_down` didn't actually store whether the previously
pressed character had an `insertText` event, because it was incorrectly
set to false on every "key up". This meant that if two keys were pressed
consecutively and then the first was released, then `is_key_down` was
set to false even if the most recent keypress did actually produce an
`insertText`.
Update changelog.
* Drop the event callback before exiting
* Update the changelog
* Apply suggestion from review
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Apply review suggestions
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Remove support for `stdweb`
* Expunge `stdweb`; make `web-sys` the default
* Mark this change as a breaking change
* Re-insert accidental removal of space
* Use the correct cargo feature syntax
* Re-add some `cfg` attributes
* Remove `web-sys` feature from CI
* Require setting the activation policy on the event loop
* Run cargo fmt
* Update changelog
* Fixes and tweaks from review
* Correct comment in app_state.rs
Co-authored-by: Mads Marquart <mads@marquart.dk>
* MacOS: Only activate after the application has finished launching
This fixes the main menu not responding until you refocus, at least from what I can tell - though we might have to do something similar to https://github.com/linebender/druid/pull/994 to fix it fully?
* MacOS: Remove activation hack
* Stop unnecessarily calling `makeKeyWindow` on initially hidden windows
You can't make hidden windows the key window
* Add new, simpler activation hack
For activating multiple windows created before the application finished launching
* feat: added MacOS menu
* fix: ran fmt
* extracted function into variable
* idiomatic formatting
* Set the default menu only during app startup
* Don't set the activation policy in the menu init
Co-authored-by: Artur Kovacs <kovacs.artur.barnabas@gmail.com>
This is called internally by NSApplication.run, and is not something we should call - I couldn't find the reasoning behind this being there in the first place, git blame reveals c38110cac from 2014, so probably a piece of legacy code.
Removing this fixes creating new windows when you have assigned a main menu to the application.
We allow to have RunLoop running only on the main thread. Which means if
we call Window::request_redraw() from other the thread then we have to
wait until some other event arrives on the main thread. That situation
is even worse when we have ControlFlow set to the `Wait` mode then user
will not ever render anything.
* Fix for #1850
* Update changelog
* Fix for compilation warnings
* Apply suggestions from code review
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Improve code quality
* Change Arc<Mutex> to Rc<RefCell>
* Panicking in the user callback is now well defined
* Address feedback
* Fix nightly warning
* The panic info is now not a global.
* Apply suggestions from code review
Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com>
* Address feedback
Co-authored-by: Markus Røyset <maroider@protonmail.com>
Co-authored-by: Francesca Lovebloom <francesca@brainiumstudios.com>
