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:
Interesting and impressive! Would you be able to demonstrate what you mean with an MDI-like interface or the actual 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.
Working on how to remote control a computer over http and websocket. Meant as an interface between custom proptypes built in HTML5 and js to cut down on development time.
Got really sidetracked by starting to do my own libjpeg to nim bindings but it’s been an enjoyable day as everything started to work just now.
Working on https://www.laarc.io/ People keep saying how eerily similar it feels to HN circa 2007.
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
We’re gearing up for an actual Show Lobsters post. Emily has been one of our secret weapons; she’s like an assassin that targets items on a todo list. It’s scary watching her work. We have an iPhone app coming soon, powered by our firebase API (e.g. https://laarrc.firebaseio.com/v0/item/1.json?print=pretty)
The API is nearly identical to HN’s. https://github.com/HackerNews/API But we’ll be adding support for tags, which is one of N hundred things to do this weekend.
Very cool! What do you see as some notable differences between laarc and Lobste.rs?
I think the communities will always compliment one another. The main difference can be illustrated by example:
And personally, I find it motivating to deliver a high-quality production-grade site written in modern Arc: https://github.com/laarc/laarc
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.
Looks interesting, though I wish it would use larger default font sizes, 10 pt is pretty hard to read for the titles and have to zoom in to 125% to make it easier to read.
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.
Honest question: what need do you have for a fast terminal 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.
I am sensitive to the same.
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.
Anyway I would have a hard time believing it’s faster than xfce4-terminal, xterm, or rxvt. It’s been a long time since I last benchmarked terminal emulators, maybe I smell a weekend project coming on.
kitty is written is about half C, half Python, Alacritty is written in Rust.
There were some benchmarks done for the recent Alacritty release that added scrollback, which include kitty, urxvt, termite, and st. https://jwilm.io/blog/alacritty-lands-scrollback/#benchmarks
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 me it’s the simple stuff that gets annoying when it’s slow. Tailing high-volume logs. less-ing/cat-ing large files. Long scrollbacks. Makes a difference to my day by just not being slow.
I don’t care that much about the speed it takes to cat a big file, but low latency is very nice and kitty is quite good at that. I cannot use libvte terminals anymore, they just seem so sluggish.
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’m on macOS.
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.
They’ve updated config files with additional info about aliasing and rendering fonts on Mac. So take a look at that if you are using your old config. It’s not a bad idea to start from scratch.
Thanks for the tip! I did start from scratch and moved over changes bit by bit, but I’ll have to check the new macOS specific lines.
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.
I think that’s my exact problem (turns out I’m even subscribed to the issue haha). I use neovim so I think it is/was applicable to both
do any of those really measure up when benchmarked.
I remember doing some writing to stdout and it alacritty turned out to be slower than say gnome-terminal or whatever.
Might’ve been that there was a bug with my intel graphics card though, don’t remember to well.
Really cool! I’m doing research on low n-count. Might be a good fit.
Reminds me of Dasher.
Thank you so much for this! I’ve been looking around quite a bit for previous work. But haven’t been able to find very much.
Do you use Dasher?
Nah. It’s a method for using mouse instead of keyboard, and I’m quite comfortable typing. I’m more into methods for reducing mouse/touchpad use, so I find Vimium useful.
On the topic of unusual input methods, you might also like Eviacam which lets you control the mouse cursor with your head.
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:
*) without that endless back and forth
Chorded keyboard as in the mother of all demos:
Tree entry method occasionally gets stuck such that you can’t enter the character it wants.
Also “About” leads to nothing and you’re stuck.
In this case, trying to type a Q:
TypeError: this.content[(this.leveln + 1)] is undefined (games.js:55:12)
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.
What about capital letters and symbols?
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
Ah I’ll change the description, I didn’t really count the reset and the backspace keys as all the layouts have them.
Even if you don’t count these, it’s 6 keys.
W A S D Q F
Aha I see what you’re getting at! Thanks for the feedback again. I’ve updated the copy!
Is anybody in here actively using tree editors?
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.
Hey, looks really nice. I’m not a windows guy in that sense but looks like your onto something nice.
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.
Typing the illiad in game using 6 keys
here you’re typing with only one hand, leaving the mouse for something else.