Data visualization! Web is the go-to format for interactive data visualizations nowadays. This package is targeted at other package developers looking to integrate the abundant wealth of React-based data viz libraries into R. Check out https://quarto.org/ for an example of a popular way users publish their data analyses as reports.
(This package isn't really meant to be used directly by the typical user)
Oh wow, a familiar name from the OpenLieroX days! Do you still do any Liero related work? OLX was like peak Liero for me, at least for the multiplayer community, clan wars and all that. Lots of good times back in the 2010s.
Unfortunately, I don't really find the time anymore. It was really fun working on it, but it took an incredibly amount of time, and now my focus shifted to many other things (deep learning, family).
I probably should release some updated binaries at some point though, such that it works properly on more recent OS.
I use PowerToys just for the easy key remapping, which I wish was a built-in feature in more keyboards. Works very nicely as a simple alternative to AutoHotKey. My RSI has gotten a lot better by just remapping Caps Lock to Ctrl.
If any PowerToys feature deserves to be added to Windows, it's gotta be the Keyboard Manager.
Key shortcut remapping should absolutely be a base feature of every single OS for accessibility reasons.
Back when I used to use Adobe Fireworks there was a shortcut for flattening the current selection, I believe it was cmd+ctrl+shift+Z and I'm pressing this hundreds of times a week and eventually it gave me RSI.
After this happened I remapped it to cmd+F, luckily the app had the ability to do that but honestly I consider it important enough that the OS should provide it. I know a lot of windows users point to AutoHotKey but it's a horrible janky feeling hack and requires you to write actual scripts.
In macOS at least you can remap any key as well as keyboard shortcut (both globally and per-app) from the built in OS keyboard preferences. The only thing it requires is that the thing you want to change has a "menu item" (so a named thing in the top menu bar in any of the submenus). Hotkey mapping works by simply mapping to any of the texts in those (sub) menus, however deep you want to go. The great thing about it is the developer of the app doesn't need to do anything to allows that, and it essentially only gets broken if an app goes out of its way to be as non-native as possible (i.e. if it doesn't even use the standard libraries that ship with the OS).
This is one thing I love about Wooting keyboards. The Wootility [0] lets you drag and drop keys around your layout to remap them, and save the mappings to the keyboard itself, so the keys will stay mapped even if you move it between systems.
It’s a great feature. It doesn’t always work 100% stable though. Would love to see it put further into the OS somehow. Macos key / modifier remaps are much more stable than powertoys’.
I tend to remap caps to ctrl, for instance. Sometimes this fails, meaning that suddenly, the keyboard is stuck in caps lock mode and can’t be returned to «lower caps mode». I don’t know if autohotkey can intercept caps lock?
It still doesn’t support app-specific key remappings though (as opposed to app-specific keyboard shortcuts). This issue has been open since 2020, I’m not sure what they are waiting for: https://github.com/microsoft/PowerToys/issues/6756
Messy WIP commits that are reorganized to cleaner commits later, like most others have said.
However, instead of rebasing, I often git reset to the beginning and recreate the commits from scratch, using partial file commits (or staged hunks). IDEs/editors like VS Code make it really easy to stage an individual part of a file for the commit. The CLI way (git add -p) has always been pretty confusing to me.
Not really a midpoint, but more on a similar level to Index. Generally, people like Index more than the Vive Pros on most points (display, audio, controllers, etc.) except for the wireless capability, and some niche features like eye tracking on the Vive Pro Eye. If you want a wireless high-end headset, Vive is the only game in town (Index is wired-only) so you have to get a Vive. It'll end up being more expensive than Index because the wireless adapter is $350. Since the Vive Pros and Index share the same tracking system, people do mix and match equipment other than the headset though. Many people will buy a Vive Pro headset and use Index controllers with them, since they're better. Index users will buy Vive trackers for full-body tracking because nothing equivalent exists for the Index.
Hopefully this will start to go away soon. I learned recently that Chrome 90 (released April 2021) replaced :focus with :focus-visible in the default UA style sheet, so the focus ring will only show when using the keyboard now.
For me, the biggest hurdle has been education and awareness. At least a few years ago, the courses and resources I used to learn about web development didn't cover accessibility, and I had to learn about it after the fact. I'm glad to see more introductory resources cover it now though, like the MDN docs and web.dev.
How accessible is Grid.js? The main differentiator between table libraries for me these days is accessibility. Many libraries and frameworks out there do it poorly. The better ones are often tied to company-specific frameworks.
From playing around a bit, I've at least noticed that sortable headers have no focus indicator, the "sort column ascending" text gets included in the column's accessible name, and un-sortable column headers are read as clickable by screen readers.
I would LOVE a framework-agnostic table library that's both lightweight and fully accessible. If there's a chance for Grid.js to take this in its philosophy, I would be all in!
> The better ones are often tied to company-specific frameworks.
That is because to implement accessibility in a grid/tree widget to a meaningful level, you need a lot of underlying code. Even in modern browsers. Source: implemented accessibility in Ext JS framework.
One of the most often asked questions from users of Ext JS was: hey, can we have the Grid widget without all the bloat? Sure, and ~95% of the framework exists so that the Grid can have its features and work reliably across all the browsers. You can probably do without the rest 5%, no biggie.
I just created a ticket to work on this aspect of the library soon. I'd appreciate if you add your comments to https://github.com/grid-js/gridjs/issues/25 if you think there is any specific components that needs immediate improvement.
(This package isn't really meant to be used directly by the typical user)