From: Jason W. <jas...@gm...> - 2011-06-16 07:00:17
|
Since slavish adherence to the way a decades old library has behaved is all I hear about when I suggest a change I vote that child windows should ignore glutFullscreen :). Besides, I can't think of any sensible behavior for such a call. On Sun, Jun 12, 2011 at 11:23 PM, Diederick C. Niehorster <dc...@gm...> wrote: > Dear All, > > There is another issue I have been thinking about in the patch: > FreeGLUT allows you to call glutFullScreen() on child windows > (original GLUT does not), but what are the semantics of that? > - a child window only exists inside its parent's client area > - a child window's coordinates are relative the the parent's > -> FreeGLUT currently (before and after my patch) resizes a child > window to the size of the whole monitor, which doesn't make sense. > -> fullscreen for a child window could instead mean resizing it to > cover its whole parent. But that wouldn't necessarily be very > fullscreen, right? and it probably wouldn't do what the user not > familiar with the nature of child windows expects. > > So maybe it is safer and more logical to disallow calling fullscreen > on a child window, as original GLUT does. Maybe, as FreeGLUT has > allowed this call before before, we should make calling glutFullScreen > on a child window a noop that simply displays a warning. > > What do you guys think? (In any case, I would say lets make this an > issue to look at after the patch I sent before has been vetted). > > Best, > Dee > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |