emersion

19 ms·

151.
by emersion 7y ago
Redshift works with this patch: https://github.com/jonls/redshift/pull/663
152.
by emersion 7y ago
>All these dependencies seem to be getting more or less mandatory. Note that Wayland is not a _new_ dependency. It's a dependency that replaces X11.
153.
by emersion 7y ago
NVIDIA doesn't support GBM, which is the standard for buffer allocation. Use nouveau. >The last issue could be solved with a reusable library that provided basic compositor functionality for window managers. This is pretty much what
154.
by emersion 7y ago
Yes. Note that this isn't really possible with X11.
155.
by emersion 7y ago
(Only replying to points that make sense to me) >Consistent window decorations? We have a protocol for this for compositors that want to support it: https://gitlab.freedesktop.org/wayland/wayland-protocols/tre..
156.
by emersion 7y ago
>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.
157.
by emersion 7y ago
You can try the project here: https://gitlab.freedesktop.org/mstoeckl/waypipe/
158.
by emersion 7y ago
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. ED
159.
by emersion 7y ago
You might be interested in https://gitlab.freedesktop.org/mstoeckl/waypipe/
160.
by emersion 7y ago
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.
161.
by emersion 7y ago
Note that some BSDs have a MAP_ZERO flag which makes invalid accesses read zeros instead of triggering SIGBUS.
162.
by emersion 7y ago
Note that on X11 hardware acceleration isn't enabled by default in Firefox.
163.
by emersion 7y ago
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.
164.
by emersion 8y ago
Maybe `GDK_BACKEND=wayland`
165.
by emersion 8y ago
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.
166.
by emersion 8y ago
Yes, you setup global hotkeys in your Sway config file.
167.
by emersion 8y ago
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 ter
168.
by emersion 8y ago
This approach is less type-safe.
169.
by emersion 8y ago
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.
170.
by emersion 8y ago
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
171.
by emersion 8y ago
I'd say either resort to code generation or pick another language that fits better your use-case.
172.
by emersion 8y ago
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.
173.
by emersion 8y ago
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&#x
174.
by emersion 8y ago
There are some weird parts in the Go language, yes. But since it's so small, a lot fewer than other languages.
175.
by emersion 8y ago
>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<Oth
176.
by emersion 8y ago
Each code in each goroutine is synchronous. That's what makes it simpler than callbacks.
177.
by emersion 8y ago
What's wrong with that? Go has channels thus it doesn't need futures/promises.
178.
by emersion 8y ago
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
179.
by emersion 8y ago
>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
180.
by emersion 8y ago
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.

More ›