-
Notifications
You must be signed in to change notification settings - Fork 80
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
WLR layer surfaces #203
base: master
Are you sure you want to change the base?
WLR layer surfaces #203
Conversation
src/shell/wlr.rs
Outdated
/// Just a tiny abstraction making anchors easier. Anchor says something about where on the screen the shell is rendered | ||
|
||
#[derive(PartialEq, Copy, Clone)] | ||
pub enum Anchor { |
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'm pretty sure that this should be a bitflag, as we can have multiple anchors at the same time.
You can use my Smithay impl as a reference: https://github.com/Smithay/smithay/blob/dd6919dd5fb1ac6571a3e7dff01b12a2102131fe/src/wayland/shell/wlr_layer/types.rs#L113
You can also see that in the protocol it is marked as bitfield: https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:anchor
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.
Well it is just a an abstraction. It goes down to the correct things i think under the hood. I just wanted to localize Anchor and Layer. When i think about it i probably should just have reexported Anchor and Layer.
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 think i will just reexport them and dont bother with it.
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.
Given the wlr layer shell is likely to be stabilized in the future, I would actually declare this bitflag/enum in module and just implement From
for the wlr and ext and the sctk type so we don't need to break clients when the ext extension is initiated.
src/shell/wlr.rs
Outdated
|
||
/// A struct representing the wlr shell | ||
|
||
pub struct WlrShell { |
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.
Kinda nitpicky, but is wlroots shell
really a good name?
As of now the only shell created by wlroots team is the layer shell, but in the future they might come up with some new ones, and then the name will be confusing.
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.
Do you have any suggestions, i struggled myself that is why it became WlrShell
src/shell/wlr.rs
Outdated
|
||
/// A struct representing the wlr shell | ||
|
||
pub struct WlrShell { |
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 seems more like a LayerSurface
of sorts?
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.
Yeah i agree. A layer surface makes way more sense.
src/shell/wlr.rs
Outdated
Closed, | ||
} | ||
|
||
/// Just a tiny abstraction making layers easier. A layer specifies a z depth for where something is drawn. A normal xdg shell is normally drawn somewhere in between Bottom and Top |
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 would probably make the docs match the purpose of the enum, this is a bit confusing.
src/shell/wlr.rs
Outdated
} | ||
|
||
impl Anchor { | ||
pub(crate) fn too_raw(&self) -> zwlr_layer_surface_v1::Anchor { |
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.
Might make more sense to implement From
for both the type here and the scanner generated type.
Does it still belong in the shell directory or does it belong somewhere else? |
As far as I can tell, it is the best place for shell abstractions |
I totally removed my abstractions and just reexported the ones already provided. I also changed the name too LayerSurface. |
/// Render event | ||
|
||
#[derive(PartialEq, Copy, Clone)] | ||
pub enum RenderEvent { |
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.
Implement Debug
?
|
||
/// A struct representing the layer surface (wlr) | ||
|
||
pub struct LayerSurface { |
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.
Debug
here also
Closed, | ||
} | ||
|
||
/// A struct representing the layer surface (wlr) |
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 think it would be useful to go into detail about what a layer is in the context of Wayland and possible use cases for a layer
|
||
pub struct LayerSurface { | ||
/// The raw wl_surface | ||
pub surface: wl_surface::WlSurface, |
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 would probably make the surface, layer, anchor and dimensions accessible via functions similar to how the Window
abstraction is. The surface()
function specifically returning an &wl_surface::WlSurface
/// The raw wl_surface | ||
pub surface: wl_surface::WlSurface, | ||
|
||
pub(crate) layer_surface: Main<zwlr_layer_surface_v1::ZwlrLayerSurfaceV1>, |
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 fine for now, we can always introduce a LayerInner
when ext-layer-shell is initiated into wayland-protocols
layer_shell.get_layer_surface(&surface, Some(output), layer, "example".to_owned()); | ||
|
||
layer_surface.set_size(dimensions.0, dimensions.1); | ||
// Anchor to the top left corner of the output |
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 comment probably doesn't apply
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.
nop, i forgot to remove it after my CTRL C + CTRL V from the example.
} | ||
}); | ||
|
||
// Commit so that the server will send a configure event |
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.
Initial commit for configure I guess?
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.
Yeah it as this point i suggest we hand it off to the user and let them do what they want.
/// Render event | ||
|
||
#[derive(PartialEq, Copy, Clone)] | ||
pub enum RenderEvent { |
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'd probably go for LayerEvent
since Close
isn't exactly an event related to rendering.
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.
You are right, changed
pub dimensions: (u32, u32), | ||
|
||
/// The next render event | ||
pub render_event: Rc<Cell<Option<RenderEvent>>>, |
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 would mimic what Window
does here with callbacks.
Using a callback here makes sense and also provides the DispatchData
the client has provided.
This would mean your LayerSurface::new would also now need to take a FnMut(Event, DispatchData) + 'static
parameter.
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.
Could you elaborate?
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.
If you look at the methods to create a window you will see one of the parameters is a Impl
which has type bounds defined in the where statement.
This FnMut the user passes in is essentially a lambda that is invoked when some event occurs on the window.
You'll see where you call quick_assign on the layer you create that you are given an event, that is where you will invoke the callback.
The DispatchData is a dynamic data container for some arbitrary data a user of the library passes in that is available when events come in.
Thanks for the feedback, will take a look at it. |
@Eskpil did you by chance forget to push a commit? There are a few comments you marked as resolved but that are not addressed in the current state of the PR. |
@vberger I got a bit distracted with other things and i needed a tiny break from programming, will take a look at it again soon. |
I added a very tiny abstraction for creating wlr shells. It does nothing special, it just eliminates 50-100 lines of code when creating a wlr shell.