LookAndFeel issues again (PopupMenu from a ComboBox / Mac OS X)


#1

Hi Jules !

I have spotted a new LookAndFeel issue. I have defined a custom LookAndFeel class with a specific Font object, returned as it should by functions like "getPopupMenuFont". As you may imagine, I have found a situation where the wrong Font/LookAndFeel is used.

I have a ComboBox object, which displays a menu when I click on it. The Font used on the PopupMenu is right for every item, but is wrong for section headers, only on Mac OS X (I use Mac OS X 10.8 and Xcode 5). The display is wrong in the VST and the AU version of the code. And everything is fine on Windows XP (?)

I think the problem is that the function "getLookAndFeel()" in HeaderItemComponent does not return the right LookAndFeel. I have tried something in "PopupMenu::addSectionHeader()" to be sure that the LookAndFeel is given to the object but without success. Maybe the problem should be issued in PopupMenu::setLookAndFeel(), where all the CustomItems previously created should have the right LookAndFeel passed by ?

Thanks in advance !


#2

Are you sure that the HeaderItemComponent is getting the wrong lookandfeel? I can't see how that'd be possible, because all components will pick up their parent's l+f, so all the menu components will share the l+f of their parent window, which presumably is correct. Maybe something else isn't working, and you're misinterpreting the cause?


#3

Hello Jules !

You are right, the LookAndFeel was the right one. But I found another clue : in the paint function from the class HeaderItemComponent, the font displayed is right when I remove the instruction "boldened()". If I keep it, the font isn't anymore the one I loaded, but a default font instead. How is it possible ? And again, it is happening only with Mac OS X, I didn't have issues with Windows XP.

Isn't that strange to see several times in a row issues with Fonts ?

Thanks again ;)


#4

Most likely the font you're using just doesn't have a bold style, or has a bold style with a different name. I guess I should move that paint code into the lookandfeel so it can be overridden for custom stuff like this.


#5

Hi Jules !

Indeed, I think it is a good thing to have this paint code into the LookAndFeel classes.

And you were right about the Font. With Windows XP, it was possible to apply the bold and italic effects on this font. However, on Mac OS X, that didn't work because the Font file contains only one style. So I should avoid to use them.


#6

Hi, I have the same problem. This thread really helped with tracking down the issue. I have the bad fonts for all the methods where I call setBold(true) on the font object. For example:

 

Font MyLookAndFeel::getMenuBarFont(MenuBarComponent & m, int /*itemIndex*/, const String &/*itemText*/) override{
        Font font(textButtonFont);
        font.setHeight(jmin(17.0f, m.getHeight() * 0.6f));       
        font.setBold(true);
        return font;
}

To be more specific, I use Open Sans font which I load directly from the file. Everything works great on my Windows 7 dev computer. I have also tried 2 more Windows 7 computers. Those have no problem as well. But now I have tried to run the application on Win8 computer, and as I said, all the fonts that are returned like in the example above are replaced with something that looks like Courier or something.

 

Also if i remove the line that says:
font.setBold(true);

there is a correct font (only not bold). The strange think is it does work on Windows 7 and does not on Windows 8 (of course it might not be Windows 8 problem but rather something else - hard to tell from so few a samples...)? What do you suggest I should do? And why does this fail on Windows 8? I think the this should be made consistent...

 

Thanks a lot

 

 


#7

So what do you suggest I should do to have the same result for Windows 7 and Windows 8? Why can't JUCE on Windows 8 make a bold font?


#8

JUCE can simulate an italic font by applying a transformation matrix, but can't simulate a bold font. We have to rely on the OS to provide a bold version of a font.


#9

So if I have Open Sans semibold loaded from file and then call setBold(true), it is OS's responsibility to handle it? So the Windows 7 somehow manage to do that and Windows 8 do not? That's rather strange but if so, I might pack the bold version to the resource as well...


#10

OK, i wanted to pack the bold font with the applicaion as well but there's a problem with that. I have been able to solve all the problems except one.

 

It took me quite a time but I have been able to track the problem. In AllertWindow::updateLayout() there is this line:

 

attributedText.append (getName(), font.withHeight (font.getHeight() * 1.1f).boldened());

 

Well, no matter what I do with the font, in this line it tries to create a bold font, which results in usage of the default font (whatever that is). In my case it already is a bold font version. But that doesn't matter, the thing is that it in my opinion it should not be responsibility of the AlertWindow at all to create some font layouts but rahter that of the LookAndFeel. Instead of creating the bold font it should probably call some method of the LookAndFeel at least.

 

Well, what do you think Jules?

 

Thanks


#11

Please I need to get this done. The thing is that as I see it, I would have to alter the juce code for it to get it work but that is never a good idea, because I would have to do this all over again everytime I update the repository.


#12

I'll make sure this gets done pronto!


#13

Thank's, it should be a simple fix... I think the AlertWindow should call some method of the LookAndFeel to get the correct font (which would in default just return the boldened version of the font, but everybody could override the method in cases like theese). The thing is I do not install the fonts but rather load them from resources.

 

Thanks again, looking forward to the patch...


#14

Just to keep you updated, I've implemented the necessary changes and am now testing them.


#15

Thanks, appreciated.


#16

Any progress? Just checking You haven't forgotten...


#17

Apologies for the delay! The changes have been made, they're just waiting to be reviewed and merged now. Hopefully this will happen soon!


#18

Changes should now be on the newest tip.


#19

Thanks a lot. That did the trick...