You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once #50 is merged, the next logical step is letting the config manipulate the scene: if for nothing else, at least for decorations. These are some possibilities how to do it; however, none seems ideal. Which is the least bad? Any better suggestions?
permission-wise:
only allow adding and manipulating view decoration
pros: simple for both kiwmi and config, one cannot get lost there
cons: very limited
let the config manipulate some certain nodes in some certain ways
pros: lets us make assumptions; fairly powerful
cons: would need to create a permission system or something of that kind
don’t restrict the config
pros: powerful; quite simple luak_*
cons: i’m not quite sure how kiwmi and wlroots would cope with it
api-wise:
copy the wlroots api: type-specific functions on the specific type; generic functions on specific_type:node()
pros: little code duplication
cons: unintuitive for a high-level language like lua
copy all generic functions for every specific node type
pros: feels normal on the lua side; simple to understand
cons: code and docs duplication, gets out of hand when making changes
smash the type system and have specific types calling generic functions (which then check that they’re called on one of the types) [otoh, isn’t this sort of how OOP works? 😆]
pros: feels normal on the lua side; less code duplication
cons: seems quite complicated to get it right
Also, should kiwmi_view be treated like a scene node (which could be terrible kiwmi-side with some implementations), or should it have :scene_tree() (which could feel unintuitive)?
The text was updated successfully, but these errors were encountered:
We might be able to wrap that up in an output:draw_rect() lua function, with just an extra parameter for whether it goes above or below the windows. How you delete those rectangles is another matter though.
That would be pretty ugly IMO (why would you make the user draw rects ‘sometime before a view’ [exaggregating] if you place them into a nice tree) and leave out nice possibilities that the scene graph offers us: the user could organise everything in a tree without the need to keep their own state (given there would be only one source of truth, there would be less stuff to debug AFAICT), having more control and saving us some worries (although adding other).
...or we go nuts and create a whole API for drawing on wlr_buffers. :)
I believe that’s the plan – for the future, no sooner than simple rects.
Once #50 is merged, the next logical step is letting the config manipulate the scene: if for nothing else, at least for decorations. These are some possibilities how to do it; however, none seems ideal. Which is the least bad? Any better suggestions?
permission-wise:
luak_*
api-wise:
specific_type:node()
Also, should
kiwmi_view
be treated like a scene node (which could be terrible kiwmi-side with some implementations), or should it have:scene_tree()
(which could feel unintuitive)?The text was updated successfully, but these errors were encountered: