a collegue of mine noticed that on Windows and X11 the modifier state (such as
Alt or Ctrl) would be applied one key press too late: e.g. press & hold Alt,
press a, release Alt, press a, press a would generate the key sequence a,
Alt-a, a instead of Alt-a, a, a.
The problem is also present on Carbon. Moving the call to setModKeyMask in
front of the call to keyPress fixed it for me on Carbon and X11. I suppose
that this will fix the problem for Windows as well."
"These enhancements make it much easier to control which libraries get
found by FIND_ using environmental variables. The problem with the old
script was that CMake searches what it considers system paths first.
This makes it difficult to override in the case where you might have a
stable version in /usr/local, but are trying to build a bleeding edge
release in the non-standard location /bleeding-edge.
I went to the CMake mailing list hoping to find a good solution to
this. Unfortunately, there isn't one, and I have to do something
rather bone-headed in the Find module. Basically, I have to run FIND_
twice: once with default search paths turned off and my environmental
variables listed, and again with standard search paths reenabled. At
least it works.
I also added a few more environmental variables, specifically:
OPENTHREADS_INCLUDE_DIR
OPENTHREADS_LIBRARY_DIR
These two variables address the shortcoming of OPENTHREADS_DIR in the
case where the include path and library path don't share a common
parent.
Put all this together, and you can setup an automated shell script or
Microsoft .bat file to configure and build your application in an
automated step.
You still should be able to use the key CMake variables like
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will
occur after the environmental paths are searched. The reason for this
is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are
more specific. This prevents the accidental ordering problem where you
might use CMAKE_INCLUDE_PATH to find some other component like GLUT,
but didn't want to accidentally include an older version of
OpenThreads located in the same area.
As the ultimate override, you can still pass -DVAR=value arguments to
cmake and it will take these above all else. However, it's safer for
people to not use these in case we modify the script and change the
variable names.
Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX}
searches in the Find module. As I've said before, this is kind of a
hack and the variable wasn't really intended to be used in this way.
And I just got bitten by it in some bad corner cases. The problem is
that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake
sets a default value for it (such as /usr/local). The problem is that
/usr/local may not be the place you want searched. If you wait to set
the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already
run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to
change the value in the GUI, it's too late if you had a stuff in
/usr/local because FIND_ already found something and won't change the
value when you reconfigure since it is already set. You will have to
manually change the value yourself. Furthermore, as another problem
example, on the Mac, /Library/Frameworks is supposed to be searched
before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in
/usr/local to be hit first which took me a really long time to
understand how this was happenning. The work around is that I must
push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to
conflict with anything else. But I think it would be much better if we
removed it entirely.
And with so many different environmental variables at our disposal, I
don't think we need this one:
(Checked by CMake automatically:)
CMAKE_INCLUDE_PATH
CMAKE_SYSTEM_INCLUDE_PATH
CMAKE_LIBRARY_PATH
CMAKE_SYSTEM_LIBRARY_PATH
PATH
LIB
(Checked by us:)
OPENTHREADS_INCLUDE_DIR
OPENTHREADS_LIBRARY_DIR
OPENTHREADS_DIR
OSG_INCLUDE_DIR
OSG_LIBRARY_DIR
OSG_DIR
"
I was using ${FOO_CONFIG_HAS_BEEN_RUN_BEFORE} instead of just
FOO_HAS_BEEN_RUN_BEFORE.
In this case, it happened to work out to still be correct, but in
general it shouldn't have the ${}. (I really hate this syntax.)"
Just as in the pre-r6419 I used the COIN_BASIC_H define in order to discriminate
between the two versions of Inventor.
Additionally, I had to change the CMakeLists.txt to use the proper include path.
"
"I was working on a new version of Inventor plugin.
It was inspired by the need to get correct and high quality conversion,
so I verified the plugin on complex models and made number of serious fixes:
- the geometry is not two times on the output file (!)
- SoVRMLImageTexture: VRML texture support was rewritten according to
Inventor programming practices, since it does not worked correctly on
many models (Anyway, thanks for Gerrick Bivins to introduce it.)
- osg::ref wrong usage related crash fixed
- code cleaning and texture code overhaul
- LOD fixes
- appended README.txt with all the contributors I was able to get from
SVN logs"
returned from Viewer::getContexts/getWindows will be the left most window on the lowest screen number.
Added ability for StatsHandler and HelpHandler to support end users setting their
Camera's graphics context.
a bug regarding when to set the debug version. It waited until both
include and library were set, but it shouldn't wait on include.
Also added a fix to the optional warning flags."
"Attached is a patch allows access access to the CMake MACOSX_BUNDLE
option. Now SETUP_APPLICATION and SETUP_EXAMPLE take an additional
optional parameter that specifies if the program is a command line
application or a GUI application (think: IS_COMMANDLINE_APP). Passing
1 means true (is_commandline_app). Passing 0 or omitting the parameter
means false.
I changed the scripts for osgversion and osgunittests to support this
option because I believe they are command line apps. Are there any
others?"
