komokana VS Uno Platform

kanata[1] and komokana[2].

kanata is basically like QMK for any keyboard without the firmware requirement. I use kanata with my trusty old iMac keyboard which is to this day my favourite keyboard of all time. But now I have all the cool QMK-style layers with it.

So that is awesome on its own, but where it gets even better for me, and this is where the seconds have really added up to hours, is that I wrote another piece of software which programmatically changes layers on kanata whenever a different window is focused in my tiling window manager.

This has honestly changed -everything- for me. I no longer have to waste keys on my keyboard to switch layers, I no longer have to -think- about switching layers, I just focus another window with alt+hjkl and whatever keyboard layer I expect for any given application is automatically applied. Definitely one of those "you can never go back" experiences for me.

[1]: https://github.com/jtroo/kanata

[2]: https://github.com/LGUG2Z/komokana

I have an Ergodox EZ sitting collecting dust these days. I got a great deal of use out of it and before long I was compiling my own firmware and making use of various advanced QMK features that were not available through the online visual layer configuration tool.

The keyboard has great build quality, the customer service is great (I got a free replacement for the right half after an issue with one of the keys), the ortholinear layout isn't that difficult to get used to, but ultimately the issue for me was that my hands aren't big enough to use the keyboard comfortably or to type as accurately as I'd like / as I'm used to typing.

I'm now back on my Apple Magic Keyboard and happier than ever, though with a few tweaks and improvements taken from my time using the Ergodox EZ.

I am now using kanata[1] which allows me to have multiple QMK-style layers on my regular old keyboard. This is already a huge step up from my pre-Ergodox days! I also like that I can have my layer configurations version controlled in a plain old git/dotfiles repo.

Since the layers are handled at the software level, I wrote my own integration with kanata, called komokana[2] to switch keyboard layers programmatically based on different state events emitted from my tiling window manager[3].

What that means in practice is that my keyboard can automatically switch to an app-specific layer when that app's window is focused, or to a workspace specific layer, or to a browser tab-specific layer, or really just switch on any event emitted by the window manager or any specific window manager state.

For me, this is really the killer feature of my setup now, and one that I don't think would be anywhere near as easy to implement with QMK which sits at the hardware level.

[1]: https://github.com/jtroo/kanata

[2]: https://github.com/LGUG2Z/komokana

[3]: https://github.com/LGUG2Z/komorebi

Hello friends! You may know me from my previous posts about my tiling window manager and my automatic keyboard layer switcher (or maybe even my harebrained attempts to get Helix to behave more like Vim!)

With all of these pieces now in place, I am very happy to introduce komokana. an automatic application-aware keyboard layer switcher for Windows.

And Uno Platform (https://platform.uno/) is akin to React Native in terms of native controls usage.

also UNO Platform (C#) which is suitable for simple or complex cross platform business applications : https://platform.uno/

Why is this a problem? At face value, it isn't a problem. Taking a step back at a more global level, what does "uComponents" mean to the rest of the world? Many of the .NET developers who heavily use NuGet may have not even heard of Umbraco CMS, let alone a 3rd party plugin for it. What if people from the Uno Platform community are browsing NuGet for some kind of components extension library? You can see, this could get confusing outside the scope of the Umbraco community/ecosystem. On top of this, uComponents was developed against Umbraco v4, with its last release in 2016, now it's there to be lingering on the NuGet repository until the end of time, set in stone.

Not a fan of XAML after trying to get into it, but there is Uno Platform. It wraps native widgets on mobile, just like React Native (which is good for accessibility), and uses C#. https://platform.uno/

My guess is that it's mainly focused on mobile. On Windows, it has no overhead (behaving like a normal WinUI 3 app), on macOS I think it uses Catalyst by default (which was developed by Apple to make more iOS apps available for Mac desktops) and on Linux it draws its own widgets that the devs try imitating the GTK style with.

On Android and iOS, it just uses the native widgets which I think is a better experience so you can see my reasons for guessing it's mobile-first. That may or may not be what you want.

5- Uno

> ...building UIs with the document/element api

When the whole premise is flawed, JSX or not, does it really matter if there is a better or worse way of misusing a technology not meant for UIs?

Leave HTML and JavaScript to Wikipedia and other hypertext document libraries.

Unfortunately, WASM is not there yet, but people are trying: https://platform.uno.

Uno Platform is fully open source, under Apache 2.0 license. You can see the license here https://github.com/unoplatform/uno/blob/master/License.md

Also, .NET 7 brought a lot of stability so I am confident you'll have a better experience. I hope to hear back from you. It would be great to have any feedback at our repo - https://github.com/unoplatform/uno/discussions