Hi !
When activating :
SetSystemUIMode (kUIModeAllHidden, kUIOptionAutoShowMenuBar);
juce popup menus and TopLevel Windows always appear behind the main window. Is the message kEventAppSystemUIModeChanged catched by Juce or am I forgetting something ?
thanks a lot
I’ve never heard of that call - what does it do?
It’s a method I just found in carbon MacApplication.h, it sets the show/hide behavior for OSX user interface elements. It can for example hide or disable the OSX dock and/or MenuBar.
here’s an overview :
http://developer.apple.com/technotes/tn2002/tn2062.html
Well I guess it’s stopping those windows from being allowed to pop to the front… Not sure what could be done to work around that, TBH.
My little experience and myself will try to have a look at the issue… :roll:
It’s strange 'cause my app continues to display other DocumentWindows to the front…
juce_AlertWindow.cpp line 113 :
[code]#if JUCE_MAC
setAlwaysOnTop (true);
#else
for (int i = Desktop::getInstance().getNumComponents(); --i >= 0;)
{
Component* const c = Desktop::getInstance().getComponent (i);
if (c != 0 && c->isAlwaysOnTop() && c->isShowing())
{
setAlwaysOnTop (true);
break;
}
}
#endif
[/code]
Is there a reason to make the difference between OSX and other plateforms ?
AlertWindows get displayed at front when commenting the OSX case, and are displayed behind with the original code.
If so, then the problem must be that it’s the “always on top” windows that aren’t being allowed to go on top in this mode.
can’t find what’s going wrong for popup menus and tooltips 
If anybody has any idea, I would really appreciate enjoying a complete kiosk mode without menuBar…
Can’t help with that, but I haven’t got there yet. I’m using SystemUIMode too, but it looks like my juce window won’t draw where the menu bar ‘was’, even though the menu bar isn’t there right now. Is there a way around that?
Bruce
Scratch that - that wasn’t the problem. It seems that getMainMonitorArea(false) is still including the menu bar…
Hmm. It seems that on Mac, juce_updateMultiMonitorInfo (Array & monitorCoords, const bool clipToWorkArea)
ignores the flag. So here’s my contribution to the deprecated warnings list:
if (clipToWorkArea || *h == 0)
GetAvailableWindowPositioningBounds (h, &rect);
else
{
rect.top = (**h).gdRect.top;
rect.left = (**h).gdRect.left;
rect.right = (**h).gdRect.right;
rect.bottom = (**h).gdRect.bottom;
}
It should now use ‘Quartz Display Services Reference’ AFAIK.
Bruce
Thanks - how about this as a new version (I’ve only got one monitor on my mac, so if anyone’s got a multiple monitor setup, I’d be keen to know if it works there too!)
[code]void juce_updateMultiMonitorInfo (Array & monitorCoords, const bool clipToWorkArea) throw()
{
int mainMonitorIndex = 0;
CGDirectDisplayID mainDisplayID = CGMainDisplayID();
CGDisplayCount count = 0;
CGDirectDisplayID disps [8];
if (CGGetActiveDisplayList (numElementsInArray (disps), disps, &count) == noErr)
{
for (int i = 0; i < count; ++i)
{
if (mainDisplayID == disps[i])
mainMonitorIndex = monitorCoords.size();
GDHandle hGDevice;
if (clipToWorkArea
&& DMGetGDeviceByDisplayID ((DisplayIDType) disps[i], &hGDevice, false) == noErr)
{
Rect rect;
GetAvailableWindowPositioningBounds (hGDevice, &rect);
monitorCoords.add (Rectangle (rect.left,
rect.top,
rect.right - rect.left,
rect.bottom - rect.top));
}
else
{
const CGRect r (CGDisplayBounds (disps[i]));
monitorCoords.add (Rectangle (r.origin.x,
r.origin.y,
r.size.width,
r.size.height));
}
}
}
// make sure the first in the list is the main monitor
if (mainMonitorIndex > 0)
monitorCoords.swap (mainMonitorIndex, 0);
jassert (monitorCoords.size() > 0);
//xxx need to register for display change callbacks
}[/code]
I have a MacBook Pro with 1 external monitor, which is the main display now. Stepping through with gdb/Xcode, it all looks fine. The main display did come up as 0, so I couldn’t test the other case - but you may not need to. I also ran with the other monitor as main and the end result was correct.
And 2 warnings less! 
Thanks.
Bruce
Nice one, thanks Bruce!
Harrumph.
OK, this Kiosk thing is great - except I can’t add windows myself! That means no tooltips (until I told them to go on top of my controls component), no popups menus or anything.
So, good and bad. I won’t be messing up my other drawing, but I need to find a way to make everything I want on top go to this.
Jules, any clues? Do I have to sub-class everything I want to use floating, or is there a clever hook?
{And I guess this is the sort of gotchca the OpenGL texture thing will be crawling with, huh)
Bruce
Haven’t got any tips as I’ve never tried this myself. But “kiosk mode” is one of my top to-do-list items, so let me know if you find anything. Probably it’ll be a case of hacking the windowing code to use a different class of window when the app is in kiosk mode, or something like that.
Well, tool-tips was OK, because it allows a component to show on. All the slider bubbles etc, and menus don’t seem workable. I’ll go with a work-around, avoiding those classes.
I’d think, the way to go would be to look at what this and an OpenGL component would need, to whit a new peer class. If you made it possible to switch the ‘desktop’ in and out, like you switch a logger in and out, then it might cover a few things.
I held off on my OpenGL component because my ‘fix’ of a void* shared context (please, please could you add this in) and threading my OpenGL Components, but it’s on the list. Would be very cool, and I suspect you would be half handling the upcoming 64-bit Carbon snafu.
Bruce
