Hi Stephan, On 1/7/07, Stephan Huber <[EMAIL PROTECTED]> wrote:
Me too, the code in Producer got very complicated. For now I implement the carbon route with "fake" fullscreen (a window which has the same dimensions as the screen) this is simpler and cleaner. For real fullscreen-mode we can implement a GraphicsWindowOSXCGL which implements the CoreGraphics-way without windows and without the windowmanager.
I think this faking of fullscreen will be fine, and having a dedicated fullscreen mode will be fine too. Its something that might be of interest on other platforms too.
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.
I started implementing the GraphicsWindowOSXCarbon class, and now I have some more questions:
May I suggest that you just name it GraphicsWindowCarbon, the Win32 and X11 versions of GraphicsWindow won't be entirely portable - well I guess X11 is really - even available under Windows... but in principle I don't think its required to have the platform clarification. However, putting all OSX GraphicsWindow implementation inside the same header might be tidier than having Cocoa, CGL and AGL implementations...
* 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. 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.
* 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. There is also a distinction to make between closing a window and closing a an application. If you have multiple windows open closing one needn't force a close of the whole application, and this is how I've implemented it in osgViewer::Viewer - it checks on each frame to see if there has been a change in the number of windows open, if there is none left it sets _done to true and the frame loop will exit, if there are windows still left but the number has changed then it'll stop any threading, and then restart threads (if appropriate i.e more than one window still open) and will the reset the frame barriers. 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. Cheers, Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
