when I do suggest a portable solution (like a browser-based tool), I get that "I want a native application instead."
OK, this thing. I really don't see why one is castigated for not wanting to compromise one's experience. Given a nice-looking app and one with the exact same function but a poor GUI, why is it a crime to prefer the nice one?
Have you taken a look at
EasyEDA? Its GUI is arguably easier and nicer-looking than any other electronic circuit design tool producing classic-format schematics and Gerbers, at least from a hobbyist or new-user perspective. Just because it runs in a browser, does not mean it has to be poor or non-nice-looking.
The ugliness of my examples (
glyphs,
FIR analysis) is purely a choice: they're just examples, focusing on showing the
functionality and possibilities, not how nice-looking you can make things in a web browser. I'd need the help of an UX specialist or graphics designer to make it genuinely nice-looking, because I'm a decade out of date on what is considered "nice". My own preferences tend to what I show on my
home page, using the very same technique (it's all contained in that single 21749-byte file); I have thought about making Tux' eyes follow the mouse cursor (á la
xeyes), but have thus far resisted the temptation.
My browser-based examples do not use any libraries or application frameworks, either, because their purpose is to show how easily one can get going, and how lightweight such solutions can be. I use EasyEDA for an example of how nice-looking they can be – but note, just as an example. I'm sure there are even better examples out there, I just haven't encountered them yet. Also note that the classic EasyEDA does not require any specific browser, either.
I understand that as a developer you want to make things once rather than half a dozen times in different ways.
Oh, no. The reason for me focusing on portability was exactly because I envisioned providing the albums here to other, non-technical users.
My own development practice is such that I test and collect "modules", algorithms and approaches, implementing and testing them in isolation; currently each one in their own folder, with a README file, and if math is involved, some documentation and Maxima worksheets to replicate the math. (I've got thousands of these.)
I've found that rather than make them library-like, I get a much better result by adapting a known-working solution I've experimented with, than using one as-is. (Also, I nowadays tend to think the operation through first, then examine the hardest-to-implement details in this "module"/"unit" fashion, before I start creating the application itself.)
Thus, portability itself is not a goal for me in general. Is only one tool among many for me. It is like software licenses to me: I use the entire range from CC0-1.0/Public Domain to GPL to completely proprietary, and have even signed some NDAs. Also, I often rewrite my code to adapt it to new use cases, so I'm definitely not the type to write stuff only once!
In my opinion, after having implemented such tagged image galleries (and image analysis and commenting tools) for public use, and therefore claiming I have actual practical experience on this (anyone can contact me with a PM for details of projects), I do believe that either such an application should either be "online" (not "cloud", but easily hosted on your own web services, including uploading the images there; the security and running costs of such being the critical/questionable part), or portable across operating systems, so as to not limit the users that can access the album/database.
As an example, my elderly mom uses an Android tablet, and although she's an avid picture-taker, she'd be extremely upset if she got an album she cannot view or fully use because it is Windows-only/macOS-only/non-Android and/or requires a paid program to view.
I, as one half of her unofficial IT support staff, would get the heat.
As to filesystem monitoring for auto-detecting changes in file names:
You do hopefully understand that that is no longer
an application; it is
a service that has to run all the time for it to be able to do such tracking. Filesystem events are not recorded anywhere, they are only reported as they occur. That is, there is no log you could read that would tell you the operations done since Yesterday for example, or the last time this application was running. Such a service should of course be native, for both efficiency and simplicity. I do not believe browsers are even able to do this yet, anyhow, lacking interfaces to the OS-specific filesystem monitoring facilities except for polling using the
FileSystem browser API. To be clear: I would definitely
not implement such a service in a browser!
Anyway, a solution suggestion:
Since we have (I believe!) already agreed that the biggest issue in this kind of application type is the tagging of the images –– editing the metadata associated with each image ––, why not solve the problem by using an approach that allows compatible implementations as a native service, a native application especially for easy tagging of new images,
and a browser-based portable viewer?
I'd say the service approach might be warranted for an user who uses that particular machine in large part for maintaining albums and image archives. A native application would be needed to interface to the service, and to act as a control panel of sorts to the service –– for example, to select which folder trees it will monitor.
Because of the limitations of the browser approach, tagging images would be best done in a native application. It is possible to do the same in a browser-based tool, but the interfaces for accessing local files are still limited, would probably feel cumbersome.
If the image metadata, tag definitions and per-image tags and image descriptions, are stored in a format that one can read from a service, native application, or a browser, there is no limitation to how one implements the application part. Browsers are a bit limited in this front, so it would have to be either plain text, JSON, or an easily parsed plain-text format like S-expressions, CSV, PSV, etc. While plain text formats are verbose, even if it grew to an average of 1k per image, it would still be extremely fast to process, and the size is irrelevant compared to the size of the image files it describes, so although this is definitely a compromise (compared to e.g. an SQLite database file), I believe it to be an acceptable one, considering the implemenation freedom this compromise provides. Of these,
JSON (using UTF-8 encoding) is probably currently the best option, considering both browser support, library/application support, and ease of implementing your own from scratch, as it is a proper standardized interchange format (see the link).
In other words, each album or image database would then be a single JSON file, plus a set of image files at relative paths (typically in same folder or in a subfolder). The JSON file would describe the album itself, the tags used, plus have a list of image objects, each specifying at least one image file (if more are specified, they should be the same image in different sizes), the tags that apply to it, and optionally a title, date-time, license, and a description.
If one is interested in this approach, the next step would be to consider the implementation of the database JSON file. Although I normally prefer long descriptive field names, for the per-image ones I would use short ones to minimize file size overhead. For the tags, I would use a list of strings per image: although compression via lookup (as in replacing each tag string with an identifier) can reduce the file size, I do not believe it would be worth the added complexity considering how much larger in file size each image is.
KISS.
Personally, I'd take a look at the database schema of existing open source solutions, then sketch out the target one, which I'd put out for suggestions and comments. For example, it might (but I'm not certain) be useful to split tags into say
contents and
context. Contents would contain tags that apply to what is visible in the image; context to why or how the picture was taken or by whom.