Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    matrixbot
    @matrixbot
    Johannes Wegener is there an overview which features are implemented in smithay and which still need implementation and how it compares to wlroots or something?
    matrixbot
    @matrixbot
    Johannes Wegener What do you think regarding this post? http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html

    drakulix > <@hpfmn:matrix.org> is there an overview which features are implemented in smithay and which still need implementation and how it compares to wlroots or something?

    Sadly not. Levans and me do have a pretty good idea about where we want to be eventually, but it is not that visible to potential contributors. (A problem that is mostly handled through this channel, because smithay is quite complex, so mentoring is almost mandatory for anyone looking to contribute.)

    matrixbot
    @matrixbot

    drakulix > <@hpfmn:matrix.org> What do you think regarding this post? http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html

    We had quite a long discussion about it, when it dropped. I think that wrapping wlroots (or any complex C-ABI) in Rust has a lot of potential shortcomings, that we can overcome with exploring a different API in smithay. But many parts of the blog post are quite accurate and reflect on a lot of technical difficulties, that we also encountered one way or another.

    matrixbot
    @matrixbot

    Levans (@levans:safaradeg.net) Johannes Wegener: To complement a little what drakulix said, basically currently Smithay is at the "building up foundations" level if I may say it like so.

    We are trying to develop safe, minimal & generic abstractions over the low-level APIs, that means the graphics/input/session APIs on the OS side, and the Wayland protocol on the Wayland side. The goal is to have abstractions that make as little assumptions about how they will be used (to let a compositor using Smithay behave however it wants), but which still compose well with each other.

    The next step will be to build higher-level abstractions on top of them for things like rendering, clients / windows management, & friends. I'm getting increasingly convinced that having a rough idea of what we want here would help guiding us in how to implement the low-level things, so I think this is worth starting to think about this too.

    So if you are interested, any help or input, ideas, suggestions, etc. are welcome :)

    matrixbot
    @matrixbot

    drakulix > <@levans:safaradeg.net> Johannes Wegener: To complement a little what drakulix said, basically currently Smithay is at the "building up foundations" level if I may say it like so.

    We are trying to develop safe, minimal & generic abstractions over the low-level APIs, that means the graphics/input/session APIs on the OS side, and the Wayland protocol on the Wayland side. The goal is to have abstractions that make as little assumptions about how they will be used (to let a compositor using Smithay behave however it wants), but which still compose well with each other.

    The next step will be to build higher-level abstractions on top of them for things like rendering, clients / windows management, & friends. I'm getting increasingly convinced that having a rough idea of what we want here would help guiding us in how to implement the low-level things, so I think this is worth starting to think about this too.

    So if you are interested, any help or input, ideas, suggestions, etc. are welcome :)

    well I have a rough idea for rendering. the rest not so much 😁

    drakulix * well I have a rough idea for high-level rendering. the rest not so much 😁
    matrixbot
    @matrixbot
    Levans (@levans:safaradeg.net) That's already something though ;)
    Levans (@levans:safaradeg.net) I'm quite in the fog wrt to client management overall tbh
    Simon Larsson
    @simvux
    is wayland_protocols::wlr::unstable::layer_shell::v1::client in a usable state? I'm trying to replace wl_shell with wlr_layer in the example wayland-client/examples/simple_window.rs since wl_shell is deprecated and not supported on sway. But I'm having a hard time figuring out how. zwlr_layer_surface_v1::Event appear to be completely empty, and I'm getting an "layer_surface has never been configured" error when trying to use the event_queue. 'nor does the window actually appear to open if I remove the event handling at the bottom, replacing it with std::thread::sleep.
    matrixbot
    @matrixbot

    Levans (@levans:safaradeg.net) If you want to replace wl_shell, the proper protocol to use is xdg_shell, not layer_shell. The later is a specialized protocol for making widgets or overlays.

    Though both xdg_shell and layer_shell have the same "configure" mechanism when you try to use them: once you have created the zwlr_layer_shell_v1 object, you have to commit its associated wl_surface once before attaching it any buffer. You'll then receive a zwlr_layer_surface_v1::Event::Configure suggesting you the correct size to use for your surface. Once that is done and you have acked the configure, you can start drawing.

    Simon Larsson
    @simvux
    For context; My end goal is to create an overlay. So I believe using layer_shell makes sense here. I'm just using the example to test out and learn the API
    So I'm supposed to use layer_surface.assign_mono(|... event| ... Event::Configure {... serial} => and I then call layer_surface.ack_configure(serial)?
    oh https://docs.rs/wayland-protocols/0.24.0/wayland_protocols/wlr/unstable/layer_shell/v1/client/zwlr_layer_surface_v1/enum.Event.html does mention the Configure variant. I couldn't find that previously
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] simvux opened pull request #280: Fixed copy-paste error in example [open] - Smithay/wayland-rs#280
    matrixbot
    @matrixbot
    drakulix It is always cool to see, what people do with your code. The person, that opened the issue about winit-key-repetition in smithay, is using smithay to build a flutter-based compositor. 😮
    https://github.com/csnewman/flutter-compositor
    matrixbot
    @matrixbot
    Levans (@levans:safaradeg.net) Wow, nice :o
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] vberger closed pull request #280: Fixed copy-paste error in example [closed] - Smithay/wayland-rs#280
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/smithay-clipboard] kchibisov opened pull request #10: Remove artificial sleep for 50ms [open] - Smithay/smithay-clipboard#10
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/smithay-clipboard] kchibisov synchronize pull request #10: Remove artificial sleep for 50ms [open] - Smithay/smithay-clipboard#10
    Github [@levans:safaradeg.net] [Smithay/smithay-clipboard] kchibisov synchronize pull request #10: Remove artificial sleep for 50ms [open] - Smithay/smithay-clipboard#10
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/smithay-clipboard] kchibisov synchronize pull request #10: Remove artificial sleep for 50ms [open] - Smithay/smithay-clipboard#10
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/smithay-clipboard] trimental closed pull request #10: Remove artificial sleep for 50ms [closed] - Smithay/smithay-clipboard#10
    matrixbot
    @matrixbot
    kchibisov on Freenode I'm really sorry about asking this question, but could we get a new smithay-clipboard release, please? I'd really like to include new fixes into the next alacritty release which will be pretty soon (we've started rc process).
    matrixbot
    @matrixbot
    Levans ping trimental ^
    matrixbot
    @matrixbot
    trimental kchibisov: of course, I look forward to seeing the changes in the next version alacrity as well :) Just as soon as I get home I’ll release it
    matrixbot
    @matrixbot
    kchibisov on Freenode trimental: Thanks in advance!
    trimental kchibisov: should be updated now to 0.3.6. Just gotta get alacritty to update their cargo.lock
    kchibisov on Freenode Thanks, I can do this part.
    matrixbot
    @matrixbot
    Levans For whoever may be interested by this, a governance agreement has been set up for wayland-protocols (the repository collecting the wayland extensions considered standard) : https://gitlab.freedesktop.org/wayland/wayland-protocols/blob/master/GOVERNANCE
    matrixbot
    @matrixbot
    @matthias.fauconneau:matrix.org was kicked by @appservice-irc:matrix.org ("User has been idle for 30+ days.").
    matrixbot
    @matrixbot
    @dineshdb:matrix.org was kicked by @appservice-irc:matrix.org ("User has been idle for 30+ days.").
    matrixbot
    @matrixbot
    YaLTeR on Freenode Why is get_connection_fd() a method on EventQueue and not on the Display?
    Levans Mostly because I expect it to be useful in conjunction with the EventQueue (when doing a poll / dispatch loop).
    Levans So you only need to access the EventQueue in the part of your code managing that.
    YaLTeR on Freenode I see
    YaLTeR on Freenode Maybe worth adding it to Display as well
    matrixbot
    @matrixbot
    Levans Do you have a specific use case in mind for that?
    YaLTeR on Freenode Not yet; I'm currently looking into the async and polling stuff and checking wayland-client to figure out how it could interact
    matrixbot
    @matrixbot
    Levans I'd be quite interested if you figure out anything interesting tbh, I've tried & failed to bring these together in a meaningful way...
    matrixbot
    @matrixbot
    YaLTeR on Freenode I can see the .flush() method on the Display, which should in theory be used with polling for fd being writable? That calls for having get_connection_fd() on the Display
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] goddessfreya opened issue #281: Does wayland support pixmaps? [open] - Smithay/wayland-rs#281
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] goddessfreya closed issue #281: Does wayland support pixmaps? [closed] - Smithay/wayland-rs#281
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] icefoxen opened issue #282: WAYLAND_DISPLAY and WAYLAND_SOCKET are apparently not universal [open] - Smithay/wayland-rs#282
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] icefoxen closed issue #282: WAYLAND_DISPLAY and WAYLAND_SOCKET are apparently not universal [closed] - Smithay/wayland-rs#282
    matrixbot
    @matrixbot
    Levans YaLTeR @ flush() on display -> wouldn't it make more sense to add the flush() method on EventQueue ? Though tbh I agree the split between Display and EventQueue is a little awkward....
    Levans Semantically, get_connection_fd() and flush() both belong on Display I guess...
    Levans Oh well, let's go with adding get_connection_fd() on the Display. It does not cost anything and is more consistent.
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] vberger opened pull request #283: client: Add get_connection_fd() to Display [open] - Smithay/wayland-rs#283
    matrixbot
    @matrixbot
    Github [@levans:safaradeg.net] [Smithay/wayland-rs] vberger closed pull request #283: client: Add get_connection_fd() to Display [closed] - Smithay/wayland-rs#283