Hi Robert,
Robert Osfield schrieb:
So people can switch between the two implementations and the examples
work out of the box the carbon way.
Perhaps we can use an extra flag in the GraphicsContext::Traits
structure to hint whether the window is resizable or not, if not and
the window is full sized then one can just create the full screen way,
this could be the case on all platforms that support a pure full
screen mode, the advent of 3d window managers on all major platforms
this will probably become more important.
An extra flag would be neat, but what for dynamic switching between
windowed and fullscreen mode? ('f' in osgProducer-based apps)
May I suggest that you just name it GraphicsWindowCarbon, t
ok, no problem...
* I need a way to get informed, if the window goes to "fullscreen"-mode
so I can hide the menu-bar and the dock. Or should I hide the
dock/menubar if the window is fullscreen-sized (looks complicated)?
Perhaps this is another option to put in GraphicsContext::Traits as a
hint to know whether to hide the menu-bar or not. Its implementation
might be platform specific, but having a single bool won't do any
harm. It might be approrpriate to add an extra method or two to the
GraphicsWindow base class to help control this aspect.
Yes please :) On OS X you can control to hide the menubar completely or
temporarly, so when you move the mouse to the upper , the menubar pops
back in.
As a default I'd go for hiding the menu-bar when in full screen, as
this would work well for vis-sim/vr apps, and will also give us the
same look and feel across platforms.
I will try to code a nice method, so the menubar gets hidden when the
window is in its area. This is a bit complicated but doable.
* How to handle window-closing via the window-manager? in the
X11-implementation you set the _valid and _realized-flags to false. On
Mac OS X you can quit an app also via the menu or via socalled
AppleEvents, how should I implement them, I see no way to set a
quit-flag like in Producer. (Ok, I can inject an Esc-key into the
event-queue, but this seems rather hackish.)
On the X11 side we now tell the window manage to send an event on the
close button being pressed, this is then caught by the checkEvents
implementation, which then calls close at the end of the checkEvents
method. Have a look at the GraphicsWindowX11. Perhaps something
similar would be appropriate.
Thanks for the hint, I coded it similar for the carbon-window and it
works :).
An application close will be something that we'll want to respond by
exiting the main frame loop. I don't know of the X11 events for this,
or if catching a particular signal will be appropriate. I also don't
know what the situation is on other platforms w.r.t window vs
application close. I therefore am all ears on the topic. I certainly
want osgViewer based apps to place nice and behave in a well mannered
and platform appropriate way.
I like it that the app quits, if all windows are closed. But it would
be nice to have the ability to set a special quit-flag, so we can force
the viewer to quit on demand. So I can handle the menu-item Quit which
is standard for all OS X application, and even handle the Shortcut
<Cmd-Q> which is also standard. I can even support AppleEvents, which is
a mechanism to communicate between different apps and there's a special
AppleEvent for quitting an app.
thanks,
Stephan
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
