from the Author

When it’s ready, and faster if you help.

If someone randomly comes up to you and offers you an apple with a rotten spot and you say "No thanks, there's a big rotten spot" would you expect them to scold you for being entitled and looking a gift horse in the mouth? _They_ came up to _you_ offering an apple!

you don't have to produce my style, and i don't have to buy your clothes, but it's good to talk about our preferences so you have a better idea of the potential market.

Clearly there are stronger plausible interpretations of the GP. Following that guideline tends to prevent getting caught in snags like this little subthread, making discussion more enjoyable for everyone.

(I don't mean this as a criticism! it's just a nice case to comment on because it's particularly clear.)

Which is a damn shame, because window managers are where some of the greatest innovation is happening.

innovation is happening with compositors too.

Ideally we will support both through the transition but unclear at this time.

It's support for CJK input is also basically broken with no chance of ever getting revived.

Our best bet on a solid Linux gui lies with XLibre.

However, saying that, a gui written in Go has very little reason to exist, because we already have excellent GUIs written in lower-level languages.

If there is anything Linux doesn't lack it it's desktops.

For those who want a fast to learn and use higher level language for this Go is a great tool and there are great projects out there. Two of them in the top 10 for all cross platform beating out a lot of other languages (no presence of GTK or Qt up that high... https://ossinsight.io/collections/cross-platform-gui-tool/)

For me I prefer higher level code and tooling wherever possible. Building this has been blazingly fast compared to previous window managers I have worked on.

exactly this.

go actually strikes a balance of being one of the few high level languages that can compile directly to binary. there are not many languages that can do that. common lisp, erlang, o'caml and maybe red are a few others that i am aware of. there are probably a few more that are less popular that i don't know.

for me high level implies at least automatic memory management and high level data types.

Does Fyne have bindings to other languages? A search for fyne python gave some hilarious AI slop from Gemini suggesting pip install fyne, but the fyne python package is something completely different and unrelated. The nice thing about GTK is it can be used from virtually any language (QT a bit less so but still a lot)

Why would I want something "fast to learn"? That sounds like one of the most ridiculous arguments when choosing a tool to master ever. On the level of "I chose this university because it was walking distance from home".

I'm choosing a tool I'm going to be using for the next 40 to 50 years. Whether it takes a month or a year to learn makes no difference whatever.

I want a tool language which is widely portable, so that I could run my programs without rewriting them on as many machines I own as possible.

I also want them to run as fast, as possible, because I want to run many useful programs on moderate hardware.

I want to be able to use as many libraries and external utilities as possible, because nobody knows when I might need them.

It should also work without internet, because who knows when exactly the government is going to cut the wire.

These core features are what I b would not even consider a language at all. The rest is bells and whistles. Nice to have, but completely optional.

>Two of them in the top 10 for all cross platform

I've never heard about any libraries from that list. In any case they seem like tools to write webpages, not tools to write desktop software.

You say that as if it's a good thing. The fact that our platforms depend on C and C++ is not a feature, it's a bug.