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.
* Fix X11 memory leak and remove mio-misc
I also fixed a couple of clippy lints.
Fixes#1984
* Send the redraw event before waking up the main event
* Use .map instead of a match, and remove comments saved by git
* Remove unnecessary pub keywords on `WakeSender` in x11/mod.rs
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.
The inability to set the cursor using any of the named cursor files
likely indicates an error in the system on which we are running.
'WinitPointer::set_cursor' also does not have any way of returning an
error so just log the error to assist users in diagnosing the problem.
Fixes: #1988.
* Adds Android winit<->ndk_glue version match table
* Fixes justification
* Adds crosses
* Address review and instead of a m:n table it shows a 1:1 version compatibility
* Addresses review
* Enable to show text when IME is active
* Remove unnecessary variable
* Enable to use IME
* fmt
* Remove println! for debug
* Fix handling of utf-8 string
* clear_marked_text should be rust function, not member function
* Store state information in ViewState
* Remove unnecessary function
* format
* Remove mut
* format
* Remove duplicate marked text
* Remove unused `is_preediting` field
Co-authored-by: Artúr Kovács <kovacs.artur.barnabas@gmail.com>
* Remove window subclassing
* Always call `DefWindowProcW` when we don't process a message
* Improve window initialization
Note that the error path in `init` is kind of cursed at the moment.
* Rename `ThreadMsgTargetCallbackData` to `ThreadMsgTargetData`
* Simplify window initialization
* Fix compilation on 32-bit targets
* Simplify the creation of the event target window
* Use `.clone()` rather than `Rc::clone()`
* Use concrete types for args to `SetWindowLongPtrW`
On 32-bit targets, `SetWindowLongPtrW` is an alias to `SetWindowLongW`,
which returns `LONG` (`i32`) rather than `LONG_PTR` (`isisze`).
* Minor comment adjustments
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.
* changed description of window scale factor in Events
* Update src/dpi.rs
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* Fix intra-doc link
Co-authored-by: Markus Røyset <maroider@protonmail.com>
* 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.
