-
Notifications
You must be signed in to change notification settings - Fork 343
Conversation
Indeed, I'd prefer to use setters. While the setters are trivial right now, they're about to get more involved with damage tracking and output-layers considerations.
That's a good question. I think for most use-cases we'll want rects to intercept the click events?
It would just set the size on commit right? I think that'd be fine yeah.
An interface struct with function pointers is mainly useful to allow third-parties to extend wlroots with their own node types. If we expect all node types to be built-in in wlroots I'm not yet sure this is a good idea. I guess it depends whether or not we can come up with a good interface API. Some node type implementation details may need special handling. If building an abstraction makes the code more complicated it wouldn't be worth it. We don't necessarily have to expose the Some interactions with things like output-layers aren't yet clear to me if we go down the interface route. I think I'd prefer to keep the enum for now and re-consider once we have all of the fancy features. |
Added setters, updated the example, and created a I went ahead and removed (Edit: technically it subsumes the "opaque" functionality, so if we were to revive |
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.
Overall this looks pretty good!
I'm still wondering about wlr_scene_node_surface_at
: it doesn't seem like compositors can re-implement it with wlr_scene_node_surface_at
, or at least not without making scene_surface_from_node
public.
Ah, you're completely right. Somehow in my mind |
Looks good to me! Can you squash the commits into logical commits? See https://github.com/swaywm/wlroots/blob/master/CONTRIBUTING.md#commit-log e.g. "scene: use memcpy to copy color arrays" can be squashed into "scene: add RECT node type" |
This will allow us to create node types which are rendered but not surface-based, such as a solid color or image.
RECT is a solid-colored rectangle, useful for simple borders or other decoration. This can be rendered directly using the wlr_renderer, without needing to create a surface.
With the addition of a non-surface node type, it was unclear how such nodes should interact with scene_node_surface_at(). For example, if the topmost node at the given point is a RECT, should the function treat that node as transparent and continue searching, or as opaque and return (probably) NULL? Instead, replace the function with one returning a scene_node, which will allow for more consistent behavior across different node types. Compositors can downcast scene_surface nodes via the now-public wlr_scene_surface_from_node() if they need access to the surface itself.
Add RECT nodes to the scene-graph demo to illustrate how they are used. Here, we add a solid rectangle behind each surface as a quick-and-dirty border, handling surface.commit in order to size it appropriately.
I left the simplification to |
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 perfect, thanks!
Adds a new scene-graph node type for rendering solid-colored rectangles, which may be useful for simple window decorations. A little reworking was needed in the scene-graph implementation, since it would break the assumption that every rendered node has an associated surface.
Thoughts/questions:
wlr_scene_rect_set_size()
and/orwlr_scene_rect_set_color()
function, or is it straghtforward enough to change the fields directly? (Maybe damage tracking considerations tip the scale toward functions?)wlr_scene_node_surface_at()
?scene_node_impl
rather than switching on a type field?