In order to make viewer’s keyboard shortcuts configurable and Quick View feature realistic I find myself refactoring main window actions, >2k lines of code – again, I’ve already done that four months ago. This is unfortunately an annoyingly common occurrence lately. Prior to Gnome Commander 2.0 release the goal was to make things work *somehow*. Now the goal is getting maintainable and extensible code. And that means revisiting pretty much everything once again.
#GnomeCommander
Just landed on the development branch: tabbed interface for the internal viewer. Instead of opening ever new windows the internal viewer now keeps everything neatly organized in one window, one tab per file.
The viewer is now a component which can be reused elsewhere. The idea is to implement a Quick View feature: a viewer showing up in a panel, displaying whichever file is selected in the opposite panel. This still requires some refactoring of the panels however.
#GnomeCommander
RE: https://floss.social/@gcmd/116676361358232158
Gnome Commander 2.0.3 is out, fixing eight annoyances this time. Most importantly, keyboard input focus will no longer be in nirvana after clicking toolbar buttons, and overlong file list contents will be ellipsized rather than cut off. The remaining six issues are evenly split between the Search dialog and the internal viewer.
https://gitlab.gnome.org/GNOME/gnome-commander/-/releases/2.0.3
#GnomeCommander #OpenSource #Linux #FileManager
Concerning those system libraries: libvte has been an issue for the portable builds so far, the other required libraries being pretty much universally available. So I’ve now managed to package libvte with the portable builds, this should significantly increase the chances of the portable builds just working out of the box.
And the portable builds just got a little bit… well, more portable. Our plugins depend on some Python modules, and these modules are now being packaged into the portable builds. So plugins now work out of the box without requiring any changes to the system.
We still depend on system libraries however (essentially Gtk and libvte). It seems that libvte in particular might not be pre-installed. The builds now contain a README file explaining this and listing the distribution packages to install.
We finally have zero compile warnings, zero clippy warnings and zero documentation warnings in the codebase! 🎉
And to celebrate the occasion CI checks for these warnings have just been added, making sure it will stay this way.
Either way, we now have this framework which is currently used for the Keyboard Shortcuts dialog but will hopefully be used consistently throughout the codebase at some point. It’s great that Relm4 demonstrates how it can be done better, and I hope that the project will see continued development.
Last but not least, there are serious concerns about the state of the Relm4 project. It appears to be in maintenance mode, not even keeping up with Gtk changes. While the core code is well though out, other parts of the library are inconsistent to say the least and often fail to follow Relm’s design concepts. So in the end it was also a question of risk: investing lots of effort into porting the code to Relm and then getting stuck when Gtk5 comes out isn’t a great prospect. ⬇️
Our code also takes some shortcuts which probably make it worse from the conceptual point of view but simpler to use. For example, parent components can access the data of subcomponents directly. We don’t quite separate code modifying the state and code modifying the view: with Gtk requiring input focus to be managed manually on far too many occasions such separation is obstructive. View updates are generally more explicit, Relm4 attempting and often failing to hide the complexity here. ⬇️
Copying an existent library is far from ideal and this step hasn’t been taken lightly. My trial balloon was the Keyboard Shortcuts dialog which I reimplemented twice: once with Relm4 and another time with our own similar library. One issue that popped up was the `view!` macro of Relm4: it tries to do everything and maximally compact, resulting in a complex syntax very unlike Rust. Our `with!` macro stays very close to Rust syntax on the other hand, making it much easier to read. ⬇️
