Icon Editor Text jumps up when using Fill Tool with dark color

[GIsaacs-NI]

Describe the bug
When using the fill tool with a dark color on the lower half of a vi icon in the icon editor, the text will jump up, as though another item is occupying the space below. It looks like the bug is being caused by how Find Start and Endpoints Body Text.vi determines the possible text area. That vi goes through each line of the vi icon until it finds one with an average grayscale value of more than 200 (which is because it assumes that the text area will be transparent or filled with white). If you fill the text area with a darker color though, it will think that the valid text area is the size of the yellow section at the top, and so it smushes the two text lines together.

To Reproduce
Steps to reproduce the behavior:

1. Create a New VI
2. Click on the VI Icon in the top-right to open the Icon Editor
3. Replicate the layers seen in the screenshots
4. Fill the bottom section with a dark color (like red)

Expected behavior
The text should not move when using the fill tool on a section of the icon editor.

Screenshots
Before using the fill tool:

After using the fill tool:

[VTRobH]

This is the biggest problem with the Icon editor. That text also jumps in other circumstances (at least in some LV versions) since I've seen it a bunch and not as a result of using dark colors

[RobustoSystems]

+1. I faced this bug multiple times in the past, but always questioned myself whether it was a bug or I wasn't understanding how the Icon Editor was supposed to work. Very glad to see that someone else identified it so clearly as a bug.

Kind regards,
Petru Tarabuta, Robusto Systems Ltd, UK

[crossrulz]

This appears to be related to the header detection, which has caused issues in other situations.

[mballawickersigpi]

In my attempt to try and understand how the ni IE works I have played with the idea of making the text better aware of the other layers but ran into some issues with establishing rules.

It is difficult to determine what layers the text should stay away from and what layers the text should ignore.
I have seen icons with the grayed graphic backgrounds and the text was overlaid on top.
There are other icons where a graphic is present and the user wants the text to not encroach on it (DQMH broadcast icons)

What text rules or functions would you put in place to allow the user to specify how the text is to be laid out?

One idea I had would be to add a check box in the layer display that indicates whether the text is to avoid the layer or ignore the layer with a possible name of "text blocker". Maybe a graphic could be developed to communicate the idea similar to how MS word does.

[crossrulz]

A simpler idea I have had in the back of my mind is to make a "Header" layer, similar to the "Template" layer, and then the text can just avoid that layer based on the lowest non-transparent pixel. This would still have the issue of avoiding glyphs in the icon body.

[VTRobH]

In my mind there are two layers that are paramount when considering text avoidance: Template and Library.
I would de-prioritize avoiding everything else until we can avoid overlap on those two
In fact, I would classify the Library layer as an additional optional template layer most likely rather than a user layer

Then I would say that only considering the "borders" is a good starting point. If the user wants to put graphics on there, that's on them

Having said that, perhaps there is another way of looking at it...
Perhaps the root problem is that there is a "text layer" that collects (up to) 4 different text entries.
What if:

• Each line of text were its own layer
• Each template/library could define where their default locations were
• When editing, the user could drag them around wherever they wanted

That would give the developer the convenience of what they have now with the power/flexibility/responsibility to handle the avoidance problem in the way that they see fit.

and no, I have not yet looked at the code to determine how much of a headache this idea would be.

[crossrulz]

In my mind there are two layers that are paramount when considering text avoidance: Template and Library.
I would de-prioritize avoiding everything else until we can avoid overlap on those two
In fact, I would classify the Library layer as an additional optional template layer most likely rather than a user layer

Sounds like we are mostly saying the same thing here. My point would be to make a generic Header layer. By default, the header would be populated by the library icon.

[crossrulz]

Perhaps the root problem is that there is a "text layer" that collects (up to) 4 different text entries.
What if:

• Each line of text were its own layer
• Each template/library could define where their default locations were
• When editing, the user could drag them around wherever they wanted

Interesting idea. This sounds like something worth experimenting with.

It may even lead to removing some code, possibly the Text tab and text tool. Note: I am not advocating for that yet, just putting it out there as something to consider.

[crossrulz]

I changed this from an issue to a discussion as we need to figure out a good method to handle this bug. There are several options mentioned here, which would likely require other changes as well.