Hi Eric, I've already made my decision and made it clear, creating bundles for the example will be set by default to OFF for the CMake Makefile build. This makes it consistent with old Makefile build system, and keeps it consistent with the rest of the OSG world, OSG documentation and the runexamples.bat test script.
XCode projects are mostly working, and still support bundles. When XCode support comes to CMake then it seems reasonable to have the bundles built for the examples. Frankly I'm not impressed with the direction things had taken under OSX, too many things were broken. Neither I'm impressed with the shrill reactions I've got with trying to fix things to work as they once did. The deeply OSX centric viewpoint has worn very thin. I am committed to getting things working under OSX, but I am also committed to keeping platforms specifics to a minimum, this is a cross platforms project, as much of the code base and build systems need to kept a portable and generally applicable as possible. This has always been a guiding principle to the OSG, and it will always be this way while I'm project lead. Robert. On 6/6/07, E. Wing <[EMAIL PROTECTED]> wrote:
> We aren't aimed at most Mac users, the OSG is for developers and > developers only. Most people touching OSG on Mac are going to be both OSG and Mac developers. It is not mutually exclusive. Most people buy Macs because of the experience it brings so people are actually looking for this stuff if they have a Mac. Steve Jobs didn't put a gun to anybody's head and force them to buy a Mac. There are lots of choices out there for those who don't like the Mac ways. If the developer is expecting the exact, must run on a command line behavior for an osg example that they got on some other system, then the they already know OSG and and the running the examples exactly the same way through the command line is meaningless information. If they already know OSG, the benefit is in seeing what the stuff they don't already know. And chances are the user on the Mac knows the GUI concept and double-click concept that they might just try that before doing anything else. Also, don't discount non-developers at looking at this stuff either. For one, think of product managers who make decisions about what technologies to use. They also look at these things. > Developers should be able to open a terminal and > type in some basic lines. I've met a surprising number of Windows developers that have never touched the command line. > The OSG is about graphics, about code, for developers not impressing > end users with pretty GUI's. Nope, it's like selling your car. It might run great and the tires might be brand new. But if you don't wash it, people are going to assume the worst. All the aspects make up the whole experience. You might only care about the OSG parts, but a new user is going to judge the product by the whole experience because they have not been trained to focus on the single aspect. Remember that you are not your user. For the user, if the parts they are familiar with don't work within their expected world view, they are going to be distracted from seeing the things you really want them to see because they are too focused with the things they know are wrong. > There should be examples that illustrate how to use the OSG API. And the bundled built product doesn't impact/change the OSG API or the example source code at all. They will learn OSG no better without the bundle. > open mybundledapp.app "args" I forgot about this one. It might work, but you might need to disambiguate using the -a switch. open -a mybundledapp.app "args" (Stuff on shell scripts for launching) Shell scripts are difficult to work with from the UI/double-click side. There used to be a trick where if you gave a shell script a .command extension, you could launch it through Finder. But I think this behavior no longer works or at least is totally unreliable. For me, scripts now open in TextEdit. (Some cite security concerns, thought I don't know the real reason. It could be something as simple as something remapped the .command extension to open in TextEdit. But again, this is the problem about undocumented behavior.) Assuming you could launch via double-clicking, the general problem with this technique is that I believe your current path gets set to the root of the file system so the problem is your script cannot find any of your programs unless you know the absolute path. A secondary issue is you can't rely on any environmental variables being set. > Well I certainly want the developer experience to be a positive one. Well I'm glad we agree on this at least. But you should have some trust in your experts that know the platform. You say a lot of negative things about the platform and the things I bring up because I think they will improve things for OSG/Mac users, and honestly, I'm starting to take it personally. I know some times you shoot down my issues because they may negatively impact other platforms and I accept that, but this specific issue is a pure Mac issue. > .app bundles right now are broken. They don't perform at all good enough. And I also agree with you on this point. But there is a very easy solution for that; for examples that require command line arguments now, provide a default value within the example code itself if no arguments are passed in e.g. "cessna.osg". It doesn't impact the OSG API, it's portable as all platforms will benefit the same way, and it doesn't interfere with preexisting behavior. Particularly for both Windows and Mac, I think this is a great solution. Windows won't require a shell script to run the things any more as a user can just pick what they want to run. All too often I see an program in Explorer or Finder and say, "Gee, that looks interesting. I wonder what that is." When I double-click, I curse and say, crap, I have to open a command line and figure out what the command line parameters are. (And personally, I don't have the patience to skip through 10 apps to see the one I want to see. Imagine if you asked somebody to skip through 10 songs in a music playlist because they couldn't select a specific one.) I would be willing to help modify the examples to provide a default argument so you don't have to do it. As for the osgViewer application, the way to handle it is to allow the viewer to load either empty or a default model (could just be an osgText string with simple instructions), and then allow the user to load a model at run time if no command line argument is specified. From a Windows and Mac vantage point, the question is, why is there no File Open dialog? Menu->File->Open is almost hard coded into the brain now. There are also other ways to load models. osgsimpleviewerCocoa uses drag-and-drop to allow models to be loaded and changed. Another way is to support dragging the file onto the program's icon. Another way is to register certain file types like .osg, so if the user double-clicks on the model file, it starts the osgViewer program. People are very familiar with this too. Of course, the command line should continue to be available and work as it always has. I am not anti-command line by any means. > 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 problem is that this is still unsupported Mac behavior and it is bad in general. So this is still not a good idea. Also, as I do actually create documentation for this stuff and try to help with on questions on and off the mailing list, it's not an issue I really want to deal with (command line launching has already been documented for quite awhile). Finally, if/when GraphicsWindowCocoa finally comes around, I don't want this to be an arbitrary political barrier in the way if it turns out this hack doesn't work with that implementation. As a compromise, I'm willing to drop the subject if you keep the option, but make the default option Bundle, and put a comment in the CMake script and description (doesn't have to be a MESSAGE) warning users that changing the default relies on unsupported behavior and is subject to break and will not be supported by us. I'll even type in the changes myself so you don't have to. Then you and anybody else can continue using it bundless and I can close my eyes and stick my fingers in my ears when somebody down the road has problems :) Thanks, Eric _______________________________________________ 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/
