@crozbo, I know that's off-topic here, but still. would you mind to check kwin-tiling script and to open reports against any missing functionality over at our issue tracker?

@strobach In past i try some kwin scripts, and i never be satisfied (usually missing features, setup problems, bugs, break on update), so for me that is hacky way, but I will try your script. I know, if plasma implement native tiling mode, that add more complexity, and it is not clear that tiling wm-s is enough big niche to need support. I would like to to make some survey to check how may peoples use kwin tiling scripts or try simulate tiling wm on any other solution.

@strobach to be clear: last time I tried (2 years ago I think) the kwin tiling script you're referring to has been missing some functionality due to deficiences of API provided by kwin. There were long standing bugreports for KDE.

I'm voting for the idea, I also wanted to report it. Please note: on Wayland, there's no real competitors to tiling compositors. There's just Sway, but it has its problems. This means, by creating a tiling-mode for KWin you gonna attract a wide amount of community, including developers. I think this is awesome.

And while on it: I'm also volunteer to contribute to such functionality. I've been previously contributing to sway.

FTR: hiangel user == kkharlamov user. I had to create the later because I couldn't access my older account

In T11067#188369, @kkharlamov wrote:

@strobach to be clear: last time I tried (2 years ago I think) the kwin tiling script you're referring to has been missing some functionality due to deficiences of API provided by kwin.

Well, that was a long time ago and things had changed since. The truth is that the script still doesn't support activities (I'm currently working on it) and wayland clients still can't be managed by the script. There's, however, 4bbef8d128 and once it gets released it will be possible for the tiling scripts to manage wayland clients.

That said, I don't really think there's a reason to reintroduce a functionality which was already dropped once because of a general lack of interest (by both users and developers alike) and which is a perfect candidate for implementation in the script engine. Let's rather improve the scripting API, make it more robust, secure and better documented.

once it gets released it will be possible for the tiling scripts to manage wayland clients.

There might be a small issue though... Wayland doesn't have concept of managed/unmanaged clients, so if your script checks managed property, you're screwed for the most part. I don't see any other option but introduce a client type enum. This would require some adjustments in scripts. :/

Wayland doesn't have concept of managed/unmanaged clients, so if your script checks managed property, you're screwed for the most part. I don't see any other option but introduce a client type enum.

That particular script I'm talking about does not really use managed property.

This would require some adjustments in scripts. :/

Yes, I expect some adjustments to be needed and some run-time X11/Wayland differentiation to be necessary. I'm OK with that - c'est la vie.

@strobach thanks, I'll give it a try again. I can think of something offhand (e.g. configuring shortcuts), but these would need to be solved when adding a new functionality to kwin anyway. So, now that I think of that, what you're saying sounds reasonable. I'll take a look.

Although, one thing that's definitely better when functional is integrated: you don't need to think about backward compatibility. If it works with current upstream, it works for everyone, because you code is part of upstream.

I think there is merit in having a robust tiling experience out of the box no matter how it is implemented, whether baked into kwin or through kwin scripts. Having support in Plasma for it would also mean then exposing it to the user in a discoverable way and documenting it (some users might have never heard of tiling but would like it), I think there is something to be said about it being an accessibility feature as well.

There are multiple parts to a proposal like this, to name three:

• the design (what do we want to do exactly?)
• the UI
• the implementation details

We are at the design stage I think at this point. I think a nice target would be i3 configuration support like sway, or awesome configuration support (with 'tags' being replaced with activities).

In T11067#188536, @hiangel wrote:

@strobach thanks, I'll give it a try again. I can think of something offhand (e.g. configuring shortcuts), but these would need to be solved when adding a new functionality to kwin anyway.

The script shortcuts in particular are handled and configured in the same way as the rest of global shortcuts. There's almost no difference except for the default binding.

Although, one thing that's definitely better when functional is integrated: you don't need to think about backward compatibility.

Yes, that's a valid argument. Currently it's up to the script maintainer/developer to consciously maintain backwards compatibility.

In T11067#188538, @lavender wrote:

I think there is merit in having a robust tiling experience out of the box no matter how it is implemented, whether baked into kwin or through kwin scripts. Having support in Plasma for it would also mean then exposing it to the user in a discoverable way and documenting it (some users might have never heard of tiling but would like it).

This does not apply exclusively to the KWin tiling functionality. There could be a list of "approved" and supported 3rd-party extensions which would be actively advertised to the user.

The script shortcuts in particular are handled and configured in the same way as the rest of global shortcuts. There's almost no difference except for the default binding.

That's the problem. It is too long and monotonous: finding each separate shortcut in systemsettings, clicking a key, pressing Ok. Rinse and repeat for all shortcuts. And then kwin have been losing my bindings a few times… Yeah, that was infuriating experience 😄

Text configs handle that way better: you usually being supplied with "default config", and then you apply to it "find and replace" or some such.

In T11067#188560, @strobach wrote:

This does not apply exclusively to the KWin tiling functionality. There could be a list of "approved" and supported 3rd-party extensions which would be actively advertised to the user.

I know but we're talking specifically about one feature not the idea of including approved 3rd-party extensions. The idea is that it would be first party.

@lavender iIthink it is too much to expect that plasma support i3/sway configuration. Yes, most of i3 features need to be supported or have better solution, but it doesn't need to be exact i3 implementation. Should be kept in mind that plasma have many thing that i3 doesn't have natively, for example plasma have krunner, task switcher, additional windows handling features, complex taskbar, widgets, applications launchers. So it need to be extension/integration with current kwin/plasma not direct implementation of i3 on top of kwin. I have only i3 experience from tiling window managers, but maybe someone know different/better features from other tiling window managers that can be implemented.

@crozbo I just think saying i3 support is a better way to summarize what you want to do, it's a nice clear goal to work towards that would satisfy the functionality that most people want. I'm not hung up on the implementation details.

In T11067#188565, @crozbo wrote:

Should be kept in mind that plasma have many thing that i3 doesn't have natively, for example plasma have krunner, task switcher, additional windows handling features, complex taskbar, widgets, applications launchers. So it need to be extension/integration with current kwin/plasma not direct implementation of i3 on top of kwin.

Isn't that exactly why we need our own implementation and it doesn't just work with i3 right now? kwin already handles all those things.

@lavender Sorry if I write stuff on complicated way, my english is bad. To summerize, we can chose i3 as a clear goal, but we dont need to make 100% of i3 in plasma. We can implement some different tiling solutions/features to be better with plasma.

In T11067#188577, @crozbo wrote:

@lavender Sorry if I write stuff on complicated way, my english is bad. To summerize, we can chose i3 as a clear goal, but we dont need to make 100% of i3 in plasma. We can implement some different tiling solutions/features to be better with plasma.

Yup I think that is how we should approach it, just as a guideline.

In T11067#188532, @strobach wrote:

In T11067#188369, @kkharlamov wrote:

@strobach to be clear: last time I tried (2 years ago I think) the kwin tiling script you're referring to has been missing some functionality due to deficiences of API provided by kwin.

Well, that was a long time ago and things had changed since. The truth is that the script still doesn't support activities (I'm currently working on it) and wayland clients still can't be managed by the script. There's, however, 4bbef8d128 and once it gets released it will be possible for the tiling scripts to manage wayland clients.

Thanks, so, I gave it a short run, so far I'm surprised in a good way, tiling and the usual functional seems to work. Indeed, for 2 years things probably have changed. My only dissatisfaction so far is with hotkeys: some of them doesn't work OOB, and, although there's "move focused window left/right", but I don't see "focus the left/right window". But probably, nothing that can't be changed within the extension.

Just to make it clear: is it possible with current API to override kwin hotkeys from the extension? E.g. to allow a user to apply default hotkeys? I'm asking, because I vaguely remember 2 years ago there were some problems with it due to missing API.

I'll probably configure and try to use it on the weekend: my current KDE installation is a bit broken, I'll need to fix some things.

@hiangel, thanks for giving us a second chance. This is, however, not a kwin-tiling support forum. Please move the discussion either to our issue tracker, or to the gitter.im chat.

In T11067#188760, @strobach wrote:

@hiangel, thanks for giving us a second chance. This is, however, not a kwin-tiling support forum. Please move the discussion either to our issue tracker, or to the gitter.im chat.

Thanks for suggestion. I however didn't ask for support, but asked a question so we can decide if that can be implemented in extension or not.

I forgot to add to my prev. comment: I remember there was some opposition to adding some API to kwin, so it wasn't matter of just writing the code. If all of that solved now, then it's nice.

In T11067#188763, @hiangel wrote:

In T11067#188760, @strobach wrote:

@hiangel, thanks for giving us a second chance. This is, however, not a kwin-tiling support forum. Please move the discussion either to our issue tracker, or to the gitter.im chat.

I forgot to add to my prev. comment: I remember there was some opposition to adding some API to kwin, so it wasn't matter of just writing the code. If all of that solved now, then it's nice.

Yes, there was recently a discussion about exposing some API events on Wayland. There were some concerns about breaking Wayland security by doing so. It was, however, decided that the API does not expose any information not available by other means, so the changes got merged about two weeks ago.

My only dissatisfaction so far is with hotkeys: some of them doesn't work OOB

We have very recently decided to remove the non-essential default key bindings, because a) neither of us is an UX specialist, so the bindings were most probably sub-optimal and b) to prevent more future conflicts with Plasma defaults.

although there's "move focused window left/right", but I don't see "focus the left/right window"

It is a design decision to not duplicate KWin's functionality and KWin already has very flexible and polished task switcher. There indeed are "focus next/previous tile" actions, but they have somewhat special meaning in respect to the window "stacking" order and they are unbound by default.

Just to make it clear: is it possible with current API to override kwin hotkeys from the extension? E.g. to allow a user to apply default hotkeys?

I don't know what's the current state, sorry.

I'll probably configure and try to use it on the weekend

Thanks. If you are on Plasma 5.16, please use our master/HEAD. There are some not-yet-released improvements in handling of maximized clients.

looks like a kinda nice featureto have.... a big overarching goal.. i'm not sure

@mart yes it is big goal, but it is solvable in step, bigest problem I see which make this complicated is X11/Wayland cross-support. But having nice Wayland tiling support can be great feature becouse currently there is not many tiling wm for Wayland, and be leader in that can be key in X11 to Wayland transition

To give some update on my possible participation: from research I made so far I'm convinced to take @strobach 's side: although having a tiling manager in KWin core is easier to maintain; however the kwin-tiling script already exists and does work. I'd like it to have more functional though, but at this point it's more productive to add features there (maybe by creating a fork if needed) rather than rewrite everything from scratch.

A feature that is missing from core KWin is desktop-per-screen, but I hope it's possible to implement without adding a separate tiling mode.

Hereby, I withdraw myself from this proposal.

With that said, at the moment I'm fighting some weird and annoying problem with KDE keyboard layouts on my system, so I'll have to solve this one before moving any further, because ATM it's a pain to use.

Thanks for evaluating the script again.

In T11067#190328, @hiangel wrote:

I'd like it to have more functional though, but at this point it's more productive to add features there (maybe by creating a fork if needed) rather than rewrite everything from scratch.

We listen to our users. We told you, that the functionality you were requesting is currently impossible to implement.

We listen to our users. We told you, that the functionality you were requesting is currently impossible to implement.

I felt like there's some misunderstanding going on. Faho says shortcuts configuration can't be read after script started; but KWin developer's suggestion was to use dbus, and I don't really see why dbus shouldn't return up-to-date information. But I may misunderstand something, at this point I wanted to make some proof of concept to see how that works, and then to reply either to KWin devs or on the issue.

Either way, let's continue this on the linked issue. I'm interested in contributing to existing project instead of creating a new one as much as possible, so you don't need to convince me on that one :)

We had tiling support in KWin and it was a complete failure. The problems was that KWin is a stacking window manager and no matter how hard you hammer on it, it will be a stacking window manager. There are concepts which just don't fit - and that's fine. Maintenance was a hell, especially tiling broke stacking and stacking broke tiling. This is a problem which just cannot be solved.

If you want to do tiling, don't add it to KWin. Instead create a new window manager which is KWin compatible, e.g. support the decorations, support the effects, support the scripts. So that users can choose between a high quality stacking and a high quality tiling window manager.

But overall I agree with Marco that this is a nice feature, but too much for a goal.

@graesslin I don't really see, what were the problems? For example, kwin-tiling extension already works just fine, I've used it for a week or so.

If you want to do tiling, don't add it to KWin. Instead create a new window manager which is KWin compatible, e.g. support the decorations, support the effects, support the scripts

Wow, that sounds like gigantic project, making sure it doesn't break the panel, widgets, tray, and all that stuff; and then also maintaining it, making sure upstream changes didn't break anything…

@graesslin I propose this goal, IMO tiling window managers going to be more popular and used, having it, can attract some number of users to Plasma/KDE. Currently there are not many Wayland tiling wm, supporting it can be key in transition from X to Wayland. My intention with this goal is to define full-scale system, not to just list bunch of nice tiling features. I am not developer and I don't unterstand underlying system of KWin, so I meant that is possible to extend KWin with complete tiling, but from your words that is practically impossible. Your sugesstion to create new manager (KWin compatible), seems more realistic, but the problem is maintaining it compatible with upstream, similar problems with Kwin scripts.
Many of us dream of those features, to be integral and easy accessible under Plasma. From this conversation, I don't see any elegant solution to this goal. I'm just Plasma user, I would like to this goal be achieved, but I understand that is not that cricital, important or valuable.

Some more information about the removal of tiling support in: http://commits.kde.org/kde-workspace/34027455aaa2ee738c45987ca2d8cb7d65491bf0 - it has a few links explaining the problems.

Concerning extending KWin vs. creating a new window manager. Creating a new window manager for tiling and having it KWin compatible is less work than extending KWin. Extending KWin would mean to find the right places and decide everywhere whether it is tiling relevant or not. It would need to diverge and we would have many many if tiling else stacking blocks. This was one of the problems with the old code base as it ended in the developers not running any of the tiling code and that just results in breakage. Code which isn't used is going to bitrot.

Creating a new window manager on the other hand which can reuse the non-stacking parts would be relatively straight forward. All the interaction with X11 and Wayland happens through external libraries anyway (and the main reason for KWayland and KWindowSystem to exist is that this can be reused), effects are abstracted through a library, even the compositor is loaded through a plugin. The low level Wayland parts (DRM, etc.) are all plugins. There are parts which are not plugin based like input handling. But all of that can be done and would probably also improve KWin by having better defined interfaces.

Keeping the window manager compatible is not that much of an issue in the C++ code base - KWin code breaks, of course, but it would just require to be released together.

@graesslin
Martin what is you opinion about integration of "smart tiling" (T11086 into KWin? Is it hard to do with current codebase?

In T11067#190658, @Eiden wrote:

@graesslin
Martin what is you opinion about integration of "smart tiling" (T11086 into KWin? Is it hard to do with current codebase?

Yes, I considered it as hard, otherwise it would already exist. Also I think it's a bad idea. There are very good tiling window managers, there is no point in doing poor man tiling - Windows where that came up has to, but on Linux we can actually run tiling wms. I think if users want tiling they should use tiling instead of getting half baked solutions. Also I don't see the "everybody else has this" as a an adequate reason.

@graesslin
It's true that KWin shouldn't have every feature under the sun but I and a lot of users found "smart tiling" actually usefull (just look at the popularity of "Sticky Window Snapping")
This feature perfectly extends "window snapping" (especially on FullHD and HighRes where halves/quarters sometimes may not work and you'll need to align both windows).
IMO, tiled window managers is completely different workflow and not for casual users.

Why not instead of trying to make KWin a tilling windows manager, not try to make Plasma better integrate with third party windows manager (under X11 and Wayland)?

@ognarb there's no WMs on Wayland, so there's nothing to integrate with. You may ask, can we integrate with an X11 WM instead. Well, I may be wrong, but AFAIK on X11 any application can manage any window, so implementing that API will make any app to be in control, which may be a security problem. (though informally people may use terms "WM" and Compositor interchangeably for Wayland, but since you asked a technical question — that's technically wrong, there only are Compositors)

I think if users want tiling they should use tiling instead of getting half baked solutions

@Eiden already commented on that, but to add some details: tiling mode is, well, a separate mode. Making use of it requires certain skills such as touch-type ability. This means that you can not say to your "stacking" users, who like being able to drag a window to a screen edge to make it half-screen, to go use tiling mode. These are different peoples, different users.

The linked task is a "stacking mode users" feature.

This probably isn't the most common use case, but it's one that I've definitely used to some extent and wished for a bit more granularity in.

Consider workflows with windows that have odd geometries and control layouts, like a lot of audio vsts/plugins. Usually the whole window doesn't need to be visible to access all the necessary controls, so stacking and overlapping serves as a useful space saving measure, even when the workflow is very similar to using a tiling window manager. This can't be done on a traditional tiling window manager because overlapping windows simply isn't within their design goals. How I've done this usually is to make course alignment movements with quick tiling (move to workspace, set monitor, set quadrant) and then do fine alignments manually. More granularity beyond just setting quadrant would make the last manual adjustment step significantly faster.

Even outside of this rather demanding use case, simply having more granular control over window geometries and placement from a tiling approach is personally very convenient, especially for larger monitors with many windows open. It lets you avoid relatively expensive (time wise) manual cursor based window geometry adjustments while maintaining the ability to have multiple non-concurrently-used windows in the same screen area (for example, spotify can probably hide behind vim since it would be a mental context switch to use it anyway.)

I don't think kwin needs full tiling support where adding a window changes the geometry of all/any other windows, but greater control over where a window goes and a more robust quick tiling interface would at least resolve this specific use case.

Some more information about the removal of tiling support in: http://commits.kde.org/kde-workspace/34027455aaa2ee738c45987ca2d8cb7d65491bf0 - it has a few links explaining the problems.

Ok, thanks, and sorry for taking so long to look at it.

The commit refers to this discussion and to a bugreport which too refers to the discussion. None of the links has any mention of conflicts with "stacking concepts" that you mentioned, and I so far can't imagine them either (in the end of the day the kwin-tiling extension is a proof that it works).

The reasons tiling was removed:

1. None of KWin devs has any idea of how tiling supposed to work (mentioned here, in the quote)
2. Because of 1 and also that KWin devs didn't use tiling, it was broken and unmaintained.

Well, if nobody knew how tiling supposed to work, then it's hard to tell whether the conflicts you mentioned, whatever they were, are really non-workaroundable ☺

Can we reframe this in a way that explains how we're going to make the world better? What story are we going to be able to tell once it's done? How is the world going to be better?

In T11067#190977, @hiangel wrote:

Well, if nobody knew how tiling supposed to work, then it's hard to tell whether the conflicts you mentioned, whatever they were, are really non-workaroundable ☺

I was the maintainer back then and I think you can/should trust what I say about it.

In T11067#192491, @graesslin wrote:

In T11067#190977, @hiangel wrote:

Well, if nobody knew how tiling supposed to work, then it's hard to tell whether the conflicts you mentioned, whatever they were, are really non-workaroundable ☺

I was the maintainer back then and I think you can/should trust what I say about it.

Sure, but we here still don't know what those conflicts were, and given this task is about a tiling WM, it sounds possibly important information.

In T11067#192498, @hiangel wrote:

Sure, but we here still don't know what those conflicts were, and given this task is about a tiling WM, it sounds possibly important information.

I hope you understand that after several years I don't remember all details. What I remember is:

• we had several breakages in both directions, so many that we decided to remove this again
• the experience was the main reason for creating https://community.kde.org/KWin/Mission_Statement - several phrases are chosen especially to catch a case like tiling, e.g.:
  • it works together with all existing features
  • it supports both single and multi screen (xrandr)
  • it is feature complete, that is supports at least all useful features from competitive implementations
  • it is not a special case for a small user group
  • it does not increase code complexity significantly
• All those points were violated by the tiling implementation, part of it was due to the implementation (e.g. the missing multi screen support), part of it was just the fact that it was tiling in a stacking window manager
• The rework of the scripting API was mainly motivated by the experience of tiling support in KWin. We wanted to provide the functionality to add something like tiling without having to touch KWin core.

There are some obvious issues when trying to add tiling support to a stacking window manager. A tiling window manager has to enforce size and position. Contrary KWin is very proud to be ICCCM compliant and honors the requested size and positions of windows. This is for us in KWin kind of a holy grail, we would never consider to break the specification. But for tiling we have to. Another area of problems are window decorations, which ideally do not exist in tiling or are handled quite differently. Yet another problematic area are global shortcuts. For tiling they are a must have and very special, it was a huge problem to have global shortcuts listed like "Move window left" which did not work in a default setup and required manual changes when enabling tiling.

Overall it was just a bad idea and didn't work out. Any i3+plasma user had a better experience and I think it's much better to go for i3 or sway+plasma instead of modifying KWin. I love KWin, I love having many people use it, but nevertheless I recommend using i3 if one wants tiling. It does a better job than KWin could ever do due to it being designed for it.

In T11067#192499, @graesslin wrote:

In T11067#192498, @hiangel wrote:

Sure, but we here still don't know what those conflicts were, and given this task is about a tiling WM, it sounds possibly important information.

I hope you understand that after several years I don't remember all details. What I remember is:

• we had several breakages in both directions, so many that we decided to remove this again
• the experience was the main reason for creating https://community.kde.org/KWin/Mission_Statement - several phrases are chosen especially to catch a case like tiling, e.g.:
  • it works together with all existing features
  • it supports both single and multi screen (xrandr)
  • it is feature complete, that is supports at least all useful features from competitive implementations
  • it is not a special case for a small user group
  • it does not increase code complexity significantly
• All those points were violated by the tiling implementation, part of it was due to the implementation (e.g. the missing multi screen support), part of it was just the fact that it was tiling in a stacking window manager

Okay, so, to make it clear: all these points say is how tiling was implemented in KWin. For example, if tiling didn't support multiple screens, that sounds bad. i3 supports that well, even better than a stacking manager would (the idea is to bind screens to desktops. It isn't specific to tiling, but in tiling some kind of "fast access" is forced upon you, whereas in stacking WM you don't know what to do unless you look that specifically up).

There are some obvious issues when trying to add tiling support to a stacking window manager. A tiling window manager has to enforce size and position. Contrary KWin is very proud to be ICCCM compliant and honors the requested size and positions of windows. This is for us in KWin kind of a holy grail, we would never consider to break the specification. But for tiling we have to. Another area of problems are window decorations, which ideally do not exist in tiling or are handled quite differently. Yet another problematic area are global shortcuts. For tiling they are a must have and very special, it was a huge problem to have global shortcuts listed like "Move window left" which did not work in a default setup and required manual changes when enabling tiling.

You don't need to consider tiling as a violation of specifications. Let's look at what right now happens in KWin: a window appears at a requested position, and then a user starts moving it around or resizing. Now, if a user requested tiling, this means they asks the WM to automate what they usually would do manually. In this case considering this a violation would be the same as considering the manual work by user a violation.

Overall it was just a bad idea and didn't work out. Any i3+plasma user had a better experience and I think it's much better to go for i3 or sway+plasma instead of modifying KWin. I love KWin, I love having many people use it, but nevertheless I recommend using i3 if one wants tiling. It does a better job than KWin could ever do due to it being designed for it.

Do you think it would be possible to use Sway with plasma? Note that this is wayland. What needs to happen for that?

According to this blog post by the sway main dev after a KDE sprint it should be possible:

The upshot of this is that we believe it’s possible to integrate the Plasma shell with sway. Users of KDE on X11 were able to replace kwin with i3 and still utilize the Plasma shell - a feature which was lost in the transition to Wayland. As we continue to work together, this use-case may well be captured again. Even KDE users who are uninterested in sway stand to benefit from this. The hacks Plasma uses today are temporary and unmaintainable, and the improvements to Plasma’s codebase will make it easier to work with. Should kwin grow stable layer-shell support, clients designed for sway will work on KDE as well. Replacing sway’s own similar hacks will have similar benefits for our codebase and open the door to 3rd-party panels, lockscreens, rofi, etc.
I spent my time in their care working on actual code to this end. I wrote up a C++ library that extends Qt with layer-shell support called qtlayershell , and extended the popular Latte Dock KDE extension to support it. Though this work is not complete, it works - as I write this blog post, Latte is running on my sway session! This is good progress, but I must return my focus to wlroots soon. If you are interested in this work, please help me complete it!

So far this is not ready for voting? Do we abandon it or reshape it so it gets ready? Once it's in shape please move it to the ready for voting column.

Quick reminder that there are two days left before the voting starts. Please make any changes you still want to make soon and let's move it to the ready for voting column.

[spam comment removed by sysadmin]