XYplorer Beta Club

Ah. The term "local" tends to remind of the local system, as in local vs network, what with your recent foray into MUT.

Well, that's right indeed. Hmmm...

Another question: should it be just the location, or include subfolders (= the branch)?

admin wrote: ↑26 Feb 2019 11:36 include subfolders (= the branch)

Yes, for sure.

OK, I agree (include subfolders).

IMO if it's difficult to find a good caption then take a simple caption. So I plead again for these (and explain the rest in the Help):
Export Local Tags
Import Local Tags

Imho thats too broad / generic.

More specific:
Export Tags to Local Folder(s)
Import Tags from Local Folder(s)

So what about this? We could used a fixed name, e.g. "XYplorerTag.dat", and then do it like this (GUI commands in bold, corresponding scripts in fixed font):

Agreed, fixed name should be used for consistency.

Export Tags To Local Database = tagexport("XYplorerTag.dat", , 3); (= store relative to tags database; don't remove from main DB)
Import Tags From Local Database = tagload("XYplorerTag.dat", 1); (= permanently merge into current DB)

After Import, the local DB survives (or should it be killed?): Prompt?

Agreed, after the export action, don't remove the exported tags from main DB.
As Sammay has said, whether the local DB should be killed can be decided by the user through a prompt. (Or there can be an option in Tools | Configuration | Information | Tags? Seems unnecessary. Prompt should be OK)

Maybe the captions should be simpler:
Export Local Tags
Import Local Tags

Agreed, I think the captions should be concise.

Imho thats too broad / generic.

More specific:
Export Tags to Local Folder(s)
Import Tags from Local Folder(s)

It's really hard to find a caption both concise and without ambiguity, though But users are not likely to use commands unclear to them. Rather, they will refer to the help manual first, so this should not be a big problem. "Export Tags to Local Folder(s)" is also with ambiguity, because that can be interpreted as "export the whold main DB to the local folder". Maybe "Export Tags for Local Folder(s)" will be better.

Another question: should it be just the location, or include subfolders (= the branch)?

Sure I would like the command to export/import tag information for all items within the project folder. However, the local DB "XYplorerTag.dat" only has to reside in the root of the project folder. I think there's no need to look for "XYplorerTag.dat" in the subfolders. (Otherwise this may cause conflict. For example, I have export a local DB within the subfolder, and later I accidentally export another local DB within the parent folder. If I run the import command within the parent folder, and look for "XYplorerTag.dat" recursively, I may find more than one "XYplorerTag.dat". Which one should I use? So looking for "XYplorerTag.dat" recursively only makes sense when the local DB stores only the tag information of items in the root of that folder, without the subfolders. But since we have decided to make "XYplorerTag.dat" contain tag information recursively, looking for it also recursively is unnecessary)

Thank you:D

Perfect. I'll have something to eat now and then go to work.

BTW, the next beta will have a new top menu "Tags". Tags are grown up now and want to move out of "Favorites".

That would be great (and more intuitive)

Menu - Tags - Export Local Tags

If you do this inside a directory for which no tags exist (neither for the directory itself, nor any file or folder underneath it),
wouldn't it make more sense to display a red status bar message that no XYplorerTag.dat was created because of no tags to export instead
of just creating it with no tags inside? Like the "Import Local Tags" does, when there is no XYplorerTag.dat file to import...

Yep, good idea!

There is one thing that bothers me...

The server has ALL files, the clients none (they tag items via a mapped network drive from the server)!

Using this setting on all machines (clients + server)
Configuration | General | Startup & Exit | Save Settings | [✔] Save changes to disk immediately
Button "Apply to..."
[✔] Tags

Now lets imagine you copy an already tagged file "1.txt" with tag "one" into the same folder on a client
machine. It gets a suffix. The Tags column updates and shows that this file also has the tag "one".

Now on the server side:
The new file "1 - Kopie.txt" is immediately visible (it's on the local file system!) but because the client,
that created it didn't trigger a "save tags" automatically, the tags column shows no entry for it.
If someone on the server would now tag it to lets say "hey - new file", just because it didn't had
a tag yet (at least on the server side) this new tag would be replicated to all other machines.

We really need a way that after a copy, delete or move "job", the tags are saved immediately as well
(as long as the Save changes to disk immediately option is active). Doing this manually would be
a pain in the ass and if someone forgets to do it and another machine that sees e.g. a new file
with no tag and tags it, would (most likely) propagate the wrong tag back to all machines...

highend wrote: ↑28 Feb 2019 22:10 There is one thing that bothers me...

The server has ALL files, the clients none (they tag items via a mapped network drive from the server)!

Using this setting on all machines (clients + server)
Configuration | General | Startup & Exit | Save Settings | [✔] Save changes to disk immediately
Button "Apply to..."
[✔] Tags

Now lets imagine you copy an already tagged file "1.txt" with tag "one" into the same folder on a client
machine. It gets a suffix. The Tags column updates and shows that this file also has the tag "one".

Now on the server side:
The new file "1 - Kopie.txt" is immediately visible (it's on the local file system!) but because the client,
that created it didn't trigger a "save tags" automatically, the tags column shows no entry for it.
If someone on the server would now tag it to lets say "hey - new file", just because it didn't had
a tag yet (at least on the server side) this new tag would be replicated to all other machines.

We really need a way that after a copy, delete or move "job", the tags are saved immediately as well
(as long as the Save changes to disk immediately option is active). Doing this manually would be
a pain in the ass and if someone forgets to do it and another machine that sees e.g. a new file
with no tag and tags it, would (most likely) propagate the wrong tag back to all machines...

Partially confirmed. With "Save changes to disk immediately" applied to tags, they are not saved immediately for items created by copy-paste action.
(I guess that the same behavior exist for "move" and "delete" actions)

Okay, I partly agree. I think it should be like this:

IF [✔] Save changes to disk immediately AND [✔] "Apply to..." = Tags THEN

ON copy > Save tags immediately IF [✔] Configuration | Information | Tags | Copy tags on copy operations
ON backup/sync > Save tags immediately IF [✔] Configuration | Information | Tags | Copy tags on backup and sync operations
ON move > Save tags immediately
ON delete > Nothing to do (the files are gone anyway)

Agreed on that logic..

One more thing: Save tags immediately should also happen if a file is just renamed but ignore this request if "ON move" already
covers a simple rename.

Okay, good point with the rename.

Done.