electron

Linux, Wayland, and NVidia.

For some time, I’ve been trying to run my Linux under Wayland. It’s… always complicated. VERY complicated.

I have what people call the “unholy trinity” – Wayland, NVidia GPU (in a laptop to make things worse), and I use an Electron app (Pulsar). Pulsar is my main editor, so it’s basically “the reason I use a computer most of the time” really.

So it was a good surprise when I found out that things work… except…

Gimp.

And Darktable.

These flickered like crazy. And because they are image editors, this flickering is insane – it makes editing things essentially impossible (imagine you’re adjusting brightness and the screen is flickering between darker and lighter, and then stops… in the wrong frame, meaning you have no idea if it’s correct or not). So I tried to track the problem, and I finally have a solution (hopefully). This post will give the results, but the TL;DR; is – update your Linux (Ubuntu 24.04 is the MINIMUM version that you need), update your KDE to at least 6.2 (or use some recent desktop env with good wayland support), don’t use the Open Kernel NVidia driver, and update your Xwayland to at least version 24.0.
(more…)

By Maurício Szabo, ago

Complex testing – the saga

While I’m developing Chlorine, sometimes I need to test multiple specific implementations of lots of really complicated stuff like REPL state, connection, async stuff (as the project is ClojureScript on Node.JS, all I/O treatment is via callbacks) and the complicated nature of rendering multiple different object types on Atom editor. I had multiple regression errors, then I’ve created some “acceptance” tests (these open up a real Atom editor and evaluate commands on it). The problem with these tests should be obvious: they are slow, and I mean REALLY SLOW, and they need a real Atom editor, lots of setups, and because Atom is not really predictable on its actions (sometimes you connect REPL and it changes the focus on the editor) there are lots of unnecessary interactions on the editor just to have less false-negatives.

Now, as I told before, I’m developing Chlorine together with REPL-Tooling, a library that should contain all tooling for any editor capable of running Javascript to run a port or Chlorine. There’s still too much on Chlorine that relies on internal Atom APIs (for example, detection of the beginning and end of forms is one, detection of namespace’s forms is other) but time is passing and more and more is being moved to REPL-Tooling, and as soon as the detection of forms is on REPL-Tooling (and is stable) there should be possible to port most Clojure parts to REPL-Tooling, and then I can think on how to refactor the ClojureScript part, test it, and then Chlorine will be a very easy project to port. Also, as a proof-of-concept there’s Clematis for NeoVIM (it’s still on the very beginning and nothing much happened after I wrote about it here), and also an “electron fake editor” that I’m using as test.

Wait, What?
(more…)

By Maurício Szabo, ago