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
