Btw, if you do decide to make it opt-in, you don't need to surround it with the new if()…endif(). The proper way would be to replace ON word with OFF at this line:

After this patch, you'd need to add -DENABLE_CCACHE=TRUE to enable ccache - I don't really see this as a big hurdle

What do we do here then going further, am I supposed to apply a downstream patch for konsole 19.12.x?

Packagers like default switches and no surprises. If it is clear that ECM uses ccache, and it provides a standard switch to enable or disable it, then this is perfectly fine.

And packaging is disabling it.

It makes the build unpredictable and may interfere with existing ccache setups (hint: some package manager already enables ccache for all packages if asked to). It may also lead to random build failures unless the cache is cleared manually.

ccache should never be enabled by default for packaging builds.

Thanks you very much!

Though in retrospective, the title here is better than the one in commit. However lack of description and authorship here bothers me. The part that this change should not affect menu accelerators, for example, seems important.

FTR, I just remember I pushed this commit on github too, here's how it looks there https://github.com/Hi-Angel/konsole/commit/5fdedf795c98053e15f7edbc25193f57a859f8d5

Thanks everyone. I forgot to say, I don't have write access to the repository, so I'd be thankful if someone could push 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

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.

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.

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

@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)

@ngraham FWIW, I can see why you thought it's a duplicate: some code to solve this can also be shared with tiling mode. But don't let this confuse you: if tiling mode task was solved, this one still wouldn't. There is some intersection in terms of implementation, however they're still separate tasks.

In T11086#188993, @ngraham wrote:

I think this can be considered a subtask or duplicate of T11067.

@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.

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

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.

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.

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.

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. If it works with current upstream, it works for everyone, because you code is part of upstream.

@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.

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