Colours added/removed in UI XML

[dannytaurus]

@David-Healey That's a git diff. The - lines represent the removed lines and the + lines are the added lines.

It shows after the first save, the bgColour and itemColour properties were removed. Then later, after another save they were added back in.

I guess if you don't use git on the command line you probably don't recognise the format, sorry!

EDIT: edited the original to show the old/new lines

[Orvillain]

Probably some tinyXML serialization type thing. I notice a lot of floating point values often change to ints and back again, from commit to commit. Tis a bit annoying.

[David Healey]

@dannytaurus said in Colours added/removed in UI XML:

That's a git diff.

Oh I see it now!

[dannytaurus]

@Orvillain Yeah, I made a PR that casts all x, y, width and height values to int before saving the XML.

PR here: https://github.com/christophhart/HISE/pull/831

But I can't pin down why the colours are added and removed.

[dannytaurus]

@David-Healey Sorry, shoulda been more explicit about what I was posting!

[Orvillain]

@dannytaurus said in Colours added/removed in UI XML:

@Orvillain Yeah, I made a PR that casts all x, y, width and height values to int before saving the XML.

PR here: https://github.com/christophhart/HISE/pull/831

But I can't pin down why the colours are added and removed.

I don't think that is a good solution. The UI layout system supports floats for those fields. All values should be floats IMHO - even if they're button states.

It is quite important to have floating-point positions when converting Figma designs over to a HISE layout (ask me how I know!)

[Christoph Hart]

@Orvillain component positions are rounded to integers anyway in the entire JUCE UI system.

You get sub pixel drawing stuff (so you can draw a rectangle at a float position / size, but not position a component.

If you design your UI in 2x for retina, then all the positions of the knobs have to be at a even position, so that if you divide it by 2 to get the "HISE coordinates" they are still an integer number.

[dannytaurus]

@Orvillain Oh, interesting! I'll dig deeper into the code.

As far as I could see originally, all position and size properties are cast to int when they're read from the XML. They're stored as strings in the XML, and when they're read back in to create the component properties, they're cast as integer.

I thought the UI layout system only used integers for position and size.

You can demonstrate this by zooming the Interface Designer to 400% and changing a component's x, y, width or height to a half-pixel value in the sidebar. You'll notice the position and size don't change in the actual UI, even though the float value is shown in the sidebar.

The half-pixel float value is even stored in the XML, and those float values are restored to the sidebar on load - but when you change the floats back to integers in the sidebar, you'll notice the component doesn't change. It was already set on integer pixel values.

This is the reason I chose to cast position and size to integers rather than floats. Having everything as floats would be fine with me, except that it implies a level of precision that you don't actually get in the UI.

[dannytaurus]

Oh werps! Just saw Christoph's reply after posting mine.

Well, good to know for sure that position is rounded to integers.

[Orvillain]

@Christoph-Hart Interesting, I did not know that! Looking forward to the designers whining at me about Figma pixel-perfect accuracy!

It might be worth performing this rounding/clamping in the UI fields too, for consistency sake. I totally get it is a JUCE baseline thing, so I'm not going to whinge about sub-pixel accuracy or anything like that.