-
-
Notifications
You must be signed in to change notification settings - Fork 144
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
implement keyboard-shortcuts-inhibit
and wlr-virtual-pointer
#630
base: main
Are you sure you want to change the base?
Changes from all commits
0dade28
132dc72
38615a6
8e32053
3e819c8
71f3b2c
5440002
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
@@ -0,0 +1,50 @@ | ||||
use ::input as libinput; | ||||
use smithay::backend::input; | ||||
use smithay::backend::winit::WinitVirtualDevice; | ||||
use smithay::output::Output; | ||||
|
||||
use crate::backend::Backend; | ||||
use crate::niri::State; | ||||
use crate::protocols::virtual_pointer::VirtualPointer; | ||||
|
||||
pub trait NiriInputBackend: input::InputBackend<Device = Self::NiriDevice> { | ||||
type NiriDevice: NiriInputDevice; | ||||
} | ||||
impl<T: input::InputBackend> NiriInputBackend for T | ||||
where | ||||
Self::Device: NiriInputDevice, | ||||
{ | ||||
type NiriDevice = Self::Device; | ||||
} | ||||
|
||||
pub trait NiriInputDevice: input::Device { | ||||
// FIXME: this should maybe be per-event, not per-device, | ||||
// but it's not clear that this matters in practice? | ||||
// it might be more obvious once we implement it for libinput | ||||
fn output(&self, state: &State) -> Option<Output>; | ||||
} | ||||
|
||||
impl NiriInputDevice for libinput::Device { | ||||
fn output(&self, _state: &State) -> Option<Output> { | ||||
// FIXME: Allow specifying the output per-device? | ||||
None | ||||
} | ||||
} | ||||
|
||||
impl NiriInputDevice for WinitVirtualDevice { | ||||
fn output(&self, state: &State) -> Option<Output> { | ||||
match state.backend { | ||||
Backend::Winit(ref winit) => Some(winit.single_output().clone()), | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this actually do anything? Maybe just replace the whole thing with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Basically, it asserts that the mouse position on the winit backend will break if/when it ever adds another output. Like, it'd try to scale it relative to the global extents of all monitors instead of just the one. That's obviously like, super wrong, for everything on the winit backend. I guess it might also correctly transform the tablet position? If we return None, we hit that code path: Line 290 in f337a27
(the in general, it just makes sure the more relevant known-output code paths are hit. It feels more correct, if nothing else. |
||||
// returning None over panicking here because it's not worth panicking over | ||||
// and also, foreseeably, someone might want to, at some point, use `WinitInputBackend` | ||||
// for dirty hacks or mocking or whatever, in which case this will be useful. | ||||
_ => None, | ||||
} | ||||
} | ||||
} | ||||
|
||||
impl NiriInputDevice for VirtualPointer { | ||||
fn output(&self, _: &State) -> Option<Output> { | ||||
self.output().cloned() | ||||
} | ||||
} |
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.
I wonder if
allow-inhibiting=false
is a bit hard to wrap one's head around? Maybe something alongprevent-inhibiting=true
would be better, human config file reading and writing wise?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.
i don't feel like that change is an improvement, because
prevent-inhibiting=true
is a double negative. but also, i agree with your concern, and i think it's slightly confusing becauseallow-inhibiting=false
is also a double negative, because the value it will be set to is false.is there a way to name it that isn't a double negative?
always-available=true
, but more descriptive? borrow an idiom from CSS and call itimportant=true
? maybe with the exclamation point to drive home the correlation?!important=true
. though it reads as "not".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.
Hmmm, difficult question indeed. I like the word "inhibit" being there because it's the technical term for this (unless it isn't always? do some apps re-phrase it?).
If we drop inhibit, maybe something like "always-accessible" is better than "always-available"? That's kind of still not very descriptive, while it does control a very specific thing, so it would be good if it were descriptive...