It can't work like that because it'd change the behaviour of everyone's existing toolbars, and break the default behaviour which is one label per file, where selecting a new label replaces the old one.
Labels are typically used to change how items look, and the changes they make are usually mutually exclusive.
Applying more than one label to the same file is an advanced/esoteric thing. Really, the only reason support for doing that exists at all is for the Status Icons system, which was built on top of the Labels system.
If you want to do esoteric things, sometimes it requires a bit of scripting.
If labels are being used for some other purpose, like categorising and searching for files, Tags, Keywords, or Descriptions may be a better fit.
Ah yes, I realize now.. the keywords ADDLABEL TOGGLELABEL are already used to switch behavior of SETLABEL. Using them would screw existing toolbars, definitely not what we want. o)
We could use XADDLABEL, XREMOVELABEL, XTOGGLELABEL then. Not optimal, but maybe still better than the SETLABEL="mylabel" SETLABELTOGGLE ADDLABEL combination, it reads like a code from 007. o)
Yep, I was thinking about that for Labels somehow. It seems a nice fit to set individual attributes to an item (since there is support for multiple mode o). The Tags string can't do that (without scripting) and what is "Keywords", you mean within Tags I assume? And Description, it's basically the same as Tags, isn't it? For the latter, there is also no dropdown support and no editor to categorize/bundle tags etc.
It would be nice if one of the multiple implementations of "setting custom attributes" would be complete.
Have a nice weekend! o)
Not sure about the name of the switch though, SET and REMOVE in one word, it kind of contradicts each other and does not help to cleanup the naming scheme of the existing switches and options in Properties command.
Since ADDLABEL and TOGGLELABEL are already used, maybe just don't use "LABEL" in these keywords again? Properties LABEL="mylabel" REMOVE/TOGGLE/ADD looks much cleaner.
Or moving label stuff into SetAttr, it seems a more logic place for handling labels than in Properties?
Adding features and options into the existing scheme seems difficult and barely possible without adding new confusion or hard to name/understand multi word switches?
Just some thoughts, appreciate the new functionality and any effort! o)
I wouldn't claim the retrofitted names and semantics are perfect, but SETLABELTOGGLE (which makes the SETLABEL argument TOGGLE things) has been around for over six years now. Calling the new thing something other than SETLABELREMOVE (which makes the SETLABEL argument REMOVE things) would probably only confuse things more and make the related arguments harder to find in the manual.
And, again, this is pretty niche stuff. Most people, and the default toolbars, won't encounter it at all.
Yes, I see why SETLABELREMOVE kind of fits the current semantics. It is a good choice considering the current naming situation. o)
Don't mind me thinking about the naming, it's like solving cross words at times. o) Naming things right can help to break down seemingly complex things into digestible pieces. This is "niche stuff" you say, which is a little unfortunate. I already mentioned why some things of the labels functionality is hard to get or hard to remember, maybe it wouldn't be so niche if it had less peculiarities? That said, it is pretty hard to get perfect and future proof naming and irregularities always add a human touch to technical things, so it's not necessarily a bad thing - we would not have this talk for instance! o)
Yes, SetAttr seems like a better home for applying labels to files. Plus I have more than one script that uses SetAttr and Properties right after another, so having all in just one command would probably speed things up.
And how about using prefixes like + and - for ADD and REMOVE (and nothing for TOGGLE), similar to how tags are handled?
The parts of Properties that manage labels, generate menus etc. could get a command of their own, but...
... is true, too. So something for the time when this area gets some major other changes
Scuse me sirs! If i do: Properties SETLABELREMOVE test, it opens file properties. Same thing happens if i do: Properties SETLABELREMOVE test ADDLABEL. How exactly is this new command specified?
This is my addlabel command: Properties SETLABEL test ADDLABEL. "test" is the name of the label. This adds the label correctly. The file may have multiple labels assigned, so i'd like to remove a specific label with the new command.
So the command looks like this: Properties SETLABEL test ADDLABEL SETLABELREMOVE
By the way whats the difference between SETLABEL test and SETLABEL=test? Which one is more appropriate?
@Leo
Dear Leo, i suggest adding an example line in the manual under this: Example:Properties SETLABEL=Bold ADDLABEL SETLABELTOGGLE
Like: Example:Properties SETLABEL=Bold ADDLABEL SETLABELREMOVE
So if someone searches for SETLABELREMOVE in the manual it can be found.
There is already an example in the manual. (n.b. The manual that comes with the program, not the web version which hasn't been updated yet and doesn't mention SETLABELREMOVE at all yet.)
You don't want ADDLABEL there either, at least according to the example in the manual.
There is usually no difference, but it's better to use = all the time if you don't want to think about it.
The one exception is for special "raw" arguments, where the entire rest of the command line is fed to them, without needing quotes even if things contain spaces, and where anything that looks like another argument won't be confused for one. Those are rare and a special case where you wouldn't want to use an = sign.
I've made it a habit to always use the = because it tremendously improves readability. Same reason why I also always include a command's default argument.
