OSG1.2
Hello Eric. You can also try changing the setup parameters of the viewer to something like this: viewer->setUpViewer(osgProducer::Viewer::STANDARD_SETTINGS & ~osgProducer::Viewer::ESCAPE_SETS_DONE ); Good luck, Guy. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: Monday, June 02, 2008 5:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] avoid Esc key on keyboard Hi Eric, As the compiler said, the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool) method is not static, so just call it from your osgProducer viewer object (viewer->setEscapeSetDone(false)) and it should work. Cheers, On Mon, Jun 2, 2008 at 4:57 PM, Eric Pouliquen <[EMAIL PROTECTED]> wrote: Hi, i'm using OSG 1.2 on an old project, and i want to switch off the default "Esc" key behavior (exiting my application). This project uses a osgProducer::viewer, and i created a class herited of GUIeventHandler to manage mouse and keyboard events. I can manage all keys except the 'Esc' key... Someone said to look at the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool), i see in it in the corresponding code, but how can i use it (a simple call causes an error due to "non static" style of the function) in my app ? I tried to manage the Esc key in the "handle" function, returning true, and pushing front the handler in the eventHandlerList, but it doesn't work. Help :) Robert Osfield a écrit : Hi Paul, On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis <[EMAIL PROTECTED]> wrote: Doing a diff between the 2.4 and current SVN headers it seems the API changes that break things are minimal: ... So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, unless you do deep stuff with database/terrain paging. Indeed, even these API changes are unlikely to affect the majority of users. In fact the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be relatively painless ports. What would be the exact premise for a 2.4 series? Keep the API stable, while only providing bug fixes now and then? This would be the rough plan - to keep a stable API, and if possible binary compatible too where possible, and just make stable releases when particular fixes are really needed, it might be that the maintainer will just declare some fixes as ones that will be dealt with by the next major point stable release. New features I would not expect to be something to roll into stable release series, it might be occasional that a bug fix comes with a new feature or change in a feature in which case the maintainer will just have to show some discretion. The aim should be to help users that require stable releases, wishing to avoid the need for open ended porting to new versions - at most an upgrade to a stable minor point release should be a recompile of the OSG and their app, this is something that needs to be done consistently so users needn't worry about extra porting work coming about due to these extra releases. What about additions, like new examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP fetching of models? Browsing a bit through the SVN log I think the number of fixes to backport at this point is relatively minor. But backporting for example support for CMake 2.6 might be a bit too much, though (haven't looked at it in detail). The amount of maintenance is therefore directly linked to what you expect a stable branch to contain compared to the development code... It's support for CMake 2.6 which is one of the motivations for make a 2.4.1, as well as the bug fixes. In terms of making a 2.4.1, we could either use SVN trunk as the source and not bother back porting, or do the job by back porting to 2.4. Just taking SVN would be quicker and less initial work, but it'd introduce new features into the bag that haven't been tested thoroughly yet, but then there is always 2.4.2 to fix all the problems in 2.4.1 ;-) If I were to tag a 2.4.1 right now I'd just use SVN as I don't have the time to review all the different changes and back porting them to 2.4. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org --------------------------------------------------------------------------------------- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- Eric Pouliquen =========================================== Silicon Worlds S.A. 224 rue St Denis 75002 Paris France Tel: +33 (0) 1 53.90.11.13 Fax: +33 (0) 1 53.90.11.12 www.silicon-worlds.fr =========================================== _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
