Skip to content
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

Expose wlr_scene to the config #60

Open
ghost opened this issue May 29, 2022 · 1 comment
Open

Expose wlr_scene to the config #60

ghost opened this issue May 29, 2022 · 1 comment

Comments

@ghost
Copy link

ghost commented May 29, 2022

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)?

@ghost
Copy link
Author

ghost commented Jun 22, 2022

@Uks2 moving discussion from #63 to here.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants