linebender / glazier Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
I think that sometimes we are returning measurements in device points when we should be using physical pixels, and vice versa. winit use some newtype wrappers to make the two types of measurement distinct in the type system. Whether we copy this or not, we should audit the places that take or return measurements to make sure they are using the right units.
As a specific example, I think WindowHandle::get_size
is returning physical pixels when the docs say device points.
This is due to a stubbed-out implementation for RawWindowHandle
.
Druid never settled on a clear Linux strategy. At first there was only the GTK backend due to the simplicity of implementation.
Then there were experimental backends for X11 and Wayland. Bringing the total to three. No clear focus, lots of effort spread thin.
There were several attempts to reach some sort of clarity on how to reduce the scope, but unfortunately no decisions made.
Complexity kills. Lack of focus kills. The scope of Glazier is already enormous with targeting Windows, macOS, web (sort of), and tentative plans for both Android and iOS. Having multiple backends for Linux doesn't seem like well spent resources. Yes there are occasional champions who contribute to specific backends, but for the general success of Glazier new features should work well on all platforms and receive proper maintenance. Far fewer volunteer for such ongoing work. Also, speaking as someone who tests all the Glazier platforms, I would love to spend less time on all the various Linux quirks.
I think it would serve us well to reduce scope and increase focus.
With that in mind, I went through the historic Druid discussion threads and also did a bit of digging across the Linux ecosystem landscape to see how things are today and how things are likely to be in a few years.
The first question is whether we should drop GTK or embrace it.
If we embrace GTK, then it would be rather straightforward to drop support for both X11 and Wayland native backends.
However if we drop GTK then we're still left with both X11 and Wayland. Still double the number of backends per platform compared to other platforms. Thus I think in the case where we drop GTK we should also seriously consider dropping X11 and focus solely on Wayland.
With such a decision tree in mind, I'll present various points regarding each of the backends.
GTK has already solved a lot of issues that we'll need to redo.
We've already implemented a lot of the GTK integration.
Probably the fastest path, in dev time, to a stable Linux backend.
Most attractive when the alternative is to keep both Wayland and X11 as opposed to only Wayland.
As GTK 4 will provide both X11 and Wayland support for us, while being only a single backend for Glazier.
There is some uncertainty around how well the Glazier model with Vello can even work with GTK.
There are various claims that it can be done, but at the moment nobody has actually spent the time to do it.
People have complained about the GTK compile times for years. Most recently in #101.
Some historic Druid tests showed it almost an order of magnitude slower than Windows.
People have also complained about app startup time.
Significantly reduces our dependency graph. A lot of it written in C. Results in faster compile times and potentially fewer security bugs.
Gives us a higher degree of control.
We're still on GTK 3 and should probably migrate to GTK 4. Removing the GTK backend skips that work.
Support for running on systems that don't have GTK installed. Admittedly not too many of those, but the dependency is huge.
Clearly the future. Various major Linux ecosystem projects are overwhelmingly in agreement.
The differences in thought come from the assessment of progress towards it.
However the progress is towards it.
We already need to do a large amount of work on our Wayland backend.
It would be a lot easier to justify this focus if this was essentially synonymous with Linux support.
Removal only makes sense if we focus on GTK instead.
We've already done a good chunk of the work.
Ability to run on setups that are either running old distributions or are custom configured to run X11.
There isn't a lot of statistics available on display server usage, but we have a tiny bit - sample size 5500 across distributions.
Keep in mind that the kind of person that would seek out self reporting like this is also more likely to change their defaults.
So reality is probably skewed more towards distribution defaults. That said, I'll link three Wayland usage charts.
The trend is aggressively towards Wayland. Wayland has been available for a long time, but adoption has really accelerated in just the last few years. All signs point towards the acceleration only growing. However it is an open question how long the last 10% will hold out.
X11 is increasingly abandoned.
It still works but is missing support for modern features and that list will only grow.
Legacy quirks are guaranteed to remain.
Significantly reduces our maintenance burden of the Linux platform.
Reduces our dependency graph even more.
App developer experience improves drastically if Linux is just one backend,
because otherwise the app code needs to perform runtime checks on X11 vs Wayland guarded by a Linux cfg attribute.
X11 has no support for wide color gamuts or HDR and there are no plans either.
Wayland doesn't have real support either, but there is serious ongoing work.
For us to support these modern features X11 would at a minimum be a heavily degraded experience.
GTK team considered removing the X11 backend from GTK for the future GTK 5 release.
Their current plan is to stop building the X11 backend by default in GTK 5,
but they also aren't rushing to delete the code .. at least until the next major refactor.
In general, the vibe I get from the GTK team is that they don't want to spend any more resources on X11 support.
Qt 6 docs state:
In fact, it is difficult to run a client fluidly with X11, and reach 60 fps without tearing.
Wayland, in contrast, is easier to implement, has better performance,
and contains all the necessary parts to run efficiently on modern graphics hardware.
Running fluidly at 60 fps, or indeed 144 fps, is one of the core goals of the Linebender stack.
If both GTK and Qt, the two biggest Linux GUI toolkits, are convinced that Wayland is the superior future,
then why would we, with less resources, invest in X11 support for our toolkit that won't even be ready for years.
Opportunity for Glazier to help shape the future of Linux desktop.
Yes Wayland has issues. If the path of least resistance is to just go back to X11, then Wayland issues remain.
If switching back to X11 isn't easy, then the path of least resistance becomes to fix the Wayland issues.
Instead of helping keep the fragmentation the way it is, we could be championing for the shift.
In the bigger Linebender picture we're already building for the future by targeting compute shaders and WebGPU.
It seems to fit thematically that we'll also focus on the latest display server.
Although I guess you could make the case that supporting X11 is similar to having a CPU fallback in Vello.
GNOME has defaulted to Wayland since ca Fedora 25.
The KDE team is pushing for Wayland by default in the upcoming Plasma 6 release.
(Estimated release date Q1 2024)
Fedora has defaulted to Wayland with Plasma since Fedora 34, and with GNOME since Fedora 25.
The Fedora team is pushing to take it even further and have the Fedora Plasma 6 ship without X11.
Red Hat Enterprise Linux 9 deprecated X11, defaults to Wayland. X11 planned for removal in RHEL 10.
Ubuntu has defaulted to Wayland since Ubuntu 21.04.
Debian has defaulted to Wayland with GNOME since Debian 10.
Glazier 1.0 isn't likely for another few years.
While large Linux distributions are looking to remove as much X11 code as they can,
should we be looking to write new X11 code for 2025 and beyond? Seems like swimming against the current.
It is better to cut scope and increase focus.
Deliver a single Wayland backend that is excellent, instead of two backends that are merely good.
Given that the primary issue with having three Linux backends is the amount of work required, I especially want to encourage people to respond here if they have even tentative plans to contribute work towards specific backends.
In general, if anyone has more reasons to add or want to amplify one of the above reasons on why we should go with any of these options, please share your thoughts.
In the process of unpiet, the Wayland backend needs some work under the hood as well. Since the backend is relatively immature, I'd recommend a rewrite of the Wayland backend while we are in progress with unpiet.
I may contribute some bits here and there in the future, but I am quite busy so I'll lay out the future ideal state of the Wayland backend:
A few implementation notes that would be useful:
And some implementation advice for fulling the scope of glazier:
wl_keyboard
, possibly some seat related stuffzwp_input_method_v1
protocoltablet-unstable-v2
protocol for drawing tablets.wl_pointer
.wl_data_device
The general philosophy is that a task is in scope if it requires deep integration with the platform and is not easy to separate out as a separate library that layers on top of Glazier.
A few things worth discussion here include:
idle-inhibit
protocol)There are some less clear, but nice things we could support that are more Wayland specific:
In the shello example, the window that opens takes up the whole screen and "looks transparent" (which might just be kwin not painting anything, rather than painting full transparency). The window still receives clicks and keyboard events. render()
never gets called.
Currently glazier allows the title bar to be disabled but this also disables the OS native buttons for closing and resizing (and macOS and windows stop treating them as main application windows).
This is fine but it would be nice to be able to configure a the window to have a full content view but still keep the OS native buttons and title_bar.
On macOS this can be done by adding NSWindowStyleMask::NSFullSizeContentViewWindowMask
to the style_mask
here
and by setting the window.setTitlebarAppearsTransparent_
with true.
I could open a PR for this but I wasn't sure how to name these items and also how to ensure consistency with windows / linux.
Symptom: the shello
example runs fine, but hangs on exit.
Apparent cause: the X11 backend destroys a window before user state (handler
) gets destroyed. This is potentially a problem because that user state may include stuff which depends on the window. At least, I appear to be hitting this issue:
So to fix this, naively, we need to destroy the RenderSurface
before the window, like this:
impl WindowState {
// ...
fn destroy(&mut self) {
drop(self.surface.take());
Application::global().quit()
}
}
... but there are two problems here:
Surface
is the only part which is window-specific)The alternative would be to keep the X11 window alive until after user state (handler
) has been destroyed. This can't simply be done from backend::x11::window::Window::destroy
since self.handler
is borrowed when this method is called so further redesign would be needed (e.g. ensure the user state is destroyed immediately after handle_destroy_notify
is called).
There is a further complication in that user state may hold a copy of a WindowHandle
, which contains a Weak
reference to the window object. I wonder whether further design changes are sensible:
handle: &WindowHandle
into all methods of WinHandler
, remove Clone
implApplication::clipboard
returns a temporary (non-Clone) object Clipboard<'_>
I best-guess-ported over CI from druid
, so someone should have a look at it once over in order to remove any tests that are unnecessary for glazier
.
glazier's dependency on piet-gpu-hal refers to the dev branch of the piet-gpu repo, which apparently no longer exists, so I can't build from a fresh checkout of glazier.
Right now, the Application
structure exposes a run()
method that blocks indefinitely until the application finishes. It would be nice if there were a way to run a Future
inside of this blocking loop, so that it would be possible to multiplex an asynchronous task with the GUI on one thread.
This would require changing the backend such that it can be woken up via a Waker
. While you could just create a Waker
to send an event to the loop, there is a more elegant way of doing this that can circumvent the normal event loops, based on the platform.
MsgWaitForMultipleObjects
.epoll
.kqueue
.I'm willing to implement this behavior into the current system.
@maan2003 is this something you can do and test out?
The Rust convention for getters and setters is to not have a get_
prefix on the getter. We should follow this convention to make the API more familiar to newcomers.
This does work in Firefox, but not in our Wayland backend. It's not clear if we need to implement an additional API for this. Naรฏvely, I'd expect this to be based on the text input protocol, but I believe we implement this correctly.
Based on alacritty/alacritty#6644, it appears that this should work. However, a test of the latest Alacritty release at the time of writing:
fsh โฏ alacritty --version
alacritty 0.12.2
doesn't support the on-screen keyboard on my machine.
Testing also using Konsole and Kwrite (KDE's QT based terminal emulator and text editor) also shows the on-screen keyboard not working. This suggests that the on-screen keyboard uses some GTK specific API, so unless we can find where this is documented, I don't believe we can fix this.
See also microsoft/vscode#81962.
The Alacritty issue does bring up an additional feature we need to implement - namely zwp_text_input_v3::set_content_type. Winit uses a simple API for this - we should instead have this be part of the input lock, but we need to make similar choices about a set of options.
Using MobaXter or vcxsrv as X server on a Win10.
Run some examples from Ubuntu 22.04, the window is balck at all.
:~/proj/rust/glazier$ cargo r --example wgpu-triangle
Finished dev [unoptimized + debuginfo] target(s) in 0.19s
Running `target/debug/examples/wgpu-triangle`
[src/backend/x11/application.rs:673] ev = MapNotify(
MapNotifyEvent {
response_type: 19,
sequence: 197,
event: 2097154,
window: 2097154,
override_redirect: false,
},
)
[src/backend/x11/application.rs:673] ev = ReparentNotify(
ReparentNotifyEvent {
response_type: 149,
sequence: 198,
event: 2097154,
window: 2097154,
parent: 197,
x: 138,
y: 161,
override_redirect: true,
},
)
To reproduce on macos:
wgpu-triangle
Haven't yet investigated what causes this
The winapi crate hasn't been updated in over a year and has been deprecated by windows-rs which are the official rust bindings to the windows api.
I think it would be better to switch sooner rather than later.
One consideration would be whether to use the windows
or windows-sys
crate.
See:
glazier/src/backend/mac/window.rs
Line 177 in 38b212a
glazier/src/backend/mac/window.rs
Line 1099 in 38b212a
TimTom on Zulip points out that the official spec doesn't say Left/Right because some users swap their primary mouse button; we should probably change these variant names to match the spec.
Used to come in from piet_common:
And was part of the Application
struct:
We have:
Lines 773 to 779 in 618382a
However, we don't report when the actual application is closing. This is most useful on macOS, as in other desktop environments (generally) the application is finished when the final window is closed1.
But for consistency, we should have the same API across all backends. This could be used for saving states, for example.
This would be slightly earlier than AppHandler::drop
- the event loop might still be running at this point (?)
An implementation for macOS exists in 86f0494 (from lapce's fork)
An implementation note:
This should not be called upon calling Application::quit, for consistency with the Window methods.
AppHandler::drop
could possibly be used in that case?
CC @waywardmonkeys, as discussed in Zulip.
Customising this behaviour could make sense - e.g. for close to tray on Windows (and Linux in theory, except that there's no tray) โฉ
I can't tell if that's deliberate. I assume it isn't.
I think cargo build --features="gtk"
works fine, but then I end up depending on the x11 backed even though I don't use it.
Does the port of bloat.yml
work? The world wonders.
Druid has the following data structure.
pub struct WindowConfig {
pub(crate) size_policy: WindowSizePolicy,
pub(crate) size: Option<Size>,
pub(crate) min_size: Option<Size>,
pub(crate) position: Option<Point>,
pub(crate) resizable: Option<bool>,
pub(crate) transparent: Option<bool>,
pub(crate) show_titlebar: Option<bool>,
pub(crate) level: Option<WindowLevel>,
pub(crate) state: Option<WindowState>,
}
That struct is directly tied to WindowBuilder
. Eg it has an apply_to_builder
method:
/// Apply this window configuration to the given WindowBuilder
pub fn apply_to_builder(&self, builder: &mut WindowBuilder) {
if let Some(resizable) = self.resizable {
builder.resizable(resizable);
}
if let Some(show_titlebar) = self.show_titlebar {
builder.show_titlebar(show_titlebar);
}
if let Some(size) = self.size {
builder.set_size(size);
} else if let WindowSizePolicy::Content = self.size_policy {
builder.set_size(Size::new(0., 0.));
}
if let Some(position) = self.position {
builder.set_position(position);
}
if let Some(transparent) = self.transparent {
builder.set_transparent(transparent);
}
if let Some(level) = &self.level {
builder.set_level(level.clone())
}
if let Some(state) = self.state {
builder.set_window_state(state);
}
if let Some(min_size) = self.min_size {
builder.set_min_size(min_size);
}
}
Almost every method of WindowBuilder has a matching field in WindowConfig. So I think it would make sense to move WindowConfig to glazier directly. (And it would remove redundant interfaces from druid / masonry).
Branched from linebender/xilem#1. The quit menu item is not enabled on mac, and quitting also doesn't work on Linux. I haven't investigated deeply, but the code to create the menu seems ok (it's the same as the druid-shell version).
Writing down this idea just so I don't forget: one thing I've noticed is most implementations of WinHandler
end up containing a ton of Option
s, which only get filled in after connect()
is called. If we changed set_handler
to take a FnOnce(&WindowHandle) -> WinHandler
as an argument instead of an explicit WinHandler
, perhaps we could handle some complexity for the user? (Although the user must be careful to not call any methods of the WindowHandle during initialization that would require the WinHandler to exist.)
In Glazier there is a counter struct that wraps an atomic number and provides unique IDs. There is a method on it that returns a NonZeroU*, and if the inner number overflows then it will get initialized with zero, which is UB. I don't think the doc comment is sufficient here, unless we mark the methods on the Counter
as unsafe
. Alternatively we should acquare exclusive access while we check that the number is not u*::MAX before we increment it and get our ID. This will lead to a little more contention, but the alternative is UB.
I'll be implementing this, building on my previous work on druid-shell.
Question: Is it OK to open a PR for this when it's only implemented on Windows? The first stage of the AccessKit macOS adapter is close to being merged. I'm not sure how soon the Linux (AT-SPI) adapter will be merged, and we don't yet have any support for the web platform.
We need to divide by DPI in the returned text bounding box
Self-explanatory. Implementation could be roughly:
match &self {
WindowLevel::AppWindow => "AppWindow",
WindowLevel::Tooltip(_) => "ToolTip",
WindowLevel::DropDown(_) => "DropDown",
WindowLevel::Modal(_) => "Modal",
}
and skip the AppHandle values, since it's hard to get meaningful debug info from them.
There's a panic in linebender/xilem#1 on window creation with the Wayland back-end. This probably has to do with the order of events on window creation being different. It certainly would be possible to fix this by making the xilem code more robust, but I think it's better to fix this at the glazier level, making the order of events more consistent from platform to platform, to reduce the burden on other potential clients.
Also see https://xi.zulipchat.com/#narrow/stream/351333-glazier/topic/Running.20callbacks.20when.20building.20windows.2E where this was discussed a bit.
I am working on silencing some clippy lints, which is pointing me to consider what is happening with regards to presentation strategy in druid-shell:
glazier/src/backend/windows/window.rs
Line 741 in 15306d1
compared to in unpiet
, where presentation strategy logic goes out the window:
glazier/src/backend/windows/window.rs
Line 689 in 03691e7
Tracing various threads back, I am lead to the blocker being create_dxgi_state
, particularly the creation of a D3D11Device
, as explained by Raph here.
Which leads me to wonder: does the presentation strategy logic also not belong in glazier
? That seems to clash with my understanding of the purpose of glazier, so I'm wondering if I can have some insight.
In #107, we've landed the beginnings of a new wayland backend. Here are some features which need to be implemented for it, and some hints for these. This all works towards #28.
Timer
to the calloop event loop, then removing it once the timer fires. Should be straightforward.paint
.damage
command ourselvesThese are other features which we need, but which require API changes across all backends:
AppHandler
.These are other features which we need, but which require API changes (only/primarily) to support wayland
"org.linebender.glazier.user_app"
. We need an API to set thisThe wl_surface.attach, wl_surface.damage, and wl_surface.commit requests must be issued by the implementation during the call to vkQueuePresentKHR and must not be issued by the implementation outside of vkQueuePresentKHR. - https://registry.khronos.org/vulkan/specs/1.1-extensions/html/vkspec.html#platformCreateSurface_wayland โฉ
If you resize the window, it doesn't repaint until some other trigger (e.g. mouse over a button).
Needs repro - I've only seen it on my machine so far. Might be an issue with my setup, might not.
It isn't always clear whether a size is in pixel or display points. Better documentation could help, but making use of the type system would be even better.
I think there are 2 ways of going about this. Using wrapper types
pub struct Physical<S: Scalable> {
pub pixels: S,
}
pub struct Logical<S: Scalable> {
pub points: S,
}
Or using an enum. This is how winit does it
pub enum Dip<S: Scalable> {
Pixels(S),
Points(S),
}
Currently, the Wayland backend code for mouse presses is roughly this:
self.clickevent.borrow_mut().debounce(MouseEvtKind::Down(
mouse::MouseEvent {
pos: self.pos.get(),
buttons: *self.buttons.borrow(),
mods: Modifiers::empty(),
count: 1,
focus: false,
button,
wheel_delta: Vec2::ZERO,
},
))
Notice that the click count is always one; this means double-clicks and triple-clicks aren't detected.
Application
is the global-equivalent of WindHandler
it should be called AppHandler
for a few reasons:
I've bumped into this problem when writing Masonry, and I think @maan2003 bumped into it as well last year: https://xi.zulipchat.com/#narrow/stream/147926-druid/topic/Remove.20Application.3A.3Aglobal/near/238902785
The AccessKit example fails to even build on Linux (with both Wayland & X11). We had to disable Linux testing of it in #111.
Run cargo build --features x11,accesskit --no-default-features --example accesskit
Downloading crates ...
Downloaded accesskit v0.11.0
Downloading crates ...
Downloaded accesskit_macos v0.7.1
Downloading crates ...
Downloaded accesskit_windows v0.14.0
Compiling glazier v0.7.0 (/home/runner/work/glazier/glazier)
Compiling accesskit v0.11.0
error[E0599]: no method named `update_accesskit_if_active` found for enum `backend::linux::window::WindowHandle` in the current scope
--> src/window.rs:436:16
|
436 | self.0.update_accesskit_if_active(update_factory)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ method not found in `WindowHandle`
|
::: src/backend/linux/window.rs:233:1
|
233 | pub(crate) enum WindowHandle {
| ---------------------------- method `update_accesskit_if_active` not found for this enum
|
note: the method `update_accesskit_if_active` exists on the type `x11::window::WindowHandle`
--> src/backend/x11/window.rs:1457:5
|
1457 | / pub fn update_accesskit_if_active(
145[8](https://github.com/linebender/glazier/actions/runs/5486073995/jobs/9995685149#step:8:9) | | &self,
145[9](https://github.com/linebender/glazier/actions/runs/5486073995/jobs/9995685149#step:8:10) | | _update_factory: impl FnOnce() -> accesskit::TreeUpdate,
1460 | | ) {
| |_____^
For more information about this error, try `rustc --explain E0599`.
error: could not compile `glazier` (lib) due to previous error
Error: Process completed with exit code [10](https://github.com/linebender/glazier/actions/runs/5486073995/jobs/9995685149#step:8:11)1.
Moving forward this should be resolved.
The example should at least build, even if that means an empty main function guarded by #[cfg]
.
Then we can have a unified CI that tests all examples on all platforms.
Is it feasible to ask to provide some kind of C API for working with Glazier, so it can be used in other languages?
This would be really helpful for using it in other languages, but I'm not sure how easy would this be.
I'm willing to potentially put time into this, given acceptance and proper guidance for this proposal.
After implementing druid-shell's WinHandler in masonry, I feel like some of the methods have unclear names and would benefit from a rename:
The pattern with most of these names is the same: the name implies that the method fetches information, when what it does it tell the implementor "some event happened, react to it".
Thoughts?
When playing around with Xilem, I found that event handlers are triggered twice. E.g. in the button example bin, the counter is incremened twice per click.
After some suggestions on Zulip, I cloned glazier and debug-printed all input events, and they are duplicated in the following form (one click):
XinputButtonPress(ButtonPressEvent { response_type: 35, extension: 131, sequence: 650, length: 22, event_type: 4, deviceid: 11, time: 309212286, detail: 1, root: 475, event: 142606366, child: 0, root_x: 36498396, root_y: 40442140, event_x: 33221596, event_y: 32643356, sourceid: 11, flags: 0, mods: ModifierInfo { base: 0, latched: 0, locked: 0, effective: 0 }, group: GroupInfo { base: 0, latched: 0, locked: 0, effective: 0 }, button_mask: [0, 0, 0, 0, 0, 0, 0, 0], valuator_mask: [0, 0], axisvalues: [] })
XinputButtonPress(ButtonPressEvent { response_type: 35, extension: 131, sequence: 650, length: 22, event_type: 4, deviceid: 2, time: 309212286, detail: 1, root: 475, event: 142606366, child: 0, root_x: 36498396, root_y: 40442140, event_x: 33221596, event_y: 32643356, sourceid: 11, flags: 0, mods: ModifierInfo { base: 0, latched: 0, locked: 0, effective: 0 }, group: GroupInfo { base: 0, latched: 0, locked: 0, effective: 0 }, button_mask: [0, 0, 0, 0, 0, 0, 0, 0], valuator_mask: [0, 0], axisvalues: [] })
XinputButtonRelease(ButtonPressEvent { response_type: 35, extension: 131, sequence: 650, length: 22, event_type: 5, deviceid: 11, time: 309212403, detail: 1, root: 475, event: 142606366, child: 0, root_x: 36498396, root_y: 40442140, event_x: 33221596, event_y: 32643356, sourceid: 11, flags: 0, mods: ModifierInfo { base: 0, latched: 0, locked: 0, effective: 0 }, group: GroupInfo { base: 0, latched: 0, locked: 0, effective: 0 }, button_mask: [2, 0, 0, 0, 0, 0, 0, 0], valuator_mask: [0, 0], axisvalues: [] })
XinputButtonRelease(ButtonPressEvent { response_type: 35, extension: 131, sequence: 650, length: 22, event_type: 5, deviceid: 2, time: 309212403, detail: 1, root: 475, event: 142606366, child: 0, root_x: 36498396, root_y: 40442140, event_x: 33221596, event_y: 32643356, sourceid: 11, flags: 0, mods: ModifierInfo { base: 0, latched: 0, locked: 0, effective: 0 }, group: GroupInfo { base: 0, latched: 0, locked: 0, effective: 0 }, button_mask: [2, 0, 0, 0, 0, 0, 0, 0], valuator_mask: [0, 0], axisvalues: [] })
Note how they only differ in the deviceid field, being sent from devices 2 and 11. According to xinput, device 2 is a Virtual Core Pointer (master pointer) and device 11 is my actual mouse (slave pointer). Running xev, it does not show duplicate events, so it shouldn't be my configuration but insufficient control logic from glazier.
For reference, my system setup is the following
OS: Manjaro Linux x86_64
Host: 81SX Legion Y540-15IRH
Kernel: 5.15.94-1-MANJARO
Uptime: 5 days, 22 hours, 56 mins
Packages: 2904 (pacman), 7 (snap)
Shell: fish 3.6.0
Resolution: 1920x1080, 1920x1080
DE: GNOME 43.3
WM: Mutter
WM Theme: Adwaita
Theme: Adw-dark [GTK2/3]
Icons: Papirus-Dark-Maia [GTK2/3]
Terminal: alacritty
CPU: Intel i7-9750H (12) @ 4.500GHz
GPU: NVIDIA GeForce GTX 1660 Ti Mobile
Memory: 24277MiB / 32021MiB
and I am running X11, a backtrace also shows that the x11 backend is used.
I am using the main branch of Xilem and these issues happen both with its selected glazier version as well as a manually cloned main branch version of glazier (I did not check if those are different or the same).
How to reproduce:
I'm currently on x11 running the gpu example and getting a size
event upon window creation, before app.run()
. Should this event be deferred until then?
Commented out by unpiet process.
See:
glazier/src/backend/windows/mod.rs
Line 20 in d306005
and:
glazier/src/backend/windows/mod.rs
Line 25 in d306005
I am not really sure why. My best guess it has to do with secret setup.
(Not sure if this is still up to date. Will need to investigate further.)
The gtk-rs crate takes a huge chunk of Glazier, Druid and Masonry's build times, but these crates only use a small fraction of the features offered by gtk. It might be feasible to cut out most of the unneeded features and get a much leaner dependency for shorter build times.
Right now when I compile glazier, I get this error:
Package xkbcommon-x11 was not found in the pkg-config search path.
Perhaps you should add the directory containing `xkbcommon-x11.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xkbcommon-x11' found
', build.rs:20:36
I can roughly guess what I need to do, but I feel like you shouldn't get a build error because of a missing dependency if the README doesn't mention you have to install that dependency.
Is there a reason why IdleHandle::schedule_idle
takes a &mut self
instead of just &self
like add_idle_callback
? The underlying function add_idle_token
doesn't seem to require mut access in any of the backends.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.