Help requested for three big items for Lumina

In this post I mentioned some of the major work that is on the road map for Lumina, and I’ve finally made the time to expand on this a little more.

In this post I’m going to cover three of the big ticket items I need help with.

However before I get into that, a few points worth mentioning. C++/Qt experience is a definite requirement. It’s not that I have anything against Python or Go, but Lumina is written with C++/Qt, so that’s what you’ll need to know. Along with that you will need to be willing to submit your code contributions under a BSD 3-Clause.

Cmake conversion.

Right now there are a bunch of build issues on various Linux OSes because of some weird interaction between using Qmake with the .pro files and building them with make. While Qt6 is moving away from qmake and going to cmake, because of Qt drama, and the fully open version of Qt6 probably being the LTS release with 6.1… this is not an immediate need.

Also even after Qt6.1 is released, we can technically keep using Qt5 for quite a while until it’s EOL’d. However it would be nice to have this as a build option to help distro and OS packagers build Lumina with less headache.

I cant believe I just implied cmake would be less headache… where have I gone wrong in life. lol

Lumina-FM re-write

As I mentioned in the prior post, the new file manager will need to function using the QFileSystem class. Beyond that there are really only a few definite needs for a new FM for Lumina. So otherwise there’s a clean slate for us to design from. Aside from the normal design of a split design with folders in a panel on the left and the browser on the right… I’m open to ideas. That being said, we don’t be doing Miller columns, if you want that use MacOS.

So the other main needs are:

• A toggle-able UI panel that would include a slider for accessing ZFS snapshots. This is IMHO, one of the killer features that Lumina offers that no one else does. As a result this is an absolute requirement.

• The Right click menu needs to be written in a way that it’s easily extensible for actions. Obviously the default would include all the normal ones, open/open-with, cut/copy/paste/delete, create new file/directory/etc, open terminal here, etc However Id like to make an additional section like we currently have for additional actions, but to create new ones in a subdir in the sources so it’d be possible to be as easy as adding a new c and h file into the sources and linking them into the FM code. Similar to how Panel widgets for the desktop panel operate. That way they’re somewhat removed from the FM itself, and it makes it a bit easier for people to create their own and hopefully be willing to upstream them. Initially of all the options out there we could add, the ones I can think of initially would be the ‘add to archive’ and ‘extract from archive’ that we already have, and a shred option if someone has a shred utility installed on their system. (Yes this wont be effective on a ZFS dataset with snapshots, but not everyone uses Lumina on ZFS, so lets give them some secure file deletion options). I have a bunch of other ideas that I want to add in the future, but we’ve got to get the rest of the FM in place first.

• Currently Lumina displays the progress of operations in the desktop panel, I’d prefer to bring that into the main FM itself as a toggle-able panel, with the option to enable desktop notifications if a user desires. Currently the dialog is pretty basic. I was working on a more informative progress panel, but I stopped working on it once I realized that the FM needed an entire overhaul.

One thing that I’ve liked about Lumina is its customization. You can set it up the way you want. I’d like to take the oddly missing feature in most file managers and extend that to the Lumina-FM as well. Id like to have a configuration system where panels can be enabled/disabled based on the users wishes. This is easy enough to do with simply checking a config file when starting the FM to see if a user has certain features enabled. If a user doesn’t want the directory panel to show, easy, then can just disable it in a config file. If a user wants to define a custom background for the file manager, easy, they can set it in a config file. Want to have the browser start with two tabs to specific directories, easy, set that in a config file. This is work I can do myself, but obviously it’s something that someone will need to take into account while we’re working on this.

Lastly, there are a few features I’ve always wanted in a FM that I’ve not seen done, and I’m not sure if people would like it… so they’re going to be some of those user toggle-able features.

• In the left directory panel, where the directories are shown… also display the folder data size. That way someone doesn’t have to right click and select properties. To prevent system strain, I’d say that we allow a user to set an upper limit… say 500mb… and if the folder size is above that it’ll just show > 500mb. If you’re having a hard time grasping what I mean, imagine the output of du -sh * for each directory in a folder that you’re sitting in, being displayed beside the system folder in the tree panel.

• Lumina currently doesn’t save thumbnails, they’re re-generated every time you enter a directory if they’re not in ram. I’d like to enable saving this, but with multiple options. First being the classic method of saving these in ~/. I personally hate that this is done, because my user folder shouldn’t be the storage place for thumbnails. IMHO thumbnails should be where the files are located. After all there’s no reason each user should have to generate thumbnails for images/videos on a NAS. But since this is what most people are used to, this should be an option that they can choose. Second option is to create a .directory where they can be stored. That way they are rendered once, saved, and always available in that folder. Move the folder, no problem, thumbnails get moved as well, meaning they never have to be rendered again. Third option is to keep the current in place of Lumina not saving thumbnails anywhere than in memory, though we can change this to /tmp if that’s easier code wise considering the other two options.

• A longer term feature Id love to have is something similar to slookup baked into the FM itself for file searching, again user toggleable.

Lumina 2.0 Window Manager.

This is well outside my capabilities, but I do have a secret plan that I’ll explain in a bit. Ken started this work, and in some ways the Window Manager does work. You can start it, and you can load windows. But there are bunch of bugs and lots of things not completed. I haven’t looked at this code since probably late 2018, so I’m a little fuzy on what state its in. I do remember Ken saying it was only a “Few Months Away” from being done. But at that time he was working on it for a couple hours a day, so… lets guestimate 100-250 hours of effort left.

Ideally I could convince him to finish it, so someone else doesn’t have the initial uphill battle of figuring out what he finished and what still needs to be worked on. So here we are at my secret evil plan… however… by reading further you have to promise that you will keep this a secret as well. This is between you… me… and the internet. I’ve turned on sponsorships for the Lumina Project. All of the money that comes in is being set aside and will continue to grow until such time that there’s enough money to actually hire someone to finish this work.

Since Ken started it, he’s the logical choice, but with work and family life that may not be possible. However I’m sure if the number becomes decent enough I can convince his wife to convince him to do it. Remember… Happy Wife… Happy Life. ;)

However if I can’t convince his wife, then I would at least have the option to hire someone else to work on it. Or someone could just be a wonderful human being and an awesome open source developer and be interested in tackling a tough challenge.

Closing

So If you’ve got time and would like to help out, reach out and let me know. I really would like to make some progress on these items, and it’s going to take some outside help.

Special BSD Now Segment for Tom Jones to read on air in Episode 442

I, Tom Jones, do hereby apologize and consent to everyone giving me (Tom Jones) a hard time when they see me because I didn’t know or forgot that I knew that JT was the current developer of Lumina. Furthermore, as penance, I also owe JT and the show listeners some BSD poetry in a future BSD Now episode.

JT while Tom reads this on air…