CodeEditor text invisible Mac OSX 10.6.8

MacOSX and iOS
1

Hi Building my app using juce tip on OSX 10.6.8 triggers a bug where the CodeEditor component does not display text -- selection works and text is actully in the component but the text  is invisible (or transparent?)  I am also able to trigger this bug in  the JuceDemo App as well, in both its CodeEditor demo and Java Script demo pages.

Now, in the demo app, If I switch from the CodeEditor window to the  OpenGl demo and then BACK to either CodeEditor demo then  text is then visible in those  code editors, so somting about initilizing the OpenGL demo seems to solve the problem.

any ideas on what I need to do to get text visible would be appreciated!

best

 

Rick Taube
Assoc. Prof. Composition/Theory
Chair, Composition/Theory Division
School of Music
University of Illinois at Urbana-Champaign
Net: taube@illinois.edu
Fax: 1 217 244 7767
Vox: 1 217 244 2684

 

 

 

2

Presumably this is just a problem that happens if you build with the 10.6 SDK, because I know that if you build with the 10.8/9 SDK and set it to be backwards-compatible, then the result will run ok under 10.6.

Annoyingly, I don't have any way of trying this myself, since I no longer have an old machine to build on.. If you could dig deeper and give me some more details about where it's going wrong, I might be able to suggest a fix though. Presumably it's something to do with the old pre-CoreText font code, but not sure how/why it'd not work.

3

here is a bit more information: if I copy this expression from the OpenGLDemo code

            MainAppWindow::getMainAppWindow()->setRenderingEngine (0);

and add that call to the CodeEditorDemo() constructor,  then when I start up the JuceDemo  text is immediately visible in the CodeEditorDemo as normal. So I wonder what the setRenderingEngine(0) twiddle is doing that makes things work ok thereafter ?

other things: i've tried building my app on 10.8.3 using  -mmacosx-version-min=10.6 and then running that executable on the older 10.6.8 machines but that dosnt help: everything compiles and links fine, but the text in the CodeEditorComponent is not visible.

Note that it only seems to be the CodeEditorComponent that has the problem,  components based on TextEditor in my app work fine, as do all the dialogs and alerts that I've tried in JuceDemo.

I wish i could flush this old OS, but my lab isnt slated for a computer refresh until later this summer, meanwhile I begin teaching next week on 15 macs running 10.6.3 and right now students cant see the code they will learning how to write. I dont mind making the course difficult, but this hardly seems fair :)

4

The openGL stuff is a red herring - it's CoreText that'll be the issue.. Could you do me a favour and try this mod to juce_mac_Fonts.mm, line 1292:

bool TextLayout::createNativeLayout (const AttributedString& text)
{
   #if JUCE_CORETEXT_AVAILABLE
    #if JUCE_MAC && ((! defined (MAC_OS_X_VERSION_10_7)) || MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_7)
    static bool canUseCoreText = SystemStats::getOperatingSystemType() >= SystemStats::MacOSX_10_7;
    if (! canUseCoreText)
        return false;
    #endif

..it's a bit of a brute-force fix, by disabling CoreText in 10.6, but I'm not sure what else to try.

5

jules adding that test did not change the visibility of the text in the code editor (i also tried just returning false without a test). thanks for your help!

best rick

 

6

Ok.. I'm a bit stuck then, I don't have a 10.6 system to debug it. Any chance you could figure out where in the font code it's failing?

7

i will keep poking around more.  BTW if I take just this line from the Demo's setRenderingEngine())  and add it to my CodeWindow constructor then  text is visible when the window opens.  not sure if this helps you or not, but it seems to trigger some kind of initializtion that allows the text to be visible even if the same coreText issues is still there

    if (ComponentPeer* peer = getPeer())
        peer->setCurrentRenderingEngine (0);

8

No, you're misunderstanding that - it's clearly something in the CoreGraphics rendering engine that's not working, so switching to the software rendering engine just side-steps the problem rather than fixing it.

9

ok i understand what you are saying. can point me in a direction or method for trying to isolate the failure? Im not sure where in the code this visibilty issue would be happing or how to detect it.

thanks for any tips!

10

Unfortunately if I knew where the problem was, I'd have fixed it! Most likely somewhere in juce_mac_Fonts.mm - if I was debugging it myself, I'd just step into the drawText calls which fail and see how far it gets.