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

[DavidCNAntonia]

I could get behind juce::Couleur

[yairadix]

You mean jus::Couleur?

[DavidCNAntonia]

Or one could translate Jule’s Utility Class Extensions and turn it into an acronym. I think this would become something like ecuj (extensions de la classe utilitaire de jule)?

ecuj::Couleur

[aamf]

Since all seriousness has been left behind… Simplifying English for The Americans | Michael McIntyre - YouTube

[crandall1]

Speaking strictly for myself, this bikeshedding of the English language and its use in JUCE has been amusing, but my obviously sarcastic comment was immediately and pedantically (and some would say willfully) misunderstood, as yet another successful attempt to derail the original point: all components should be type.

It’ll be too much work? Just do a search for “deprecated” in the codebase if you’re new here. The entire parameter system has been replaced twice, so let’s not talk about work, nor putting another coat of paint on past mistakes.

[ImJimmi]

@crandall1

my obviously sarcastic comment was immediately and pedantically (and some would say willfully) misunderstood

Sarcasm doesn’t come across in text form. We don’t know you, we don’t know your culture, we don’t know what may or may not be intended as sarcasm. I didn’t sense any sarcasm in any of your comments, I sensed frustration and rudeness.

@crandall1

yet another successful attempt to derail the original point: all components should be type.

I don’t think anyone in this thread disagrees with you. We’d all like to see this change. But being rude isn’t the way to motivate people. You tried to enforce your proposal by making additional rediculous proposals which has lost you a lot of respect.

[Mrugalla]

i’d just like to point out that things being a breaking change shouldn’t really hold the JUCE team back from attempting this. lately when i updated to the latest version of JUCE i had to change all my dsp classes to work with float* const* instead of float** and ofc it was a bit confusing at first, but in the end it was alright. and templating components to float or double would also not be that much of a deal. everyone would probably just decide what they wanna use and then put

using Component = juce::Component<float>;

at the beginning of their namespace or so. then everything else would still work as before. only those who really care would additionally have to adjust their resized-methods to use the new potential, but those people are also those who asked for it, so it’s cool

[aamf]

@crandall1

I don’t want to make British people sad. They have enough to deal with. Since it wasn’t clear, that was sarcastic humor.

Love this. Yes, it wasn’t clear. As @ImJimmi said, sarcasm in text form is hard to perceive. And there’s people who are serious about this stuff, someone has actually voted for the American-English feature request!

Back to the proposal (for which I voted!): it’s not quite clear to me how much of a breaking change this would actually be. I can’t imagine it being very bad and agree with @Mrugalla that a breaking change shouldn’t hold the JUCE team back.

Here’s another thread on the topic:

Support for floating-point component bounds?

It’s a change that we’d all love to make, but it’s also one where it’d be very hard not to make it break everyone’s code! There are workarounds though - you can give your object a floating point position relative to its parent and then update the component bounds to be big enough to enclose it. Then in its paint method you just subtract the integer component position from the floating point target position and it looks correct. That’s how things like Drawables are done.

[sudara]

I was going to make a new FR for “Component and images should accept float bounds,” but remembered we have this one. Here’s a little post-JUCE 8 bump!

I wanted to add it would be useful if in addition to components, juce::Image worked with float bounds.

I just tried to do some image tiling (which is so fast!) with some cached drawing (a cached gradient, path, etc) and remembered I’d have to round everything to the nearest pixel to get the benefits of tiling to work. Int rounding means it’s harder to get seamless image tiling (unless I draw to exact int bounds, in which case I get stair-stepping vs. smooth animation).