A battery included hacker's file manager with VIM inspired keybind in a single binary
27 points by houqp
27 points by houqp
If only I knew what a hacker's file manager does differently than an ordinary one.
I see that it depends on accesskit. Does that mean I can use it with assistive tech? :o
AccessKit co-developer here. I just tried kiorg on Windows, and yes, it's partially usable with NVDA. I did find at least one "unknown" widget in the main window. Presumably that's a custom egui widget that doesn't yet expose any accessibility info. The tab order also includes things it shouldn't, and the main list view isn't exposed as a high-level widget the way it should be. But the latter isn't yet fully supported in AccessKit either. Regardless, this is progress. Before AccessKit, my default assumption was that an application like this would be completely inaccessible.
Before AccessKit, my default assumption was that an application like this would be completely inaccessible.
Mine as well. Thank you for your work on AccessKit, and thank you @houqp for proving my assumption wrong. May this be the first of many such cases.
100% this wouldn't have happened without AccessKit, thank you for your work on this mwcampbell. Only took me 1-2 hours to get the integration work and fine tune the experience. But a lot has changed since the integration, so the experience might have degraded a bit. Appreciate all the feedback on the existing accessbility gaps, will file an issue to track them.
Perhaps a lazy question, but how does this compare to yazi?
One thing I can already appreciate from the screenshots is that the keybindings are viewable from within the program, which is a nice improvement over yazi.
I was a yazi user for a few months, but decided to build this due to various content preview and perf bug I ran into with it. I think you can achieve a much better UX with a full fledged GUI. A lot of the layouts and shortcuts in kiorg is inspired by yazi for sure.
I know neither, but (probably similar to you) my head associated "hacker" with TUI, which kiorg is not. It's a GUI application using egui for cross-platform support.
Single binary but bajillion built-in dependencies. Still, I'm curious to compare with File Pilot which is also a single binary but a fraction of the size of Kiorg.
error: failed to compile `kiorg v1.2.2 (/Users/krig/src/extern/kiorg)`, intermediate artifacts can be found at `/Users/krig/src/extern/kiorg/target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
Caused by:
rustc 1.86.0 is not supported by the following packages:
ecolor@0.33.2 requires rustc 1.88
eframe@0.33.2 requires rustc 1.88
egui@0.33.2 requires rustc 1.88
egui-winit@0.33.2 requires rustc 1.88
egui_extras@0.33.2 requires rustc 1.88
egui_glow@0.33.2 requires rustc 1.88
emath@0.33.2 requires rustc 1.88
epaint@0.33.2 requires rustc 1.88
epaint_default_fonts@0.33.2 requires rustc 1.88
file_type@0.8.10 requires rustc 1.90.0
home@0.5.12 requires rustc 1.88
Either upgrade rustc or select compatible dependency versions with
`cargo update <name>@<current-ver> --precise <compatible-ver>`
where `<compatible-ver>` is the latest version supporting rustc 1.86.0
No shade on this project in particular, but this stuff is what I like the least about the rust eco-system. Tons of dependencies with brittle connections. Somehow in javascript land things are simultaneously both worse and better. Worse in that the dependencies are not counted by the hundreds but by the thousands (in the best case), but better in that things are so loosely coupled that most of the time it just works.