[RFC] Exposing sway as a library

[Armael]

The goal of this issue is to collect opinions about the idea of exposing part of sway internals as a library.

Motivation

The motivation behind this is to allow experimenting and extending sway with new features, or replacing/reimplementing existing features. I'm thinking for example of implementing new layouts, new workspace management policies, modifying how outputs are handled... I personally wanted to implement some kind of workspace groups or namespaces, which led me to that proposal.

To my knowledge, the current options for extending sway are the following:

• Using the IPC mechanism. This is a convenient and well documented way of interacting with sway, and running comments/reacting to events. However, it is limited, and does not allow implementing any non-trivial feature related to window management/workspaces/outputs;
• Hacking through sway's source code and implement the desired feature there. This works on the short term, but is probably somewhat difficult to maintain on the long run, as one has to periodically merge sway/master into one's modified version;
• Implementing the feature, submitting a PR, and getting it merged. This is the ideal outcome, but I would assume it requires the feature to be "reasonable", and well behaved with respect to all the existing features of i3.

I feel it would be nice to have an additional way of extending i3, which allows people to use locally extensions that would not be "ready to merge".

Typically I googled a bit for this "workspace namespace" feature, and some people have requested an implementation in i3, but so far there is no consensus on a design that would interact well with all existing features of i3. Still, I would be happy with writing and using locally an implementation of this that only works with the subset of features I use.

I think a solution to this could be to expose some internals of sway as a library, sway-the-binary simply being produced by assembling the components of the library. I do not think this would require heavy refactoring of sway's code, but mostly exposing the bits that already exist as of now.

As a bonus, this would allow to easily extend sway using other languages than C (also something that I'd like to do): these typically interact with C code through a FFI, which makes the "go and hack the C code" approach more difficult. Having the C code available as a library would be much nicer.

Proposal (draft)

I think this can be done incrementally, in an "on-demand" fashion. The first step would be allowing the user to provide custom implementation for the various handlers that are registered by sway, and exposing the default implementation of these handlers.

• The current C code for sway-the-binary is moved to sway-the-library
• sway-the-library provides a sway_main function, which takes a struct of handlers to use as argument
• the default implementation of these handlers is exposed in sway-the-library
• sway-the-binary simply calls sway_main with the default handlers

Allowing users to swap out custom code for some of sway's handlers (and reuse the default implementation) would already be super useful. I got something along these lines working locally, and I'd be happy to submit a PR if this is considered a good idea.

Then we could think of exposing a bit more of the internals, on a case-by-case basis.

Maintenance

I understand exposing some of sway's internals comes has a maintenance cost: the developers now have to put extra thoughts when changing the exposed interface, because it could break user code.

I personally think it would be fine to handle this in a relatively liberal way, and allow breaking the API when needed — I would consider the API "expert mode". But this mostly depends on the developers appreciation, I assume.

---

Thoughts?

[4e554c4c]

There is already some effort to extend sway development into a separate library and that is wlroots. In my opinion, sway should not be a large and modal library, but a smaller implementation of higher libraries.

As a bonus, this would allow to easily extend sway using other languages than C

I believe it is especially true in this case. Sway is very C-centric and I don't think that any of it would be good to extended to other languages. They should be, like sway, another front-end to the same libraries. Just like what way-cooler is.

That being said, how sway is done could definitely be improved, and I know that Sircmpwn has expressed that he wants to do things a different way as well. See the initial proposition for #1076

Implementing the feature, submitting a PR, and getting it merged. This is the ideal outcome, but I would assume it requires the feature to be "reasonable", and well behaved with respect to all the existing features of i3.

Yes, this is a problem, I agree. Again, the proposal in #1076 may be better for less i3 compatible features, and hopefully creating similar projects will be easier once wlroots is more complete.

[ascent12]

There is already some effort to extend sway development into a separate library and that is wlroots.

wlroots is more focused on handling a lot of the details like displaying things to a monitor, input, and the like. It's not going to handle any window management features, which is supposed to allow a lot more flexibility for the compositors and what they can do. I think @Armael's talking more about window-manager specific stuff.

[ddevault]

I'm not interested in this at the moment.

[Armael]

Ok. Thanks for your time.