Notices by Gergely Nagy 🐁 (algernon@trunk.mad-scientist.club), page 12

Son started to experiment with making faces. Right now "looking very angry while smiling under our nose" is the favourite.

It's adorable.

#Parenting

@indrora Oh, they do. But this one's *labeled* compose!

Not sure what keycode it sends, mind you, or if it's a built-in thing. Didn't get around to plug the board in yet.

Heh, this old keyboard here has a Compose key.

Who's bright idea was it that the Youtube app should blast on full volume when the phone is otherwise muted?

/o\

:flan_eyes_narrowed: :flan_molotov:

@obra Nope. Might need a `readCols` like the Atreus for speed, but otherwise no. And that code isn't required either, its just optimization.

Mind you, no hardware to test it on yet. I'm 99% sure it will work though, with no custom code. The ATMegaKeyboard abstraction is just lovely.

I got my first kiss from my daughter. Today was a good day.

#Parenting

@ondra @chucker I looked at WebUSB, but it required too much space on the firmware side. On a more powerful MCU, it would be a reasonable option, but not on the Atmega32u4 I work with.

It's an additional interface on top of what we already have, and... that's costy.

@liw That's one amazing idea and hostname. Please do!

I will be compiling this rant into a blog post. I'm sure I'll get pissed off again in the future, and then I can just link it instead of going on a venting rampage again. Saves everyone a couple of cycles. :p

:flan_molotov: :flan_writing:

@alcinnz @bob That works for Linux, and Debian/Ubuntu. For RedHat/Fedora and the rest, not quite. Not to mention OSX and Windows. :(

@bob Comparing to native: I'd have to bundle stuff for easy distribution. Think Snaps or Flatpacks. That increases the burden of maintenance significantly. Similar to the Electron case, I now need to care about the security of the whole bundle, not just my app. I need to update my dependencies, and so on and so forth.

It's not much different in the end. Smaller attack surface due to no browser, but that's about it.

@bob There are downsides, indeed, and it is definitely not the best choice for every case. For what I need it for, it is: older hardware have alternative (though perhaps less "nice" tools), the app does not require any internet access, and I can actively lock it down, decreasing the attack surface further. I upgrade Electron when there's a new version, upgrading the browser is their responsibility then.

One more thing about #Electron: chrome's web developer tools combined with React and Redux extensions are an amazing set of tools. I haven't seen anything like those for any of the native toolkits.

Yet, when developing complex applications, these are invaluable. They make it so easy to see what happens inside. Or even roll back. Oh dear, that is a life saver! I wish I had that with native apps.

@samir @chosafine Distribution is one thing, and Electron isn't exactly stellar there either (as soon as you start using libraries with native parts like I do, all hell breaks loose). The thing about Electron is that it allows *rapid* development, with very few constraints. Snaps and Flatpacks help with distribution, but not development, which is where Electron is the strongest in my opinion.

@tjk I don't have much data about Topre switches. Only typed on some for 15 minutes or so, didn't feel "whoa", but 15 minutes is... not much.

Mind you, for Topre to be a viable candidate for me, it would need to be on a keyboard I'm willing to use =) (split, with open source firmware as a start)

@Aerdan While I'd love to be able to write software that can be used by every user, that's practically impossible. So I go with the option that makes it usable for the majority of them, and which doesn't require development resources I do not have.

Yes, there will be people who won't be able to use it. But there will be many, who will be.

The alternative is that the app wouldn't even exist, because native is cost-prohibitive.

@Aerdan Yeah, there are a bunch of assumptions. From the data I have, those assumptions are spot on. In the rare case where the keyboard is paired with a device that would have problems running an Electron app, we do provide alternatives, but they aren't graphical (still very usable though).

As for QT: nope, for this purpose, it's not suitable. I did explore native options before going with Electron. I also have MUCH more experience with GTK and QT than with web stuff, but still went Electron.

@rocx Web apps being terrible is not a fault of Electron itself though. It does make it easier to do terrible UX things, but you can write Electron apps that aren't a nightmare to use, and won't bombard you with neither modals, nor a needlessly flashy UI.

(You can also write native apps that are completely terrible, and are a pain to use, and make you wish for WebApps where you can Stylus or AdBlock the hell out of 'em. :P)