-
Notifications
You must be signed in to change notification settings - Fork 567
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
LinuxApplicationExt: experiment with platforms specific extensions #1843
Conversation
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.
Cool, I think this makes sense. I've left some comments inline, but to me it's really just a matter of sorting out the details.
druid-shell/src/lib.rs
Outdated
#[cfg(target_os = "linux")] | ||
pub use application::LinuxApplicationExt; |
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.
how we should expose these is a good question.
I like the pattern in std
of having the std::os
module, which contains std::os::unix
, std::os:windows
, etcetera; I could imagine having something like that?
hmhm:
If we made the platform
module public we could put these in the particular root modules of the specific platforms, but that might get a bit messy.
Maybe what I would prefer instead would be that we have an ext
module, and then ext::linux
? Another option would be to rename platform
to backend
or something, and then we could use platform
for this, which feels like a better name...
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 like platform::LinuxApplicationExt
or platform::linux::LinuxApplicationExt
. renaming existing platform
to backend
sound reasonable.
I would prefer shorter use statement:
use druid::shell::platform::LinuxApplicationExt;
over
use druid::shell::platform::linux::LinuxApplicationExt;
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.
we could also have druid::platform::linux
that reexports things from shell?
Now should we generally distinguish between platform::gtk
and platform::x11
?
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 guess platform::linux::{GtkApplicationExt, X11ApplicationExt}
. X11 and Wayland should be different though
these commits are best understandable separately |
ce969e5
to
4b64400
Compare
Removed x11 impl for now because clipboard is changing in #1851 |
@maan2003 can we split this up, and do the 'platform -> backend' change as a single separate PR? |
Sure 👍 |
provides `primary_clipboard` Co-authored-by: Colin Rofls <[email protected]>
rebased |
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.
Cool, I've been wanting to see something like this for ages, and this feels like a very nice little test case to try it out with.
One question inline, otherwise I'm happy to get this merged!
/// Linux specific extensions to [`Application`] | ||
/// | ||
/// [`Application`]: crate::Application | ||
pub trait LinuxApplicationExt { |
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.
Is this 'linux' thing, or only a gtk thing?
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.
this is a Linux thing
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.
Is this a Linux thing? The primary selection (I wouldn't really call it "clipboard"...) is AFAIK an X11 thing and not implemented on Wayland. But my knowledge here might be out of date and I am too lazy to dig into Gtk's Wayland backend right now, so I am just leaving this as a comment here...
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 really forgot wayland's existence.
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.
there is a unstable wayland protocol and is supported by gtk, qt and by kde plasma, gnome and sway, so 🤷♂️
@maan2003: I just realized something about this, and naming: basically I think this should just be called |
makes sense, will fix this soon |
No description provided.