The future of wlc

[Drakulix]

Hey there,
I am currently working on fireplace as some of you might now, and I also guess most of you know about sway and track its status as well, because it is the most popular and feature complete compositor build upon wlc.

Recently sway decided to switch to an in-house compositor and so far there are no guarantees, that their new compositor will be usable completely independently from sway, if it can be dynamically linked and if we may be able to write rust bindings as a direct result of it.

wlc will of course still exist, but its situation is already complicated, although sway is making use of it as well and maintenance is kept at a bare minimum to keep it functional. I honestly expect this situation to get even worse, once sway has made that transition.

As a result, I am thinking about switching the compositor library as well for fireplace. Current alternatives I see are:

• Writing bindings for libweston (it seems quite usable, but more investigation is necessary)
• Rewriting wlc in rust. Because this is quite the huge undertaking, I would suggest translating the original wlc library with corrode, fixing the result until it can be used as a direct replacement and then gradually re-write parts of it, writing bindings where required on the way and replacing certain libraries with the rust ecosystem.

I personally don't think wlcs design is overly complicated, it is clearly structured, the biggest difficulty comes from the inherently complex things wlc does.

That said I am in favor of using libweston (if possible) instead of maintaining another project.

The reason, I am bringing up this issue here, should be fairly obvious. way-cooler will be influenced by sway's decision as well and I wanted to suggest to join forces on finding and writing a suitable replacement. What do you think?

[Timidger]

Hey there, thanks for reaching out.

You have a done a good job enumerating our options. I also agree that we should not necessarily make a rust fork of wlc. While it would be easier to transition Way Cooler over to something like that, it would be a bad decision in the long run.

Another alternative is to go the sway route and integrate our own compositors. I do not think this is the correct solution, I think that the future of non mainstream window managers (eg non Gnome/KDE) is to use libraries like Libweston and wlc so that they all get the benefits.

Taking a look at that tutorial (I've never looked at Libweston) it looks to be a less abstracted wlc (no longer are there callbacks, and we use most Wayland object directly). We should make sure that it is possible to use the Wayland client libraries that @vberger has made. I know when trying to work with it in the past there were issues due to the user data that both wlc and the Wayland rust libraries need to use.

EDIT: see this thread for details

[Drakulix]

I have also found libweston-desktop, browsing though their sources, which seems to abstract a lot of the xdg-shell functionality in addition to libweston. This looks quite usable, as you said, basically wlc with wayland types.

I have also noticed @vberger has started/planned a similar project, although this does not seem to be based on libweston, but rather a new take on something like wlc, just in Rust.

I am still in favor of creating libweston bindings, as far less maintenance work would be required to keep up with the upstream changes.
Maybe @vberger can provide some information on why he started smithay? Is it more an educational project or is there a reason libweston would not make a good/idiomatic rust library?

From what I've seen his wayland implementations looks quite stable at least design-wise and the user_data problem was also addressed recently.

[Timidger]

Interesting, I had not seen that project he started. I'd be interested in hearing why he is doing it too.

I also agree that going with Libweston seems to be the better way to go.

Nice to hear those user data issues were fixed though

[chrysehs]

Looking at orbment when I read Cloudef/orbment#141 (comment) and does not look like wlc is over-complicated as much as it is all the things really in wayland. Anyone find compositor using libweston? only I find is https://github.com/gschwind/libweston_tutorial . @Cloudef mention https://github.com/letoram/arcan/wiki , did he check more? http://durden.arcan-fe.com/ seem very complete. Then https://github.com/michaelforney/swc also looking like it is developed still.

[Drakulix]

Then https://github.com/michaelforney/swc also looking like it is developed still.

I had my first tries with swc back almost 2 years ago and that point it's development had stalled and many advertised features were broken. Although development has happened very recently, it hasn't even made the transition to the xdg-shell-v6 protocol and is still using v5. I would not expect libswc to become a more viable alternative to what wlc currently provides in the near future. Although I certainly hope I am wrong. The more options the better.

[Timidger]

Although I certainly hope I am wrong. The more options the better.

I agree with @Drakulix, the more frameworks right now that try to achieve what wlc could not (and maybe libweston does) is good. From the bazaar, we will eventually center a round a few good frameworks to use for this.

Looking at orbment when I read Cloudef/orbment#141 (comment) and does not look like wlc is over-complicated as much as it is all the things really in wayland.

I agree, though I think that this complexity can be managed.

Yes, in it's current form Wayland compositors are in a tough place: they need to implement a lot of functionality. However, my hope is that libraries like wlc was meant to be and what libweston might become will become the norm for implementing window managers. wlc was a hobby project that wasn't designed to handle all the complexities that he listed (and that's fine).

Because libweston is from the Wayland devs, and Weston relies on it it is more likely to get these features that window managers shouldn't worry about. There doesn't seem to be any other "real" window managers implemented in it, but I think that has to do with how new it is rather than any indication on the quality of the library itself.

[Drakulix]

There doesn't seem to be any other "real" window managers implemented in it, but I think that has to do with how new it is rather than any indication on the quality of the library itself.

Right. libweston was only recently split from weston itself. Long after GNOME and KDE did start to provide wayland support. Its understandable that nobody has picked it up yet.

[Timidger]

So it seems libweston is the way to go. We should attempt to set it up similar to how you did wlc.rs @Drakulix, with a libweston-sys as the bindgen and a wrapper above it providing safe bindings. Where should the project live, under your namespace or ours? Since it's just bindings, there won't need to be as much maintenance so it doesn't really matter to me.

You did a good job designing the abstractions for wlc, so perhaps you should spear-head the design if you'd like. I'd be more than happy to help you work on it. Once it's built we can begin moving over our respective window managers to libweston.

[Cloudef]

Here are the main (technical) things that suck about wlc and can maybe act as advice for other peoples dwelling into writing similar library.

1. Avoid immediate calls.
   One problem in wlc is that it tries to process everything immediately. This ruins performance as events and calls are not being throttled, it can easily also cause recursion when calling back into wlc from callback. As a alternative make more use of the event-loop that is required anyways (if using libwayland), or defer calls to stack from which they will be popped later (as bonus the stack can act as valuable replay / debugging resource). This also simplified handling of cases where something should be done only after next wayland display dispatch (many keyboard, focus related issues on wlc would be fixed).

2. Datastructures could be generated from wayland specifications.
   wlc has lots of code written by hand that could've been generated from protocol specifications. The wayland-scanner merely offers you callbacks, but most of time you also want to store the data given from these callbacks somewhere.

Few ideas I had in mind during development:

1. Make wlc a wayland protocol, which only privilidged process (wm) can use. (Thus being like xserver)
2. Generate all control flow from finite state machine representation.

[Cloudef]

libweston should be a safe bet since it is maintained by wayland / weston developers.

[Drakulix]

You did a good job designing the abstractions for wlc, so perhaps you should spear-head the design if you'd like. I'd be more than happy to help you work on it. Once it's built we can begin moving over our respective window managers to libweston.

Thank you very much. I will open a repository later today and add you as a contributor. Anybody else working on way-cooler is also welcome, just ping me and I will add you.
I might take some days until I add anything reasonable to the repository, I am a bit busy with exams in the next week, but other than that I am looking forward to this project.

Also huge thanks @Cloudef for your insights.

[Timidger]

I might take some days until I add anything reasonable to the repository, I am a bit busy with exams in the next week, but other than that I am looking forward to this project.

Same, I should have some time this weekend though so I'll try and stub out at least the basic bindings.

[moosingin3space]

I'm interested in Wayland and may have some time coming up, please add me so I can help!

[Drakulix]

I have opened a repository and added you two. I currently does not compile, but provides a starting point.
Please use branches and pull requests and let us all review our changes before pushing them to master.
If you have some questions about the overall design feel free to experiment, but open an issue for discussion. Any further discussion about the project may be done in the repository itself.

[elinorbgr]

I see I've been pinged here regarding my very new project smithay. Let me then give you more details about it. :)

About compatibility of wayland-server with wlc/libweston

First of all, regarding the question of compatibility between my wayland bindings and other libs like wlc and libweston, the recent PR I made adding an user_data mechanism does not fix it. The core idea is that my bindings use the user_data mechansim from libwayland-{client,sever}.so to store metadata about the Proxy/Ressources and ensure safety from Rust point of view. An important goal of my bindings was to provide a safe API, and I can't see how to do this without using the user_data.

Now, internally, wlc and libweston also use the user_data field to do their logic. Actually, I recently realized this is almost indispensable, thiw is why I added a similar mechanism on my bindings. But this is a new user_data API built on top of the original C one. It is not compatible with it at all.

Why smithay

As a consequence of it, my bindings cannot be used in conjuction with a C library using this user_data, so basically any lib taking a large control over the program workflow, lib wlc or libweston. This is part of my motivation for smithay: providing a library filling the functionnalities of wlc/libweston, but in Rust, and built on top of my bindings, so hopefully mostly safe-rust.

An other, more personal motivation, is principally intellectual interest. I find this project interesting. But I am well conscious of a particular difficulty of these kinds of libraries: they cannot be built out of nowhere, without being driven by a concrete project (to ensure the API design choices are actually usable). This is mostly why I've implemented the wayland backend of glutin: as a way to ensure my client bindings (and the helper crates wayland-kbd and wayland-window) were properly designed.

Now, I don't have a compositor project in my hat, so needless to say, regarding this, if anybody is interested into building a compositor on top of smithay, I'd be very enthusiast about it! But smithay is also basically empty for now. I'm still figuring out the proper design. And my lack of experience in writing wayland compositors at large does not help.

smithay's design

I think my target design will be quite different from wlc (I don't know about libweston) but probably much more rusty. I plan to build on top of wayland-server's design: the binding crate provides an abstraction for the event loop, the user then provides a set of Handlers, which are structs implementing traits from handling the various client requests (you can think of it as fancy closures provided as callbacks).

The core modularity approach is composition: handlers are composable. For example, wayland-kbd abstracts over wl_keyboard::Handler and require the user to provide a wayland_kbd::Handler instead, which is an higher-level API that the pure wayland one.

Now I plan to plug smithay into this in a very simple way. It should provide:

• basic primitives to interacting with the underlying platform (initialize a tty, the link with mesa, libinput, etc...) (this will maybe be done as a set of small independent crates, using smithay as an umbrella)
• pre-implemented Handlers simplifying basic functionality that will probably be very common across compositor design

But importantly: it reuses wayland-server's event loop, and does not abstract over it. The user is still responsible for setting it up and running it. The goal in this choice, is that smithay should then be modular: you can use only what you want for it. If you want to plan a very specific design for handling some kind of client requests, just don't use the provided Handler and write your own.

---

That's my idea with all this for now. As I wrote, I'm still thinking over the overall design of smithay. To kickstart the thing, I'm trying to re-implement the SHM helpers from libwayland-server.so, that also cannot be used with wayland-server due to this user_data issue. You can see the work in progress here: https://github.com/vberger/smithay/tree/shm_handler

Hopefully this answered your questions, @Timidger @Drakulix ?

[elinorbgr]

As a TL;DR: if you want a working replacement for wlc ASAP, libweston is certainly the best route.

If you're willing to invest time in helping me design smithay, I'd love it (and this is basically the thing I'm looking for). But I know it's a quite long shot, and maybe not an option you're willing to follow.

[Drakulix]

Some very interesting information.

I would love to switch to smithay at some point, but I have some reservations about it:

• first its quite a long shot as you pointed out and I do not know if wlc will be enough for the meantime, I doubt it
• second although I bet we all can learn from mistakes that were already made, we are then replacing wlc with something very similar. A rather small hobby project, which will need time to mature and might never be reach the compatibility libweston would provide.

On the other side, I really like the design of your project, I have gone a very similar route in fireplace. I took the basic abstraction wlc provided, used the specialization feature to provide default implementations for them to make them composable and wrote a bunch of rather small handlers providing a complete compositor together. That fits nicely.

I am really in two minds about this. I would like the result of fireplace+smithay much more, once it is done and everything works. But using libweston is a much easier and more maintainable transition.
Also I dont want to switch the framework to often for obvious reasons.

[Timidger]

While I lament the loss of using your bindings, I think the best decision for us is to use Libweston. It's already at a mature state, and is very likely to be maintained in the future.

Good luck with smithay, I hope someday that there will be a nice stack for a Rust Wayland window manager to use.

[Drakulix]

@vberger When smithay matures, please feel free to ping me and I might try to get the minimal required codebase of fireplace ported over. If I will ever do the transition will mostly depend on the state of smithay and I do not have enough time and the required knowledge to contribute much code, but I am more than willing to provide feedback to you.

In the meantime, lets focus on libweston. Its not bad to have choice and I also want something reliable in the near future.

[elinorbgr]

I think you're making the wise decisiong by focusing on libweston. I really cannot give you any guarantee about when smithay will be ready.

However, give it seems to interest you nonetheless, I hope I can ping you if I have questions regarding smithay's design possibilities. Your experience in writing compositors would certainly be very helpful!

[ddevault]

Hi, I'm the BDFL over at Sway. I have two thoughts to share in this thread:

• If you guys want to collab on a wlc replacement I'm down
• I've evaluated libweston several times over the past year or two and have concluded every time that it's not the right call. I can expand on this if you'd like. I think you would be wiser to invest in something like smithay. You should always trade immediate gain for a better solution in the long run. Who cares if it's done in 6 months or in 2 years? This is my approach to Sway.

[ddevault]

Also, note that the points I raise over at swaywm/sway#1076 are discussion points, not decisions. If you're interested in collaborating on this and changing some details would suit your needs, please bring it up for discussion.

[Drakulix]

@SirCmpwn
I would really like to hear your thoughts on libweston.

Building a solid foundation is what I want and with limited man power libweston looked like a good choice, but I have not investigated enough into it to call this a fixed decision and if we all develop something together building something completely new becomes a very doable project.

Obvious questions, since most of the people participating here were expecting to write something in rust. Would you rather prefer C and if yes for what reasons? There is no problem in wrapping the C library for Rust, neither is there a problem providing a C API from a rust library, its just that wlc did a pure job fitting with Rust's memory model, as it was not designed with that in mind and the easiest way to avoid that (and in return gain some safety guarantees) is to use rust in the first place. But I would most likely also join a C project as long as something usable and maintainable is the end result.

[ddevault]

Building a solid foundation is what I want and with limited man power libweston looked like a good choice, but I have not investigated enough into it to call this a fixed decision and if we all develop something together building something completely new becomes a very doable project.

libweston has a number of problems, in no particular order:

• The codebase is generally pretty bad. It's has good performance but the actual code is pretty terrible.
• It has a lot of questionable opinions like desktop-shell.xml that you will inherit with it
• Weston design choices bubble up to libweston too, like the config parser, keybindings, etc. It does too much.
• The API is poorly designed and basically just exposes internal weston headers to libweston users and hopes they'll read around the implementation details
• Working on libweston involves collaborating with weston developers, which is... not something I would look forward to

I had more reasons but they don't come to mind at the moment. IMO weston is best suited as a reference compositor and not a practical one.

Obvious questions, since most of the people participating here were expecting to write something in rust. Would you rather prefer C and if yes for what reasons? There is no problem in wrapping the C library for Rust, neither is there a problem providing a C API from a rust library, its just that wlc did a pure job fitting with Rust's memory model, as it was not designed with that in mind and the easiest way to avoid that (and in return gain some safety guarantees) is to use rust in the first place. But I would most likely also join a C project as long as something usable and maintainable is the end result.

You can probably guess that I would prefer C. I have some personal objections to Rust as a programming language that aren't relevant for this thread. I feel that choosing C will lead to a tighter product, better portability, and faster development. For one thing, we can mobilize the small army of Sway contributors in this direction if C is used. I have some strong opinions about C that lead to, among other things, safer C code that's easy to write API wrappers for. I'm not concerned about Rust interop being an issue, especially with a contingent of contributors maintaining a Rust wrapper to integrate with way-cooler and policing the API themselves.

It's unlikely that any effort in Rust is going to be integrated with Sway. The interests of the projects would just be too divergent. If a wlc replacement were written in Rust, it would be better to expose an idiomatic Rustful API for way-cooler to use, and such an API would not integrate cleanly with Sway. No hard feelings if you want to go with a Rust solution - but the hard truth is that using such a solution would probably be bad for Sway. I think both projects and the greater ecosystem would benefit from a shared base, though, so we should consider a C solution carefully.

Unrelated, I object to forking wlc or converting wlc to Rust with that one tool. A greenfield effort would probably turn out better.

[Drakulix]

The API is poorly designed and basically just exposes internal weston headers to libweston users and hopes they'll read around the implementation details

I had this impression when looking through the public api and did hope this is just some wayland stuff, they did not want to wrap. Too bad..

Working on libweston involves collaborating with weston developers, which is... not something I would look forward to

My hope was not having to work with any of them, because it is the reference implementation, meaning it should work the best, although most likely not perfectly. Did you already have some bad experiences? This sounds like it.

You can probably guess that I would prefer C. I have some personal objections to Rust as a programming language that aren't relevant for this thread.

I already expected that, so no worries. Not every language is for everybody and not every language suits every use case, although I certainly think it would fit this specific one and could be a tight product.

Portability especially with a few BSD-users you have, might actually be an issue and fast development comes mostly down to the amount of C libraries you would need to use, but I give you that point as well.

In case you are interested, I have had quite some experience with C and Rust, if you ever have interest in talking about your opinions or giving the language another chance, but don't know where to start, feel write to write me.

Unrelated, I object to forking wlc or converting wlc to Rust with that one tool. A greenfield effort would probably turn out better.

I would also prefer that, but this brings up the time issue again, which mostly exists because you already have quite advanced plans for your compositor and I had the feel, that we needed to leave the sinking ship asap, if I want to keep using my own compositor.
I am quite happy I got to this point, but the whole wayland ecosystem is moving really fast, xdg-shell-v6 did show how quickly things may break, if something like wlc is not maintained enough.

Developing together with you would of course avoid that problem, as we would probably do the transition together or in quick succession.

I think both projects and the greater ecosystem would benefit from a shared base, though, so we should consider a C solution carefully.

I approve this. The more is build upon it, the more contribution will happen and the more stable and tested the code base will become.

I have some strong opinions about C that lead to, among other things, safer C code that's easy to write API wrappers for.

I would like to hear about this, maybe you have already written something like this in sway contribution guide if something like this exists? If I can see that your project is well suited for my/our needs without facing some additional challenges, I would most likely join.

[ddevault]

My hope was not having to work with any of them, because it is the reference implementation, meaning it should work the best, although most likely not perfectly.

The reference implementation works the most correctly, not the best. That's what it means to be the reference implementation. And you would definitely have to work with them, you'll always have to work with a project this close and critical to your own. Sway contributors have a significant amount of code to wlc to make it suit our needs.

I already expected that, so no worries. Not every language is for everybody and not every language suits every use case, although I certainly think it would fit this specific one and could be a tight product.

The concerns I have here are with Rust, not with Rust projects. No product made with Rust could be a tight product in the context of my concerns about Rust.

Portability especially with a few BSD-users you have, might actually be an issue and fast development comes mostly down to the amount of C libraries you would need to use, but I give you that point as well.

Portability amounts to more than Linux and BSD. I see no reason why Sway shouldn't run on any POSIX system with minimal finageling (porting rust does not count as minimal finageling). I expect Sway to be able to be ported to Linux, BSD, Minix, plan9, and your cousin's POSIX clone he wrote in OS class in college, on every architecture ever. C delivers on all of that like no other language can.

I would also prefer that, but this brings up the time issue again, which mostly exists because you already have quite advanced plans for your compositor and I had the feel, that we needed to leave the sinking ship asap, if I want to keep using my own compositor.

I would sacrifice time for a better product any day of the week. Xorg works, people can still use it today. And I think you'll find that if we can get a sufficient force of motivated contributors behind this project, time will be less and less of a problem. Getting Sway from PoC to usable desktop progressed at a blistering pace.

Developing together with you would of course avoid that problem, as we would probably do the transition together or in quick succession.

Aye.

I would like to hear about this, maybe you have already written something like this in sway contribution guide if something like this exists? If I can see that your project is well suited for my/our needs without facing some additional challenges, I would most likely join.

Some of this is written down. Some of it comes from intuition and is made known while reviewing pull requests. The written down parts are here: https://github.com/SirCmpwn/sway/blob/master/CONTRIBUTING.md. I call out unsafe C during review, and forbid certain practices like fixed buffers and carefully watch what happens to untrusted values. Writing safe C requires dicipline but it's definitely achievable. I encourage you to read through Sway and my other C codebases (aerc is another good one) and their pull requests for an idea of how I C.

[Timidger]

@SirCmpwn

Thanks for your insight, I'd be willing to work together on a wlc replacement as well. Sway, Way Cooler, and Fireplace don't seem to be going anywhere so I think a library mantained by us will both better suit our needs and more likely to be maintained compared to wlc.

I understand your desire to write it in C, and would be more than happy to contribute to it (I also know C, though not as well as I know Rust). To make it in Rust would probably make it problematic for other languages to bind to it, because even if we expose C bindings they would not be one-to-one with the Rust ones and a divergent API is never good.

I would sacrifice time for a better product any day of the week. Xorg works, people can still use it today. And I think you'll find that if we can get a sufficient force of motivated contributors behind this project, time will be less and less of a problem. Getting Sway from PoC to usable desktop progressed at a blistering pace.

This is also a good point -- it's important that we build something right rather than work to build something fast. wlc was obviously just a hobby projct, but it didn't try to do things right and suffered for it. Since our window managers seem to be the only usable/near-complete tiling window managers in the Wayland ecosystem right now, it seems prudent that we design a good, lasting solution for tiling window managers.

[Drakulix]

The concerns I have here are with Rust, not with Rust projects. No product made with Rust could be a tight product in the context of my concerns about Rust.

I am sorry, but I cannot hold myself, although I know this is not really related to the issue. I am sold on doing the library in C, no worries, but is this about the rather huge statically linked standard library or how did you end up with that opinion?

... C delivers on all of that like no other language can.

Point made. Although I had recently fun developing a kernel in rust at university, but its definitely not production ready for these things.

Getting Sway from PoC to usable desktop progressed at a blistering pace.

I know, I watched it grow and used it for quite some time. ;)

I encourage you to read through Sway and my other C codebases (aerc is another good one) and their pull requests for an idea of how I C.

I will in the following days, I like what I see in the CONTRIBUTING file so far (although tabs is a bit unusual, but hey, that is something my IDE should handle).

Thanks for your insight, I'd be willing to work together on a wlc replacement as well. Sway, Way Cooler, and Fireplace don't seem to be going anywhere so I think a library mantained by us will both better suit our needs and more likely to be maintained compared to wlc.

Nice to see you on-board here.

Since our window managers seem to be the only usable/near-complete tiling window managers in the Wayland ecosystem right now, it seems prudent that we design a good, lasting solution for tiling window managers.

Just adding my two cents, I do not think a library like wlc should be tailored to tiling at all. Maybe provide some helpers, but that's about it.

@SirCmpwn I see you are managing a lot of your discussion via IRC. I am not a big fan of it, mostly because I always forget to check it and miss important information. If you continue to sum up most of it in swaywm/sway#1076 and if we could organize smaller projects related to the new compositor in their own issues, I would be really happy. Once we have fleshed out, how you would like to structure it and go about it, I am willing to jump straight into development.

[ddevault]

I am sorry, but I cannot hold myself, although I know this is not really related to the issue. I am sold on doing the library in C, no worries, but is this about the rather huge statically linked standard library or how did you end up with that opinion?

We can chat about this on IRC or something if you like. Which you don't, it seems.

Just adding my two cents, I do not think a library like wlc should be tailored to tiling at all. Maybe provide some helpers, but that's about it.

Agreed. This was just briefly discussed on, uh, IRC.

@SirCmpwn I see you are managing a lot of your discussion via IRC. I am not a big fan of it, mostly because I always forget to check it and miss important information. If you continue to sum up most of it in swaywm/sway#1076 and if we could organize smaller projects related to the new compositor in their own issues, I would be really happy. Once we have fleshed out, how you would like to structure it and go about it, I am willing to jump straight into development.

I highly reccommend IRC as a medium for collaboration. If important decisions are reached or important topics discussed, they are summarized or pasted into the discussion on GitHub so they won't be missed and are permanently archived. It seems from my readings of the rest of the discussion that some of the direction I'm proposing doesn't mesh quite right with way-cooler's goals - can you guys hop into that discussion and provide feedback? I think before we start actually writing code we need to discuss and stew on this for a few weeks.

[Timidger]

@SirCmpwn, I'll be sure to hop on the IRC. I have been there a few times, namely to see ask a question or two and see what it's like. The only thing stopping me before was that I didn't have a client that I knew well enough and so was just using web clients in order to connect. Now's a good a time as any to find an IRC client I like (any recommendations, by the way?).

[ddevault]

Do you like terminals? Weechat. Do you like GUIs? HexChat.

[moosingin3space]

@Timidger @Drakulix what's the plan wrt libweston.rs? Still planning to build it?

[Drakulix]

@Timidger @Drakulix what's the plan wrt libweston.rs? Still planning to build it?

Most likely not. Focus is now on helping @SirCmpwn with his compositor and shape it in the process to be also usable by way-cooler and fireplace.

[Drakulix]

I have spend quite some time to think about this back and forth in the last days and I want to take my chance and go with @vberger 's project smithay.

This might take a lot of time, but the more I try to integrate with the wlc and wayland apis to e.g. implement the redshift gamma-control api, the less I think I will enjoy working on other rust-bindings. It will most likely never integrate well enough with @vberger 's existing wayland libraries and there will most likely be other challeges to fight.

I know that sway's library will mostly likely be the most stable solution and that smithay maybe will take some more time, but I have another vision for my code base and the api I want to use to integrate with wayland.

[Timidger]

@Drakulix, sorry to hear that. Good luck working with smithay.
@SirCmpwn, I'm still down to work with you on a compositor framework if you are.

[ddevault]

Best of luck!

[fooishbar]

I know I'm months too late for this, but just to note for the record (leaving aside 'terrible code' and that we're an awful upstream to work with, which I obviously don't agree with but have no interest in getting into), that whilst libweston does expose a lot of its internal implementation details, that's not the long-term plan.

Current libweston is just an evolution of the original codebase into something which could be exposed as a library; as that wasn't done from the start, we're still going through the process of cleanly separating out an API. We'd be really interested to work with anyone using it, to get feedback on and help fix the - no getting around this - clearly suboptimal current API.

Anyway, best of luck with waycooler and wlc!