emersion

>whole screen updates directly over the wire

Not whole screen. Whole windows.

You can use VNC, but it won't integrate well with other windows.

You can try the project here: https://gitlab.freedesktop.org/mstoeckl/waypipe/

This isn't supposed to happen. Worst case scenario, the DMA-BUF is copied internally in the GPU from hidden memory to visible memory, and then back to the CPU.

Being able to export a DMA-BUF is necessary anyway for multi-GPU setups.

EDIT: fixed a s/GPU/CPU/ typo

You might be interested in https://gitlab.freedesktop.org/mstoeckl/waypipe/

Regarding the HiDPI issue with dunst: you can try sway, Wayland works way better than xorg with HiDPI displays.

Disclaimer: I'm a sway dev.

Note that some BSDs have a MAP_ZERO flag which makes invalid accesses read zeros instead of triggering SIGBUS.

Note that on X11 hardware acceleration isn't enabled by default in Firefox.

What are your use-cases not addressed by Wayland?

The sway compositor has been standardizing protocols for screenshots, screen recording/streaming, composable desktop components and so on.

Maybe `GDK_BACKEND=wayland`

It should work perfectly with native Wayland apps.

However, Xwayland apps will be blurry. This is a harder problem to solve, but KDE is working on a solution which would work for sway too.

Yes, you setup global hotkeys in your Sway config file.

We have designed a new Wayland protocol for this kind of apps: https://github.com/swaywm/wlr-protocols/blob/master/unstable...

So yes, it's possible. I'm not aware of any existing drop-down terminal using the protocol yet.

This approach is less type-safe.

ACME clients should write the private key and certificate to a temporary file, then move it to the final destination so that the change is atomic.

For completeness, here is the reply from one of the KDE developers: https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAGeFrHA7FyqR2...

(It doesn't appear in the thread because it's been forwarded)

EDIT: and here is a blog post about EGLStreams from another KDE developer (2016): https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-...

Here is a follow-up blog post from the same author (2017): https://blog.martin-graesslin.com/blog/2017/10/plasmawayland...

Here are some (technical) discussions on wayland-devel about EGLStreams (2016): https://lists.freedesktop.org/archives/wayland-devel/2016-Ma...

Here are some recent IRC logs from #wayland, also discussing EGLStreams: https://dri.freedesktop.org/~cbrill/dri-log/?channel=wayland...

I'd say either resort to code generation or pick another language that fits better your use-case.

Then should all languages have all features?

As the author explains in the article, I don't think all languages should try to solve all problems perfectly.

As said in the article, solutions to these problems have now been implemented. These solutions _feel_ very Go-ish. Modules are an elegant solution. Adding them was a good idea.

Until we find an elegant solution for the generics issue, it's better not to have them.

There are some weird parts in the Go language, yes. But since it's so small, a lot fewer than other languages.

>Popular language missing essential feature

But is it an essential feature? I've written a lot of Go code and I'm perfectly fine without generics. It makes my code a lot simpler, no need to abstract everything into Thing<OtherThing implementing Stuff, YetOtherThing<Thingie implementing This or That>>. By the way, C doesn't have generics.

If you really need generics that badly for your use-case, nothing stops you from using another language.

Each code in each goroutine is synchronous. That's what makes it simpler than callbacks.

What's wrong with that? Go has channels thus it doesn't need futures/promises.

Macros are another can of worms. Even if they're AST-aware like in Rust, you can do very complicated stuff with them and they are very hard to read/write/debug. This would kill the advantage that it's very hard to write obscure Go code.

>Some that burn me a lot is support for future/promises

This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutines to execute multiple tasks at the same time. That's a big part of what makes Go simple: it's a lot easier to understand sequential code than spaghetti callbacks and promises (it's somewhat similar to async/await in the JavaScript world).

I don't think so. The article explains also that generics as implemented in other programming languages bring a lot of complexity and that generics aren't mandatory.

It's not strictly speaking "standard library containers", but rather "builtin containers".

You'd have to use an equivalent of `void *` (for Go, it's the empty interface: `interface{}`). However in 99% of the cases the builtin slice and map data structures are enough.

Same as regular URL hash I guess? (Browsers tend to wait a little if they don't find the target)

Is there a way to convert a regular PR to a draft PR?

Indeed, GL is not a Wayland requirement. The core protocol only requires the compositor to support wl_shm (shared memory). Some compositors have a software-only mode (e.g. Weston, and you mentioned KWin).