I think the subject says it all. I’m willing to accept reasonable counter-arguments as to why there are two different coordinate systems in JUCE, as long as the person making the argument is willing to accept that they’re wrong.
Can we just go to floats or doubles for everything in the UI for once and all? Having some objects be integers, others type, and still others float is, aside from being silly in 2023, actually using up hours to days of my time trying to keep compiler warnings down to a dull roar.
Other minor complaints that I have made before and don’t expect to have addressed:
Why do we have drawRect and fillRect, but drawRoundedRectangle and fillRoundedRectangle? Setting aside the fact that all four of those could be one function, was the person in charge of rounding not in to brevity?
Why do components STILL only accept integer rects?
Why does drawText accept a float rect but drawSingleLineText only accept an int point? Getting an int point from a float rect is comically stupid
Now that JUCE is owned by PACE, can we PLEASE remove the passive-aggressive anglicisms? Literally no other SDK on the planet uses “colour.”EDIT: I don’t actually give a shit about this, plus it makes British people sad to even think about a “color” without a “u” in it, and I don’t want to make British people sad. They have enough to deal with. Since it wasn’t clear, that was sarcastic humor.
You shouldn’t make too many feature requests in one post. Most ones seem to get ignored so we should focus on the most important ones to get anything done.
this seems to be the most important one to me. all components working with float by default would solve some layout issues
I’ve requested all these features repeatedly, individually and in concert, in person and in this forum, for over a decade now. There’s no scenario where they’re not ignored.
But as you say, yes, that’s the most important one. I’ll bet a significant (like 2-digit) percentage of the Audio Damage codebase is directly responsible for converting float rects to int rects for components. I’d really like to put those CPU and work cycles to use doing literally anything else.
i feel that, ofc. i always write my layout code to be relative to the bounds of its parents so before doing anything i always start by converting width and height to float, then do the things and at the end cast back to int because that’s what setBounds wants. but it feels silly everytime, because inside those children the whole thing starts off from the beginning again
I like integers, because they are reliable, they have advantages.
But if we make the switch, we need at least doubles, if we you use just “floats” we wouldn’t have the same amount integer-“resolution” for backwards compatibility.
(However, I would consider many other things to be more important.)
This is exactly what I do (and pretty much everyone with resizable UIs, which is, at this point, pretty much everyone), and exactly why it feel silly. It gets even sillier when dealing with iOS AUv3.
I suspect that most persons who are not from the U.S., and specially those from non-English speaking countries, are very much amused at seeing people from the U.S. complain about the language of a framework written in English.
I’d say:make your own little wrapperobjects that allwys use floats, doubles or whatever you want. The simpler your wrapperobject is, the less its implementation has to be to updated with each JUCE update.
E.g. The popupmenu class has this silly behaviour that it returns 0 when the user clicked outside the menu, which is stupid because 0 is also the first item index in an array of options. (It is a classic base 0 vs. base 1 case)
If I’m bored enough by it, I’ll make a wrapper of the popup class, that gives -1 when clicked outside the menu.
I dont expect JUCE however to change this class’s tradition.
That’s a fine behavior, but when you’ve been doing this as long as I have, and have as many products as my company does, on basically all the platforms JUCE ships for, you will find that one fun little fix you did 15 years ago to deal with something silly Jules thought would be cool will force a macOS/Windows/Linux/iOS all formats rebuild of your entire product line, and you become EXTREMELY reticent to fork and wrap.
Learn from my experience here.
Also, breaking changes are the norm for JUCE, not the exception. So don’t feel bad requesting them, nor sad when they come around. Also, fuck PopUpMenu. That thing is a fucking travesty.
But if we make the switch, we need at least doubles, if we you use just “floats” we wouldn’t have the same amount integer-“resolution” for backwards compatibility.
I’d say the most modern approach would be to make all component geometry APIs be templated to take any arithmetic type, and the use of doubles be encapsulated at the lowest possible level.
I think the JUCE team would appreciate more constructive feedback than this. It’s no surprise the JUCE team choose not to address these things if this is the way their community talk about their work.
Does the naming of some methods really matter when their usage is obvious enough? IME, using juce::Path is almost always the best approach anyway, I don’t remember the last time I used any of these methods.
Agree, but juce::FlexBox and juce::Grid are almost always the best approach for positioning components which do take floating-point values.
How is that passive aggression?
JUCE is owned by a British company, based in the capital of England, developed by (AFAIK) mostly British developers. Why would they use anything other than their own dialect?
And again, does it matter when the meaning if obvious?
can we pls focus on this suggestion? that seems like it would solve everything to me. flexbox and grid are not cutting it. problems from rounding to int can accumulate the deeper a child component is in the hierarchy and that wouldn’t be a thing if every component knew its sub pixel offset. float components could be for all those who just want it lowkey correct on all resizes and double components for those who want it to work exact on rounded values or whatever that was
I strongly concur. Flexbox and Grid are basically yet another coat of paint (and one that is not terribly well thought-out) over the problem. It would be better if the problem was solved.
This problem has come up many times. Why not create a proper feature request where people can vote? As far as I can tell there is none.
Apparently it’s a hard change to make without breaking most people’s code, so a vote does make sense. If there’s enough interest the JUCE team might consider it worthwile.
I totally agree with that! Reading through this thread and putting myself in any developer (or contributor really on JUCE) doesn’t make me wanna address any of this at all! This stuff is open source for a reason, if you have a problem with it, change it yourself and stop attacking the JUCE team for feature requests you really want. And if you end up with a hole lot of merge conflicts every time you update your JUCE version, maybe that gives you a little hint on what kind of crap the JUCE developers might be looking at, when introducing these breaking changes with not everyone being on board potentially to change every every single UI component class the JUCE users have every written.
Also may I just add to the general tone of communications here: to some it may seem the JUCE team is just dangling around and writing some stuff no-one really wants. But keep in mind that these guys wrote the foundation for your possible huge success with your plugins/fast deployment to virtually every system out there. And they invest many hours to fix all the itty bitty bugs that are specific for one DAW on one OS so you guys don’t have to worry about it! I think a little bit of appreciations are on order instead of ranting about their choice of using the UK version “Colour”.
With all respect to the current and regarded maintainers of JUCE, but they did not write this foundation, that was Jules and he personally introduced the British English spelling.
“They invest many hours…” = they are on a payroll.
And Juce is owned by a commercial, American company, so Open Source, yes, to a certain point, I assume. “This is open source for a reason” - can you please elaborate on this?
I am 100% with Crandall1 when it comes to the integer / float issues - that is a constant irritation for me as well. Same for the inconsistent naming and formatting conventions (e.g. compare the Dsp module with other modules). These requests can improve Juce - they are not a risk, imho. And they are certainly not about introducing “crap” as you suggest.
You have just added to the tone of the discussion yourself now, and you try to silence another forum member with his requests / wishes.
