On 6/5/07, E. Wing <[EMAIL PROTECTED]> wrote:
They are not crippled until your change.

Well yesterday we couldn't get OSG examples running properly.  Today
Martin's run through seeing which ones worked with a double click and
some run, but the ones that do don't find any fonts or textures.

Its very very simple, if an example doesn't run as it does on other
platforms its crippled.  Most OSG examples are designed to be run from
the command line, this keeps them simple and too the point - examples
of how to use the OSG API.

You cannot double-click
launch a non app bundle which makes bundless is crippled. Most Mac
users will be confused or assume osg programs can't be double-clicked
to launch. This is not good.

We aren't aimed at most Mac users, the OSG is for developers and
developers only.  Developers should be able to open a terminal and
type in some basic lines.

The instructions on the OSG website and the book are all about running
stuff from the command line, its wrong to have a cavete or special
documentation and rules for one platform.


And being on par isn't enough. A universally poor, but consistent user
experience is not what it is about.

The current app bundle experience is appalling.

Also have things consistent is crucial.  The examples are just a way
into learning about the OSG, its doesn't make sense to have different
ways of teaching people on different platforms.

This is the Java GUI affect. It
works the same on all platforms, but very few users are impressed.

The OSG is about graphics, about code, for developers not impressing
end users with pretty GUI's.


This is arguing the wrong thing. Users need to learn both. They need
to understand OSG, but they also need to understand the platform they
develop for. When users look to the examples, they are looking at both
the osg code, but also how it is put together for their platform.

There should be examples that illustrate how to use the OSG API.

There should be examples that illustrate how to integrate the OSG with
native GUI's and development frameworks.

All examples should not try to do both.  Each example should be
minimal and focused on its not task, there shouldn't be anything more
to it that is essential for it to illustrate its point.

When
there were Visual Studio projects, Xcode projects, and Makefiles,
users would not only look at the source code, but they would also try
to understand how to build the applications by looking at the
projects. Improperly building a project would be a disservice to the
user and ultimately a poor reflection on OSG itself. Now people are
going to look at our CMake system and are going to draw the wrong
conclusions. At the very least, the default option needs to be for an
.app bundle.

.app bundles right now are broken.  They don't perform at all good enough.


User experience and first impressions are important. Users have an
unconscious expectation of how a program should run on their platform.
When they run the application for the first time, the experience
should be positive. You want the person to say, 'Wow, OSG is great and
has a good understanding of what it does and also how to make it work
on my platform. They must know what they are doing. I want to use
it.'. You don't want them to say, 'Gee, this really sucks. They don't
understand my platform at all so they probably didn't do many other
things right.' and move on to something else. It might not be true or
fair, but this is how people make judgments.

Well I certainly want the developer experience to be a positive one.
The vast majority of the changes to the OSG over the past 6 months
have been about this.  The unified build system, moving to single
download single build package, introducing a new viewer library to
better solve the problems that users have to tackle, the book.


This week I have Martin and his Mac Pro, its a great opportunity for
me to see how things are working under OSX and get things stable and
working as well as under other platforms.  Yesterday we got the CMake
build up to useful point.  Now we've got all the examples working I'm
pretty pleased with how things are looking and behaving under OSX,
Stephan's work on GraphicsWindowCarbon really has made things work
more slickly than things have ever been under OSX which is great.

Today I've tasked Martin with trying to get a Xcode build up to see
how close we are to getting things ready for 2.0.   There are a few
examples that are crashing, and the hangs that Stephan reported, so
we'll look into these.

Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to