If you know of a way for me to send the database to you, I'd love to hear about it.
E-mailing it didn't work through my e-mail client, so I tried logging in to the webmail interface, where I was told that it was too big
…but the webmail told me, I could send it using the cloud storage service, that comes along with the e-mail account
…which
also didn't work, for some inexplicable reason. (it took ages to load, consistent with it needing to upload the file, and then created a link to it …except that it was a link to nothing, and no database file was uploaded to the storage)
xnview wrote: Tue May 24, 2022 11:52 amonly a relative path is stored in the database not absolute
How is that relevant, to the issue of connecting folder importation and the "Excluded/Included" list?
Figuring out the absolute path, of relative paths, is about as easy a thing as you could possibly do, for a computer program. (using the same methods as a simple search-and-replace)
So there is no reason for there to be any problems, with figuring out the which folders one browses, that are in the "Excluded/Included" list, due to one having absolute paths and the other having relative ones, or anything like that.
you should not change method once database is created.
…which is EXACTLY what YOU TOLD ME to do!
Despite
knowing full well, that doing so ruins the database!
Many users would like to have only relative paths to be able to browse on multiple computers...
Including me, but I have been told, that XnView only uses absolute paths, making that impossible.
…and the fact that the paths shown, in the "Import folder" tab, are all absolute, re-enforced that notion.
Relative paths should always be shown as relative.
However, having one single base path, for relative paths, means that it is only possible to catalogue files/folders, that one puts in a specific base folder, and nothing else.
Having the option to set
multiple "base path"s (which, being multiple, should maybe have a different name), which can be given different names, where you can then change their "base path"s, when copying the database to another computer…
The paths (along with the names) of the "base path"s being stored, in the ini-file, and the relative paths (using the base path names) being stored in the database.
(and if a base path isn't used, then no base path should be set or shown, but instead say something along the lines of "none" or "only absolute paths")
So that, e.g., if you have "base paths" named (to choose some random names) "Pony" and "*bUrn", you could have a list of imported folders like this:
\@Pony\folder1\folderB
\@Pony\folder1\
C:\Random
\@bUrn\folder1
\@bUrn\folder2
\@bUrn\
…and also have the option to change paths from absolute to relative, or relative to absolute.
So if "Pony" is "C:\AAA", then changing "Pony" to absolute, would mean replacing the "\@Pony" with "C:\AAA" (for both the folder, as well as any and all files in it)
…and if one wants to make "C:\Random" into a relative path, you'd get a dialogue that tells you to input a name for that relative path, and then change "C:\Random" to "\@[whatever name you inputted]"
Again: This is all very simple and easy. A simple search and replace.
In fact, rather than adding a warning, when changing the base path, why not simple have XnView do a search-and-replace of the paths, to make sure that the paths are correct?
So that, when changing from "c:\" to "\", it would change any paths with "\@" to "c:\", so that they are correct, under the new base path. (naturally, this can't be done, if the ini-file is manually changed, but… (hence a warning about this, in the ini-file, would be advisable))
Or if the base path is "c:\images", and one changes it to "\", then "\@" would be replaces with "c:\images", so that "\@pic.png" would become "c:\images\pic.png".
…and also use those same relative paths (alongside absolute paths), in "Excluded/Included".
Speaking of "Excluded/Included":
What purpose does "Included" in "Excluded/Included" serve?
I suppose it's necessary to include a subfolder to a folder that is listed as excluded, but does it have any other purpose?
Actually, why not change the "Excluded/Included", so that there is a setting for whether or not a folder is included/excluded by itself, or recursively, and then set it so that XnView checks the list, before it decides to import any files/folders, with an option (in the "Excluded/Included" tab) of whether or not one wants to allow XnView to automatically import folders that aren't added as included.
That way, no files/folders would get automatically imported, outside of those under the paths one specifies in the "Excluded/Included" …unless you check the option of treating any non-excluded folders, as included, that is. (thus letting XnView import folders in the same way that it is currently supposed to)
If you do it like that, then the import folder list would serve to tell you what folders have been imported into the catalogue, and the size
…but the "Excluded/Included" list would be where you decide what folders get imported.
This would also perfectly solve the issue, mentioned in
viewtopic.php?f=60&t=43241
It's not completely ideal.
As long as you only make changes to one at a time, and copy to the next computer you use, there's no problems, but if you make separate changes, to the databases of two or more different computers, replacing one file with another would mean gaining some changes, but erasing others.
…but for a single person using multiple computers with XnView (copying a database between them), it should work out decently well.
Though I still think the folder-sidecar idea, would be a good additional option, regardless, for exporting
part of a database.
