I’m trying to create a text button who’s text is a little smaller than the 15 point that is standard.
Am I correct in thinking that the only way to do this is to subclass TextButton for each text size I want in my interface? The juce TextButton class has a getFont() member, which is used by the LookAndFeel to find the font to use, but there’s no setFont() member, so there’s no way for me to change the size of the text at creation time, or even on the fly. Am I missing something?
It’d be more suited to a custom lookandfeel rather than a subclass of textbutton.
I disagree that it should be put in the Look and Feel. There should be a way to set the font on specific buttons. Different buttons may have different fonts within the same application. I had complained earlier in the day about making it easier for the user and you said to voice my opinions, so here is another one. Things like this should be simple and straight forward. This is how it would be easy. The constructor sets the font to NULL and user can set it later. At paint time if the TextButton’s font is null the paint routine uses the look and feel for it’s font. This way you get the best of both worlds.
I spent an hour trying to figure out how to change the a TextButton’s font and it should be 10 sec. You as they say time is money and this is costing me and I have deadlines.
I know I can override paintButton or TextButton.getFont() but this should not be necessary. As I said before, why not make things like this simple. This is what we pay for. I see the date on this post and wonder if people give up and just rewrite juce themselves.
Ex.
I 've already started changing juce myself by making the x and y member variables in Point public so we can access them like every other environment. I have a million lines of code and probably 5,000 places where point members are accessed directly. Can you imagine rewriting all of them. Every environment has them as public. I undestand the safety of making all members private, but for basic elements like point, rectangle, etc. it’s not needed.
I know I am coming on a bit strong but after 28 years of writing applications I feel this is obvious. juce can be great but still needs the user experience to be better to get there. Take a lesson from Apple. User experience is the a very important part of any application.
So at this point I’ll just override the getFont() in my own button class and live with it. I know it’s easy, but spending the time having to figure simple things out like this is killing me.
[quote=“FirePlayer”]I disagree that it should be put in the Look and Feel. There should be a way to set the font on specific buttons. Different buttons may have different fonts within the same application. I had complained earlier in the day about making it easier for the user and you said to voice my opinions, so here is another one. Things like this should be simple and straight forward. This is how it would be easy. The constructor sets the font to NULL and user can set it later. At paint time if the TextButton’s font is null the paint routine uses the look and feel for it’s font. This way you get the best of both worlds.
[/quote]
You could have stopped there. Jules is very appreciative of feedback (as he mentioned to you earlier) and in my experience has done his best to make any changes that make sense. For the parts where Juce isn’t perfect, there are many areas that well make up for it. Jules has mentioned in the past that he has plans to rework the LookAndFeel stuff, but if you’d like to see the Juce user experience be elevated to the apple level, then I’m sure Jules would be happy to have a look at anything you wish to contribute. He really is very good in this way and I’ve gathered that most people here are very appreciative of it.
Epic D.R.Y. fail!
In the case of Point (but not Rectangle), you do have a valid point.
But: when I first introduced the Point class and refactored all my own code to use it, I noticed that whenever I hit a situation where I seemed to need direct write-access to the x and y members, there was in fact always a cleaner, better way to do the job, usually by treating the Point objects in a more immutable way. I would certainly have made the x and y public, if it wasn’t for the fact that I found that restricting access to them actually forced me to write better code than I might otherwise have done.
Ideally, I’d like to be able to make the x and y public but const, but that’s not very easy (…although actually, it would be possible via cunning c++ trickery, hmm, might have to tinker with that idea…)
Graeme,
I appreciate your comments and the work jules has done. I just sent him a private message explaining who I am and what I’m looking for and also why I am a bit picky. Hopefully he sees it as positive feedback. And I am willing to help with the improvements to make it more “user friendly”. My technical knowledge it not the c++ programming capabilities and jules is way beyond me in that area. My strength is in user interface and user experience. The funny thing is even though I mention Apple I don’t like what Apple did to developers, but they sure know how to convince the rest of the world they know what’s right. My code from 15 years ago still runs under Windows but has to be rewritten every few years for the MAC. Guess what, I wrote all of it on the MAC and then ported it to windows and but now do the opposite. I pray that juce solves this problem and I only write under one platform from now on.
P.S. Yes a million lines of code.
Again thanks and I’ll back off a bit.
