[osg-users] avoid Esc key on keyboard

[Eric Pouliquen]

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 <paul at science.uva.nl> 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
> osg-users at lists.openscenegraph.org
> 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
===========================================