I bet you thought this was a thread made to suck on Hydrus Dev's cock. HAHA, WRONG!
There's so many things about the Hydrus network that irritate the crap out of me, and it's clear that, as they're deliberate design considerations, they're not going to ever change. Therefore, I want to make my own. Problem is, I haven't really developed shit before, so I just want to know what I'm in for. Maybe I'm mistaken, but I'm under the impression that Hydrus Dev was only starting out when he began creating his as well, so maybe he could offer a few pointers, being already so far into his own project.
Anyway, here's some notes I've been making on how I might do things differently. I imagine Hydrus Dev has already considered a lot of these ideas before, so being more world-weary, and having lost that old shine in his eyes, maybe he could tell me why they're fucking stupid and wouldn't work at all.
Pyrus Database
- Store tags and other filesystem-related metadata in two separate databases for full reversibility. Since I consider reversibility so important, I think it deserves this level of security, to be stored in a more stable database of its own which gets written to less frequently and is therefore less prone to breakage. This secondary database will contain all forms of metadata the source filesystems could possibly support; not just the basics like filenames or creation dates, but also comments music tags, or even multi-purpose "description" fields. Users could also create custom keys such as "Likes" for archived YouTube or Twitter posts. Naturally, this level of data retention may seem redundant to many users, so it wouldn't be mandatory.
- Also store the full source paths of programs, or, optionally, just the final directory name. When certain files are "marked", they may all be stored (or at least symlinked) in a single internal directory with all of their original filenames. This would allow certain flash files, and even games or programs to function normally within the database. Naturally, these directories should be excluded when you start the server up. I'm thinking of a hierarchy like this.
Pyrus Client
- Develop a GUI and TUI in tandem, or if it has to be a GUI, at least don't use a terrible library that forces you to look at the hideous default GTK3 theme.
- Don't do anything absolutely fucking stupid like develop a garbage "Media Viewer" implement and integrate it so deeply into the operation of the program that other features must get held back for it.
- Allow users to create custom execs for each filetype, or even for entirely different database variables. If a user doesn't want to define another set of execs for their client, then they can simply write "rifle"/"xdg-open"/"whatever" into each field. Since we've abandoned the Media Viewer, which is used to untangle the messy jungle of a filesystem behind the curtains, we can go even more abstract and create variables for several client-specific factors to be passed as arguments for the exec.
%s might mean all selected files
%a might mean all files (this is dumb and dangerous)
%v might mean all files in the active view
and so on.
For example, and that is if that's the way the program works, an exec binding might look like this:
Bind Control-E:
exec 'Image Viewer.exe' – %v
Which, though it'd make a ridiculously long command, I don't think would have to be particularly RAM or CPU intensive. After all, this is the kind of thing ordinary file managers like Ranger do.
You could get a whole lot more complicated in the long-term by introducing a whole scripting language which can bring up windows in the client itself, or use if statements and the like, but maybe it'd be best to adhere to the KISS philosopy.
So about how stupid are my ideas?