Wolfram Posted October 21, 2019 Report Share Posted October 21, 2019 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: 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: 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%"')? Link to comment Share on other sites More sharing options...
S_Luis Posted October 22, 2019 Report Share Posted October 22, 2019 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. Link to comment Share on other sites More sharing options...
Wolfram Posted October 23, 2019 Author Report Share Posted October 23, 2019 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. Link to comment Share on other sites More sharing options...
S_Luis Posted October 24, 2019 Report Share Posted October 24, 2019 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! Link to comment Share on other sites More sharing options...
S_Luis Posted October 24, 2019 Report Share Posted October 24, 2019 Just fixed it. Should be in release early next week Thank you again for reporting this! Link to comment Share on other sites More sharing options...
Wolfram Posted October 28, 2019 Author Report Share Posted October 28, 2019 Yay, that was quick! Thanks! ☺️ Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now