The Tiling Layer

[acrisci]

The Tiling Layer

[acrisci]

Tiled layouts are configured per tag, so I think I need to do basic tags first.

[Timidger]

So previous versions of Way Cooler had i3 like tiling. However, for Awesome tiling the tiling is done "entirely" through Lua.

I say "entirely" because obviously the compositor (or X in Awesome's case) still needs to know where to put the clients. Thankfully we can share the same representation and use the Lua state directly, like we are already doing for the drawins to render the status bar.

We'll probably need to implement the API of almost everything in this issue for the Lua libraries to call. Then we "just" grab the coordinates and other information from the client structure and render it (here is how Awesome defined it, ours will be similar potentially).

Now I'm not sure of how this interacts with standard drawins. Are they treated as clients as well? Are clients always other clients or could they just be other floating "windows" that Awesome creates (like popups and the like)? If so then that will complicate this (and if not, wee we can just stick an View in there and do that). @psychon will probably know more.

This is definitely the biggest and ugliest API to implement, but once it is implemented tiling should "just werk".

[acrisci]

Oh ok, what's the first thing to do?

[Timidger]

I don't know what exactly part of the API is needed (except definitely geometry). You can see what's necessary with the errors that are spat out on the console.

[psychon]

I don't know what exactly part of the API is needed (except definitely geometry).

I would guess geometry. However, before that, clients need to be actually created for any windows that the compositor manages and the manage signal has to be emitted (and I guess unmanage for when they go away). I would start with implementing this and then stubbing methods until the resulting errors go away. :-)
Next step would IMO be to implement client.get which lets Lua query the list of all clients, but this could again cause lots of errors for unimplemented APIs.

Before the above is done, the Lua code will not assign geometry to clients anyway.

Now I'm not sure of how this interacts with standard drawins.

Short version: For now this can be ignored. The only interaction that I see is "stacking order" and that can be handled much later, I guess.

Long version:
In awesome, drawins and clients "inherit" from something internal called "window". A window (basically) has a geometry (Area in way-cooler).
Right now, the only important interaction that I can come up with is the stacking order. This is defined/handled in stack.c, but I guess could be ignored for now. Anyway: A window is assigned some layer and the order is like this:

• clients with .type == "desktop" at the bottom.
• clients with .below == true
• drawins with .ontop == false
• clients not assigned to any other layer
• clients with .above == true
• clients with .fullscreen == true
• clients with .ontop == true
• drawins with .ontop == true

Oh and one more thing: transient windows (e.g. a "Open file" dialog) are ignored by the algorithm and are instead stacked ontop of their parent window.

Inside the layers, the order is basically "in order of creation". For drawins, no one yet had a reason to be able to influence this, but for clients, the C code can influence this. For this, there is a single, global list of all clients (globalconf.stack) and Lua can influence the order in this list via client:swap(other_client). (And for rendering, you basically filter this list for clients that are assigned to the currently active layer)

[psychon]

I thought "basic tags" were done already? They can be selected and activated. The only missing piece would be :clients(), which is a "TODO / FIXME" in src/awesome/tag.rs, I guess (I have not checked).