Jump to content
Wolfram

new feature "coloring changesets and labels" not always working correctly

Recommended Posts

Hiho.

Thanks for the new feature that allows us to color labels individually! 🙂

However, in certain situations it doesn't seem to work correctly yet:

We added a rule 'name like "%Release%"' to our clients:

labels1.png.5f4887050e140975ef62774a7a776880.png

This does work if there is only ONE label on a changeset. However, with more than one label, the rule is evaluated only for the FIRST label, and then applied to ALL labels on that changeset.

In this example:

labels2.png.7a700657cbf1b053d35f24f9905dbc51.png              labels3.png.60f771992ec9fc2eb75806712aeed2c7.png

We added a label containing the word "Release" to the first changeset (which is colored correctly).

We added a SECOND label containing "Release" to the second changeset (which already had one label). Note that all labels have the default color, which is not correct.

We added a label containing "Release" to the third changeset, and THEN added another label to it, without the word "Release". Note that all labels have the filter rule color, which is not correct.

(note that both in the graphics, as well as in the context menu, the label orders are reversed, so for the middle changeset, the label shown as "this is a Rele..." is actually the SECOND (=newer) label, not the first)

(using 8.0.16.3636 Windows)

 

Side question: is it possible to specify a case-insensitive filter/coloring rule, or do we need to manually combine them (for example, by using 'name like "%Release%" or name like "%release%"')?

Share this post


Link to post
Share on other sites

Hi Wolfram.

Let me explain the cause of this label drawing:

Try the following: when you right-click a label draw that represents a single label, you have a (let's call it this way) "top-level" contextual menu with all of the options for said label. On the other hand, when you right-click a label draw that represents two or more labels, you can see that instead of the "top-level" menu you have a menu to choose the label, and then a submenu with all of the options for said label.

That's on Windows. On Linux and macOS we don't even draw multiple labels by splitting the crown - we just differentiate them by the names printed on top of them.

On Windows, the multiple label crown just indicates the number of labels - but it doesn't differentiate which is which. Again, this comes from the times we didn't have color filters - but the search behaves in the exact same way. Try a search that only affects a label, and you'll see all of them highlighted.

Right now maybe it is worth it to draw each piece of the crown with a different color depending on the filters that apply to each label - we'll look into it, but I can't promise it will make its way into the roadmap!

About the case insensitive search - nope, sorry! You need to manually combine them.

Share this post


Link to post
Share on other sites

Thanks for the reply!

Yeah, I assumed as much.
However, it currently creates an inconsistency: If the user starts relying on the coloring, he will miss the middle changeset in the example above, as it contains a label with "Release", but that changeset's labels are not colored.

Splitting up the arcs and coloring them individually might be a lot of effort on your side, with possible side-effects.
A quick solution might be, to have the label rules match all labels with an "OR" concatenation, instead of just checking the first label. So in my example above, all arcs would be colored, if ANY of the attached labels match the rule. This would correctly color all three changesets according to the  'name like "%Release%"' rule. Prioritization if there are several matching rules would simply be determined by rule order (as it's already done with branch colors and so on).
This solution would even work for Linux+Mac, which don't visualize multiple labels on the same changeset. But currently, the label (or even branch) coloring rules for these platforms aren't implemented yet, anyway.

Also, you have the "OR" rule already working for the filter/search field: if I search for "release" (even case-insensitive 😉 ), all THREE changesets will be highlighted, no matter the order in which these labels were originally created. If I search for "Unity", only the middle changeset will be highlighted.

Share this post


Link to post
Share on other sites

Ouch. Now I see what you meant in your first post, sorry! 😞

Yes, this is a bug. I will take care of it as soon as possible. Thank you for reporting it!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...