Is it possible to combine the effort under Bismuth umbrella?

[gikari]

Due to an absence of the maintainer (@esjeon) for over a year, I forked this repo and renamed it to Bismuth. Bismuth has the same features as Krohnkite, but with some additions: KCM configuration and separate Shortcuts category (will be in the 3.0 release). Also, there are plans to introduce the Plasma Applet and other stuff, that is not possible in pure TypeScript/JavaScript. There were of course some internal modernizations in the code and addition of CI. Currently, I'm porting the project from TypeScript to C++ to make the codebase consistent and easier to handle with the tooling.

I saw, that there was some recent activity and the maintainer became active. One of the users asked in the Matrix Chat, if it is possible to combine the effort on creating tiling window management in Plasma. So, is there any interest in joining forces under the Bismuth umbrella to make the greatest tiling experience on Plasma available?

[esjeon]

Hi, Gikari.

Yes, I think we can collaborate. Actually I had the same idea, but I'm too much of a loner to push it further on my side. Haha.

Due to an absence of the maintainer for over a year

Yeah, that part is kinda hurting. I got my current job about an year ago, and have struggled since.

So, is there any interest in joining forces under the Bismuth umbrella to make the greatest tiling experience on Plasma available?

My vision is slightly different. Krohnkite is not just a KWin script. It's a general tiling logic library with a KWin driver. I was hoping to be able to run Krohnkite on different environments like web, GNOME, and independent WMs. That's the rationale behind all the internal abstractions, which also coincidentally provides robustness. This also allows better testing and prevent lots of regressions, though I have never reached that part. Anyways, I want to carry this trait further and broader.

So, yes, we can combine effort and aim for the best in KDE, but I'm pretty sure we can aim higher.

[gikari]

My vision is slightly different. Krohnkite is not just a KWin script. It's a general tiling logic library with a KWin driver. I was hoping to be able to run Krohnkite on different environments like web, GNOME, and independent WMs.

This is quite an enormous task for a single person (or even for a small team). Each environment has its own specifics, that could easily get in a way and produce sudden bugs. It's a minefield.

And what tech stack it will be using? If we put the differences between various first class citizen programming languages for each platform aside (C++ for KDE Plasma, C for GNOME, JS for Web), and take JS for as some sort of common denominator, we will get the following problems:

• Each platform has its own JS environment. Browser JS engine, Qt JS engine and GNOME JS engine are different. (If you want to write unit-tests, you will have to add Node environment into the mix). It's impossible to write TypeScript, that is portable between these environments. I learned it a hard way, when dealing with the JS modules in a buggy QML environment, where if you have an error, you will just get an obscure error message, or nothing at all.
• The resulting solution will be mediocre and will require the platform specific adjustments (like writing a KCM for KDE, applet for KDE, applet for GNOME, other GUI parts etc. etc.). Why all this work, when you'll have to write platform specific stuff anyway?

Even if we had something better, combining all these complexities into a single maintainable interface is very hard, mostly impossible in my opinion. It also complicates the development process tremendously, limiting the amount of future contributors, which are as valuable as any of the shiny gems you can name the project with.

Writing a platform-agnostic solution is not actually needed. GNOME has a Pop Shell Tiling Extension, that is pretty much integrated and feels pretty nice. People are loving it and the extension is maintained by a team. No need to reinvent the wheel.

So, I think, that broadening the scope is not a good idea given the limited development resources. From the issues, reported to Bismuth I could say, that it's better to focus on providing features, missed by people, like Plasma Tray applet and advanced layouting system. If the scope is huge, we could never get our hands on implementing stuff, that is actually useful for the end user. (Ironically, it is a problem, that KDE Plasma developers have too: not enough working hands with a very broad scope. That's one of the reasons why there are considering removing Activities in Plasma 6)

So, yes, we can combine effort and aim for the best in KDE, but I'm pretty sure we can aim higher.

I am currently porting Bismuth to C++, so that all the logic can be incorporated in a C++ library (with KWin JS API bindings) and attached to KWin Script QML as a module. In the end, there will be no TypeScript and NPM tooling with it, so that Bismuth could be packaged more easily without requiring a TypeScript compiler and ESBuild. This will also make using advanced features, such is DBus communication, more developer-friendly.

[esjeon]

Hmm, maybe it was too quick to mention the multi-platform part. I'm NOT suggesting we do all the grunt work for everything. Instead, we do KDE, make it the best, and others will naturally follow if we keep the core independent.

Anyways, I just wanted to show you the big cake, but perhaps I misunderstood your style. You seem to be caring about KDE and are eager to work on GUI. I can see you're working hard to meet users' expectations. Me, on the other hand, is a former suckless guy who is into software design and architecture, and am not really bound to KDE nor GUI. I started Krohnkite as a design challenge, and I want to carry it so. I think this is where we are misaligned, but certainly the sum of our interests can cover everything we need for a good extension, which makes me positive about collaboration.

So, my actual suggestion is that:

1. Make Krohnkite a library, keeping only the core logic.
2. Bismuth calls Krohnkite, implementing platform specific logic.

Note that regardless of the collaboration, I'll be doing roughly the same thing anyway, so it can be a good idea to talk again when things are done on my side.

---

Some minor notes:

Each platform has its own JS environment. Browser JS engine, Qt JS engine and GNOME JS engine are different

Krohnkite is using only ES5. Even archaic Javascript engines from >10 years ago will be able to run it without issues.

Even if we had something better, combining all these complexities into a single maintainable interface is very hard, mostly impossible in my opinion

Nothing needs to be combined. Krohnkite is (kinda) reactive, and all it does is pushing rectangles on a certain Surface into a certain Layout. The rest is the responsibility of the caller (or it should be).

GNOME has a Pop Shell Tiling Extension

AFAICT, Pop Shell is i3wm clone. Krohnkite is dwm clone. They are quite different.

That's one of the reasons why there are considering removing Activities in Plasma 6

I hope you to understand the beauty of Surface in Krohnkite. It'll take only few lines(2?) of changes to stop supporting Activities. It also can be used to implement (1) split-screen (2+ layouts on 1 monitor) (2) multi-screen layout. This may sound wicked, but these will be useful with ultra-wide monitors and multihead setup.

[Thaodan]

I wonder since resources are so limited does it make sense to try to get into Gnome too? From my experience doing something that comes from KDE's side into Gnome is hard to impossible.

[xpufx]

That's one of the reasons why there are considering removing Activities in Plasma 6

FYI it looks like they decided to keep and fix activies related issues. By the way @gikari it looks like you decided to go with rust yourself? As far as I know someone who forked your project was trying to get some PRs into KDE/Kwin/Plasma so things would work more properly. A lot of talented and skilled people approaching this from different directions (including the go based drop in solution zentile and its fork cortile). Pretty exciting. Good luck to you all.

[I-Want-ToBelieve]

Imagine combining yabai with the core of krohnkite

[piotr-dobrogost]

@gikari It seems like your dialogue with @esjeon stopped. Are you interested in continuing it?

[I-Want-ToBelieve]

I'm a bit tired of nixos(The configuration is too perfect, completed), so I tried hackintosh

Dynamic tiling is a lack on macos

I'm now trying to bring the bismuth(krohnkite) experience to macos, waiting for my good news

[I-Want-ToBelieve]

I have successfully combined krohnkite-core with yabai.

There are still some bugs at the moment. After fixing some bugs, I will release an early version on GitHub. This should not take too long.

Kapture.2023-11-16.at.12.50.30.mp4

koekeishiya/yabai#1124 (comment)

[I-Want-ToBelieve]

https://github.com/I-Want-ToBelieve/yakite

Kapture.2023-11-19.at.11.17.16.mp4