DO12 - ADDLABEL should REPLACE incompatible label, not "add"

In recent betas (I think) I've noticed that the usability of color labels has been degraded.

In DO11 you could easily switch colors with buttons such as:
Properties SETLABEL=Red
Properties SETLABEL=Green

In DO12, it became convenient to add ADDLABEL to these buttons so the files could also be bold, underlined etc:
Properties SETLABEL=Red ADDLABEL
Properties SETLABEL=Green ADDLABEL

If I recall correctly (and I may be wrong), until recently I was still able to switch from Red to Green when clicking the second button after the first.

However, at the moment, ADDLABEL tries to cumulate the Green to the Red. And actually nothing happens, so the file name stays red.

In DO11, a workaround would have been to use
Properties SETLABEL=!reset
before applying the new label.

But now that labels can be cumulated, doing so also removes other labels, such as bold -- not the desired effect.

In my view, for ADDLABEL, DO12 should detect if the label being added is mutually incompatible with a label currently applied (i.e., adding a color when there is already a color label), and in that case the behavior should be of replacing that label.

By the way, the documentation includes an example of
Properties SETLABEL=Green,Blue
which in my mind doesn't make sense (it just makes a green file name).

So maybe I'm missing something?
In any case, I'd like to recover the ability to switch colors without losing other labels.

Thanks in advance for any thoughts. :slight_smile:

Opus is just doing what you tell it to do, at the end of the day. Replace is the default. AddLabel is an alternative option. And AddLabel means AddLabel.

If AddLabel's meaning was changed to "add sometimes, and replace others", what should it do if some elements clash but others don't? Add or replace?

Or what if you are using labels for searching and filtering and need to apply two labels to a file even though the visual properties of one override the other? That still needs to work, so what you're asking for would have to be a separate option/argument.

What you can do already is use the categories:

Properties SETLABEL=!menu LABELCATEGORY Colors

That removes other labels from the "Colors" category when setting the label, but leaves labels from other categories alone.

Hi Leo,
Thank you, I had missed that.
Properties SETLABEL=Red LABELCATEGORY Colors
seems to work.

:thumbsup:

Follow-up question: with buttons such as
Properties SETLABEL=Blue LABELCATEGORY Colors
I can first set the label to Bold, then add Red, then change it to Blue while keeping the bold.

When I add SETLABELTOGGLE, I'm not able to remove the Blue:
Properties SETLABEL=Blue SETLABELTOGGLE LABELCATEGORY Colors

In fact this label, applied after Bold, will kill the Bold.

Am I missing something?

From a quick look, that seems like a bug/limitation of SETLABELTOGGLE. We can improve that in the future.

Terrific, I'd love that.

This is actually working by design; if you want to preserve existing labels you need to add the ADDLABEL argument as well:

Properties SETLABEL=Blue ADDLABEL SETLABELTOGGLE LABELCATEGORY Colors

1 Like

That works perfectly.
Thank you, Jon!

@Jon
Actually, I've realized that I don't have it working yet.
For instance, suppose I have this:
Properties SETLABEL=Red ADDLABEL SETLABELTOGGLE LABELCATEGORY Colors

Whan I can do:

  • Set a Bold label
  • Apply the Red label, which will cumulate (nice).

Whan I cannot do:

  • Set a Bold label
  • Apply the Blue label
  • Apply the Red label to take over the blue.
    I first need to toggle the Blue or Reset All.

What I'm looking to do is still to replace an incompatible label (blue vs red), but it looks like I've misunderstood your instructions.