Hi Garret, I'm not of the opinion of axing support for Bundles or Frameworks if users want them for their own applications. Now for OSX developers who use the OSG and wish to use Frameworks then the OSG itself needs to support it. Its different for Bundling of the OSG examples, this has no baring on how OSX developer need distribute their own apps.
Right now Bundling of examples are broken for most of the examples, its madness to pretend anything otherwise. The majority of OSG examples are command line examples, this is they way they are and always will be, adding in GUI and extra build complexities for simple examples defeats their purpose. They are simple OSG examples. They aren't example to show off platform specific features, or the rightous way doing things on platform Y, they are about the OSG plain and simple, its about those lines of code in the .cpp. As far as I'm aware neither the current version of CMake and our CMAke build system is not ready to build Frameworks. For me this is the big missing feature, and the only really important one for me, this is what OSX users really need. XCode and bundles are just niceties for those who like to use XCode and click on example rather opening a win term. Since CMake build isn't yet up to build Frameworks under Makefiles or XCode the old XCode project files are still checked into the OSG's SVN. Martin has just downloaded the latest XCode 2.4 as 2.1 didn't work with them, so will be giving them a try. I believe the XCode projects have actually been broken for most of the past 9 months, I don't know how much work it will be to get them working once more. If they can't be fixed in time for 2.0 then really shouldn't be in there. A CMake Makefile based build that actually works, albeot with not all features that all OSX users might desire is infinitely better than a XCode project that doesn't work at all. Long term having the XCode project separate for CMake is not viable, the XCode projects have been broken for most of their life as part of the core OSG, they are impossible for me to maintain and this means they break often, and when they break they harm OSX users experience. The cost in maintaining them also waste our precious time, time that could be spent fixing real bugs, adding real features, writing documentation... Integrating XCode projects into the OSG has already cost us alot, and trying to fix up the projects was a major factor in me developing RSI. This sucks. Robert. On 6/5/07, Garrett Potts <[EMAIL PROTECTED]> wrote:
Hello All: I have been reading through the threads on the topic and I am a little nervous on the direction that it appears to be taking. If all could please clarify. Reading the emails it almost appears that we are trying to "axe" everything that brings the native experience of a MAC to the end user. It would be a shame to see something that has the attitude of "it's just easier to do it this way let's just forget about bundles and frameworks", hey it works. True, it might work, but like Eric has said this is not the standard MAC way of doing it and might not work in the future. Now for running command line args, I have not fully tested since it probably depends on the install_name setup but you can use the open command to open an application bundle and also, I do believe, that you can pass quoted arguments to the application: open mybundledapp.app "args" Eric W. is this true? It seems to me that CMake needs to be fixed and not let's "cripple" the native experience due to lack of support on the CMake part for bundles and frameworks. In all fairness every platform has a different tweak to enjoy the native experience that the platform offers. Just my opinion, until CMake is fixed I would not prematurely get rid of the xcode projects. Not sure if that was under consideration as well. Take care Garrett On Jun 5, 2007, at 5:50 AM, Robert Osfield wrote: > Hi Stephan, > > I was going to suggest what you have just done - Makefile build > without bundles, Xcode build with bundles, this is in effect the way > its been under OSX even before CMake. > > The caveat to this many (most) of the examples require command line > parameters, even the osgviewer example requires command line > parameters, so one is left with the question about what to do about > all these examples. Can bundles be built to run with a default > command line option? Can bundles be built to run a simple script > which allows the user to specify command line options and files? If > this is possible how might we go about specifying this per example. > Also if you go this approach, how might you might it work for point > and click running of example on all platforms? > > Lots of question that we won't be able to answer before 2.0, but > something to think about post 2.0. Right now the task is making sure > that things compile and run stable. > > Robert. > > On 6/5/07, Stephan Maximilian Huber <[EMAIL PROTECTED]> wrote: >> Hi, >> >> to chime in: I am missing the functionality to run a script to see if >> all examples do work as expected. So I vote for bundleless >> examples. The >> whole OS X stuff should be documented well so people know, what to >> do, >> if they want bundled examples. >> >> Perhaps when cmake creates XCode-project files, then the examples >> should >> be compiled as bundles so they will run from inside XCode. There >> you can >> specify optional command line arguments and env-vars and there you'll >> see in the run-log, what happened when an app could not start. >> >> When compiling the unix-way with makefiles from cMake then the >> example >> should be build not as bundles, so they work as expected. >> >> So both sides get their best: OS X developers used to XCode get >> bundles >> and unix-hacker get bundleless apps :) >> >> Any news about building frameworks from cMake either with XCode or >> with >> MakeFiles? >> >> >> just my two cents, >> >> Stephan >> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@openscenegraph.net >> http://openscenegraph.net/mailman/listinfo/osg-users >> http://www.openscenegraph.org/ >> > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
