Are you still using Windows operating systems and products? Well, you're an idiot, IMO. It's 2023 and time to move to something better (id est, a UNIX-based or compatible system, such as GNU/Linux or Mac OS X).
Having played around a bit with KeePassXC's CLI utility (keepassxc-cli) this morning, it appears to support sufficient functionality that I can build a TUI utility to interact with it (keepassxc-tui), provided the language I choose has both the ability to interact with CLI apps, including capturing output (subprocess or similar) and TUI functionality built in or libraries to enable that (ncurses, notcurses, etc.) Having not looked at the code yet (because I don't know C++), I'm assuming that the Qt-based GUI app does that. (If the developer of it is clever, it will. Otherwise, the CLI tool's functionality is duplicated in the GUI version, not that that's likely to matter to me.)
That's a good thing, IMO, since it will likely save me some work (not having to recreate the GUI/CLI apps' functionality in a TUI version). The only real challenge, as I see it, is getting the existing CPP code to compile into native binaries and libraries that work on GNU/Linux. Not having to compile a GUI version decreases the complexity of that process, since I need only concern myself with the CLI code (which will likely be a lot simpler and in need of fewer changes, if any). It also relieves me of the requirement to fork the KeePassXC codebase, since I can build the TUI utility as a separate project that will only need updating when I fix bugs within it or modify it to stay compatible with any changes/feature additions in the CLI tool. That's great news for me, IMO.
At this stage, my next step is to download the code from the GitHub repository and see if it will compile with gcc. If not, I'll have to learn C++, fix any errors that result from compilation and debug the version built on GNU/Linux once I've got a binary. After that, building a TUI version that interacts with the CLI utility (and looks like the GUI version as much as possible) is the next step. (I'm thinking of using Python and uniCurses or urwid, then recreating it in Nim if there are any speed bottlenecks. I might end up learning C/C++ and using NDK++ or PDCursesMod to create a Windows port, but probably not.)
Having that should expedite my complete transition from Windows to GNU/Linux, since there are only a handful of other Windows applications (Chromium-based Irridium Browser, JetBrains DotPeek, MS Teams, a few things that run on Steam) I use that don't have ports or adequate equivalents on GNU/Linux, as far as I know. Hell, if I get good at porting/recreating apps, I can always try my hand at forking ungoogled-chromium and Firefox (which, as far as I know from using minimal WMs on Debian, aren't closely-coupled to any particular GUI framework or toolkit). Others have managed to do that, so it's not beyond the realm of possibility.
PortableApps for Windows is a thing, so why not for GNU/Linux? (AppImage format comes pretty close, although I far prefer not to bundle everything in one archive, since the way *NIX handles separating libraries from the things that use them and putting them in a shared location is far better than the Windows approach.) I'm getting ahead of myself and moving the goal posts (likely in the wrong direction), though ...
Update
I have now managed to get KeePassXC to run on Debian/Ubuntu, using Flatpak/Flathub (but not snapd, because the snap system clearly sucks ass, as I suspect I_g_o_r does, from reading his BS comments), so all of the above is likely moot. I still have to confirm that all of the functionality works as expected, but I think this is a step in the right direction. Creating a TUI to interact with the CLI version of KeePassXC is still an option, but one I'll put on the back-burner and file under "Want to", rather than "Need to".
Post thumbnail: Screenshot of interacting with keepassxc-cli on Windows, using cmder
