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

I’ve requested missing features and bugs for as long as double you did, and i always had to do things myself in the end. Contributing to juce, is just asking to be fish slapped that “your code sucks we can do better”. And nothing happens for years.

Welcome to “maintain your damn fork” framework. Case closed.

3 Likes

I edited the category to make this an “official” feature request. Hope that’s not too much of an abuse of my “Regular” forum status…

I also voted for it. The int/float confusion is a regular layout hurdle for newcomers. It would save a lot of cumulative dev time (and headache) if it were resolved in the framework.

I could be misremembering, but I think this was acknowledged on the JUCE forum as “possibly up next” by someone on the JUCE team some time last year?..

5 Likes

Yeah. You can easily tell everyone in this thread who has been deeply patronized by Jules at some point and everyone who hasn’t. :slight_smile:

4 Likes

…and who managed to get over it :wink:

On topic:

  • 100% for float bounds
  • 100% for adding consistency to some function names, keeping the existing as deprecated
  • colour: pretty much amused…
5 Likes

This was the post I was thinking about:

Other interesting threads on the issue:

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

Why don’t you create a wrapper and derived classes? I hardly use JUCE methods usually, if I draw a square sometimes I want it to have a different colored border, or a texture, or a shadow, etc. and all that I include in my functions with its own name and parameters, I’m not going to build anything drawing simple rectangles.

The components are exactly the same, I’m not going to build a slider from scratch defining all the functions and parameters one by one, I already have my own class where my default preferences are set.

That would be the best solution but at the same time it would require (I assume) significant changes to the LookAndFeel class (I had already conceptual issues with templated components and their painting methods in LookAndFeel).

Btw., maybe there should be also a discussion about providing something like paint delegates as an alternative to LookAndFeel?

I know a lot of developers whose mother tongue is Hebrew, Russian, etc yet everyone writes their open source libraries and projects (and all code for that matter) in English. Is British ok only because it passes as close enough?

There’s a lot of off-topic conversation going on in this thread (and I appologise for my contribution to that).

I’ve made a couple of breakout threads for the two other proposals mentioned in this thread:

1 Like

I seem to remember Jules saying at one of the YouTubed conferences that he regretted using int’s in the GUI. It was a few years ago.

1 Like

Careful, that’s getting close to suggesting American English is the default English! It really depends on which metric you’re using to decide which is which. Brits will vehemently disagree unless the answer is, “British English”. We would also argue there is no need to qualify it. :joy:

Although I somewhat suspect that comment was an example of trolling as a art. :wink:

3 Likes

Let’s just go for the most commonly used spelling

It’s undeniable that US English is the unqualified one, but let’s make a deal: If you expand your empire back to here then I’ll be super thankful and will join the UK English camp!

1 Like

Guess my breakout threads were a waste of time then :person_shrugging:

2 Likes

Would you prefer I asked for the restoration of the British mandate in your breakout thread? :wink:

This thread is starting to read like reddit. Everybody love everybody.

4 Likes

Funny how the biggest issue eventually seems to be spelling.

1 Like

Personally I’d call it “English” and “American English” :joy:

3 Likes

I propose an english that is continent neutral
the offending part is repeated in the opposed spelling;
Color or Colour? no! use: Colorour
Digitise or Digitize? no! use; Digitiseize
Both UK and US spelling are equally observed here.
okok, I’ll shut up…

3 Likes

Ok, how about we compromise and use French?

3 Likes