Plugging away on an experimental interface to our conferencing app, one that places the windows into an MDI-like interface. We bringing on some UX “experts”, so we’ll see what they think. It can get confusing for folks when their video windows are scattered about the desktop. Maybe this will help.

If you wanted to know what I worked on in a past life, check out this insteresting and pretty accurate article on Looking Glass Technology and Ultima Underworld, my last game dev project:

It’s pretty easy with Qt. Our app, a video conferencing app, has a main UI window and, when in a meeting, creates a window for each video feed (which can be up to 32 or more - honestly!). I just created a new mainwindow with an QMdiArea widget in it and then just add all the others windows as QMdiSubWindows instead of right on the root window. Works pretty nice and keeps things easier to manage. I may experiments with leaving the main UI window outside and just create the MdiWIndow to contain video feeds when you join a meeting as well.

There’s been an influx of new members seemingly out of nowhere each day. And they tend to be some of the best hackers I’ve met. JungleCat’s “scent map” pathfinding technique is particularly impressive: https://www.laarc.io/item?id=285

There are a bunch of easter eggs scattered throughout the site, which users seem to like. And setting up a discord server turned out to be super important for building the community. https://discord.gg/qaqkc9z

The world is starting to notice that writing webapps in React or Vue can end up being an order of magnitude more work. Elixir is doing some pretty wonderful work with realtime serverside re-rendering. Arc has had this since the very beginning. And you get some amazing features like thread-local variables.

You know how in Express you have to pass around req and res everywhere? In Arc you can just write (the-req*) to get the current request. Many functions have been rewritten to take advantage of this. For example, the authentication code is one of the simplest you’ll see anywhere: if you call (get-user) with no arguments and it returns nil, the user isn’t logged in. If (get-auth) returns nil, that means the user visited a link like /logout but it didn’t have the proper /logout?auth=<hash> code, so therefore the server should ignore the logout attempt. And so on.

But really, the most exciting part of laarc is the people. Everyone has so many neat personal projects, and everyone is so nice. It’s a spirit I’ll be embedding into the site’s soul.

Looks really cool. I’ve somehow gotten the idea that HN is inflated by people who are doing social media campaigning to get to the front page for advertisement. In more or less honest way. That’s what I like about lobsters it simply feels more authentic somehow.

I’d be interested to see a side-by-side comparison of kitty to alacritty. In particular, I’ve been using alacritty at work for a while and while it’s barebones at the moment, it’s exceptionally fast (which is probably my core feature for terminal emulators). That said, kitty looks like a fine emulator.

I have a minor obsession with input latency and scroll jank. It seems to creep up everywhere and is hard to stamp out (Sublime Text is a shining counterexample). I noticed a bit of weird input latency issues when using Terminal.app (purely anecdotal), and haven’t seen the same thing since using alacritty. So that’s the need I have for a fast emulator, it enables a smooth input and output experience.

This is what kept me on Sublime Text for years, despite open source alternatives (Atom, VS Code and friends). I gave them all at least a week, but in the end the minor latency hiccups were a major distraction. A friend with similar sensitivity has told me that VS Code has gotten better lately, I would give it another go if I weren’t transitioning to Emacs instead.

I sometimes use the Gmail web client and, for some period of time, I would experience an odd buffering of my keystrokes and it would sometimes completely derail my train of thought. It’s the digital equivalent of a painful muscle spasm. Sometimes you ignore it and move on, but sometimes you stop and think “Did I do something wrong here? Is there something more generally broken, and I should fear or investigate it?”

Web-based applications are particularly bad, because often they don’t just buffer, but completely reorder my keystrokes. So I can’t just keep typing and wait for the page to catch up; I have to stop, otherwise I’m going to have to do an edit anyway.

I just did a few rough-and-ready benchmarks on my system. Compared to my daily driver (xfce4-terminal), kitty is a little under twice as fast, alacritty and rxvt are about three times as fast. If raw speed was my only concern, I would probably reach for rxvt-unicode since it’s a more mature project.

Alacritty is too bare-bones for me but I could be sold on kitty if I took the time to make it work/behave like xfce4-terminal.

I like xfce4-terminal, but it renders fonts completely wrong for me. It’s most noticeable when I run tmux and the solid lines are drawn with dashes. If I pick a font where the lines are solid, then certain letters look off. It’s a shame, because other vte-based terminals (e.g. gnome-terminal) tend to be much slower.

For one thing, my workflow involves cutting and pasting large blocks of text. If the terminal emulator can’t keep up, blocks of text can come through out of order etc, which can be a bad time for everyone involved.

I used alacritty for a while, then switched to kitty as I’d get these long page redraws when switching tmux windows—so kitty is at least better for me in that regard. Both have similar ease of configuration. I use tmux within both, so I don’t use kitty’s scrolling or tabs. The way I was using them, they were more or less the same.

I’m going to try alacritty again to see if it’s improved. I’d honestly use the default Terminal app if I could easily provide custom shortcuts (I bind keys to switching tmux panes, etc).

I came back to Alacritty on MacOS just the other day after trying it last maybe 6 months ago and finding it “not ready” in my head. It’s been significantly updated, there’s a DMG installer (and it’s in brew), a lot more polished overall and it works really well and really fast. No redraws in tmux switches. Weirded redraw artifiact while resizing main window, but snaps to fixed immediately you stop, and doesn’t bother me much. Using it as a full-time Terminal replacement right now, liking it so far, will see how it goes!

Good to know! I’ve installed it via brew now and double-checked my old config. My font (as in, not the default Menlo. I’m using a patched Roboto Mono) looks a bit too bold, so just gotta figure out what’s wrong there.

Cool, thanks for your input! I also use tmux, and I haven’t seen anything like what you described (I also don’t really use tmux panes, only tabs). I know there has been a longstanding vim + tmux + osx bug as well, but I haven’t used vim proper in a while.

mm Vimium has been a great source of inspiration for me! I think there exists a fork that lets you control it with your left hand only. Basically I am trying to solve the same problem, but from a different angle. Instead of having the keyboard do all things, my idea is to limit the keyboard to half the size. No more back and forth.

Please head to the site and click subscribe if you want updates! I have some new things that I want to add.

Also I’m quite curious on what the audience is interested in. I have a thousand ideas but I suspect that what you guys are looking for is a fraction of those things. Without communication it’s so hard to figure out what people are looking for.

Personally I am looking for two things:

to be able to code from my coach

To be able to use my mouse for tweaking settings in developer tools and to type code with my left hand *

Also the description for treeboard is wrong; it clearly uses more than 5 keys.

I kinda wanted to build a one-handed keyboard with <= 10 keys, or maybe a split keyboard with 8-10 keys on each hand, but I came to the conclusion that it just can’t ever match a normal keyboard in speed. Unless, perhaps, you count chording. But I’m not comfortable with dictionary based entry that needs to be trained for the thing you’re typing. I once watched a programmer demonstrate their chording keyboard, and it was so awkward watching them trying to recall the chords they probably made up half an hour ago.

This hits the nail on the head. No tool other than the traditional keyboard has every letter available immediately, repeatedly, and in combination with other keys for the more unusual letters. Any “true violin” would need to improve either the speed or diversity of access without compromising the others.

Things will probably get different in a suitably touchscreen or VR world, and different tools will have advantages there, but not in meatspace with hands. You just can’t improve drastically on some designs, unless the context for their use changes too.

Nice to hear that someone has similar interests! I’d love to get in touch with you to discuss this even further if you can find the time!

What bugs me quite a lot while coding now a days, is that I have to constantly move my right hand from the keyboard to the mouse. Especially when doing web development.

Chorded keyboards obviously have to go. Still when writing within a special subset of text, say coding word prediction might come in handy. Especially when doing coding then you can to an almost absolute certainty know which symbols are available (function names, keywords, variables…) so prediction becomes really accurate.

Obviously I left word prediction since that kinda would kill the spirit of the game in a sense, but in specialized areas it might come in handy!

Thanks for the feedback I’ll try to iron out those bugs right away!

Ah I’ll change the description, I didn’t really count the reset and the backspace keys as all the layouts have them.

Yes, I’ve thought a fair bit about chording myself obviously.

As far as capital letters are concerned, I decided to skip them for simplicity. There are a few lines of code that lowercase all the letters to make the game easier to get started with. I would prefer a version where the model is universal so that you don’t have any shift / caps lock functionality but I suppose that in an actual for work product might have at least have the option to switch between lower and upper case trees.

Note that the classical keyboard also doesn’t register the difference between upper and lower case text. This is particularly apparent when writing the illiad in greek :D

Last day at work today for the year! Going on vacation with the family and while doing that putting some finishing touches on Yori for v1.0. As much as it pains me to be writing native Windows “df” and “du”, I know I need them and will use them for many years, so may as well hammer them out. Also still straightening out kinks in the “monolithic” version where all tools are linked into a single binary like busybox/cmd; I don’t like it architecturally, but it is kind of convenient to be able to copy a single binary onto a system and go.

My obsession for the last three years have been trying to reinvent text input. Somewhat a crazy task but I’m in the process of tying it up. Obviously you’ll perform much better with the keyboard that you’ve practiced with for ten years, but to make users up to speed I’m making the learning process into a game.

The reason for all this is VR. Running around with a keyboard doesn’t sound to realistic having chorded keyboards is nice and all but good luck learning all users 60 chords just to start typing.

The idea is to use gamification to get a lot of testing and statistical feedback as well as to see how well users can be thought a couple of different layouts with a few configuration options.