FR: Excise multiple types In UI for Once And All [e.g. component float bounds]

[sudara]

This was the post I was thinking about:

Mouse coordinate bug on Mac?

Hi Ben, thanks for bearing with me. For the time being a workaround may be possible after all. The one I’m hopeful for requires the modification of two lines in juce_MouseEvent.cpp. They are changing the initialization of the x and y members of MouseEvent at around line 43. x ((int) std::floor (pos.x)), y ((int) std::floor (pos.y)), This stands a chance of becoming the official fix, so please see if it works for you. This is going to work as long as we specify Component coordinates using …

Other interesting threads on the issue:

Tricks to set components bounds with floats instead of ints

I think some people might be interested in this. I’ve been fighting with the fact that Component::setBounds accepts only integer arguments for years, preventing me from getting pixel-perfect alignement of UI elements with rescaling enabled. Recently, I did code some solutions that allowed me to get the results I wanted as elegantly as possible without having to hack anything in the JUCE code base. The main idea is the following: we want a function such as setFloatBounds(float x, float y, float…

Fighting Int Scale Resolution

I’d prefer if it were easier to make JUCE’s component bounds and drawing match the screen pixel positions. Then if you drag one pixel your component will move one pixel. JUCE hides and auto scales the actual rendered resolution away to make it easier to have different sizes for your plugin. That means the forced integer bounds of your components can fall between rendered pixels. I’ve made changes to JUCE that let me request an actual resolution for rendered pixels and removed all the OS auto s…

Jules recently musing that clip bounds should ideally be floating point:

BR: fillAll doesn't fill all

Yeah, the main problem is not with calling fill multiple times within a component, it’s where you have adjacent components that meet on a non-pixel boundary, so that the line where they join isn’t quite right. Makes it hard to have opaque components with the same background colour next to each other. I agree on the practicality of just making it fill a slightly larger area in this one case, it’d certainly fix the problem despite not being very elegant. Ideally I guess the clip bounds would be f…