-
Notifications
You must be signed in to change notification settings - Fork 920
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Window attribute #4039
base: master
Are you sure you want to change the base?
Window attribute #4039
Conversation
Mehrbod2002
commented
Dec 13, 2024
- Add window attribute to retrieve because of custom handlers in our system and frameworks .
Just in case, so the correct changelog will be rendered when pulling the crate from the crates.io as archive and trying to build it.
Signed-off-by: growfrow <growfrow@outlook.com>
…ust-windowing#3657) Setting the background color changes how the window title bar appears, which is something that the application should customize itself if it wants this behaviour (and also, it wasn't set when calling `set_transparent`, so the behaviour wasn't consistent).
…ing#3597) - Allow all gestures simultaneously recognized. - Add PanGestureRecogniser with min/max number of touches. - Fix sending delta values relative to Update instead to match macOS. - Fix rotation gesture units from iOS to be in degrees instead of radians. Co-authored-by: Mads Marquart <mads@marquart.dk>
The delegate is only weakly referenced by NSApplication, so getting it from there may fail if the event loop has been dropped. Fixes rust-windowing#3668.
When the user decides to use an older version of raw-window-handle, through the rwh_04 or rwh_05 features, it makes sense to reexport the crate so they don’t have to depend on it manually and can instead use winit::raw_window_handle.
On Raspberry Pi, using the Rust crate eframe caused the program to crash on mouse movement. The Backtrace lead to this specific line of code, and the exact error was a "misaligned pointer dereference: address must be a multiple of 0x8 but is xxxx" The edit has been tested with the Raspberry Pi, which works now.
This correctly handles recent nightly lint that requires to explicitly define the CFG guards.
This fixes an issue where the window glitched due to resize when the user doesn't actually change the window, but macOS function to update window size was still called.
…st-windowing#3619) Co-authored-by: Mads Marquart <mads@marquart.dk>
* Use AppKit's internal queuing mechanisms This allows events to be queued in a more consistent order, they're now interleaved with events that we handle immediately (like redraw events), instead of being handled afterwards. * Only queue events if necessary This makes the call stack / backtraces easier to understand whenever possible, and generally improves upon the order in which events are delivered.
…3720) I'm preparing to get rid of our application delegate in favour of registering notification observers, to do so I'm renaming `app_delegate.rs` to `app_state.rs`, and moving the functionality out of the Objective-C method into a normal method. Additionally, `AppState` previously implemented `Default`, but really, this was a hack done because someone (probably myself) was too lazy to write out the full initialization in `AppDelegate::new`.
Signed-off-by: John Nunley <dev@notgull.net>
Not using `NSColor::clearColor()` results in Quartz thinking that the window is not transparent at all, which results in artifacts. However, not setting the `windowBackgroundColor` in `Window::set_transparent` results in border not properly rendered. Fixes: 94664ff (Don't set the background color)
This is a breaking change, thus revert it for patch series.
Update SCTK as a follow-up to 1170554 (ignore events to dead objects) fixing it for wl_output.
`clippy::doc_lazy_continuation` was added, which needed some fixing from our side.
This type comes from the user and stored for the entire lifetime, so no need to hide it from them after they've passed it to winit. Fixes rust-windowing#3818.
This was detected by a new change in Nightly Rust that applied `#[must_use]` to the return value of `Box::into_raw()`.
Prevent assertion error when trying to close a fullscreen window that was on a display that got disconnected.
This also fixes macOS returning `None` in `Window::theme()` if no theme override is set, instead it now returns the system theme. MacOS and Wayland were the only ones working correctly according to the documentation, which was an oversight. The documentation was "fixed" now. Fixes rust-windowing#3837.
It has low amount of users and not active, so better direct people straight to matrix at this point.
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! You seem to have based this on the v0.30.x
branch, could you rebase on top of master
?
Apart from that, I'm not sure I want to accept this, at least not without a clearer use-case description? The attributes are not being kept up to date with the state in the Window, so it seems mostly useless?
As an example I am going to use it in dixous in customized way to use winit instead gtk . So to use in custom event handler and when user want to use method like with_window and transfer to between platforms . I got response from this merge and satisfied and do it in this version because of rwh_06 which is needed too . |
Could you show a piece of example code for how you'd use it?
|
@madsmtm |
I'm sorry, that issue doesn't really explain anything to me? How is it linked with the feature your implementing here? And why does Dioxus need the pub struct DioxusWindow {
pub window: winit::window::Window,
pub attributes: winit::window::WindowAttributes,
} |
It's so clear . we need window attributes for creating window and need to be use raw window and display in platforms . don't store in struct in dioxus because some method not defined to retrieve . for example how to retrieve blur or transparent ?. If not reasonable please close this PR . |
But why do you need the same attributes as what you created the first window with? Can you not use
That's true, we don't have a way to retrieve those - but that isn't solved by this PR either? I'd be happy accepting a PR that added getters
I'm inclined to, but honestly mostly because I have a hard time understanding you (apologies!). I'm not sure what to do about that, maybe try to put your thoughts into more words? |