[Bf-committers] 2.5 release

[Erwin Coumans]

The Game menu and function are hidden behind some toggle, which is a pity.
Why can't we have the Game menu always enabled, and greyed out with an
'enable' entry,
that automatically selects this 'engine toggle'?

Cheers,
Erwin



2009/11/17 blendenzo <blendenzo at blendenzo.com>

> I can attest to the amount of time which can be wasted looking for
> buttons that are not there.  I recently spent half an hour searching for
> the Texture Face settings which are used to give special properties to
> faces in the game engine, only to find that they have not yet been added
> (even though the functionality which they represent is already present
> in 2.5).
>
> Personally I am in favor of having the UI as representative of the final
> UI as is possible, even if it means some grayed out buttons or "feature
> not yet implemented" popups.  However, I also recognize that this would
> mean a substantial amount of unplanned for work before first release, so
> I won't be surprised if it doesn't happen.
>
> Knapp wrote:
> > OK, I can see this point but the other side of it is that we (advanced
> > users in both senses) are using it to try it out and to find bugs but
> > also to learn it, so that we can help the next wave of users. If I see
> > a button is missing, for example the play rendered animations button,
> > I go looking for it. If I find it, then I know where it is and have
> > learned that bit. If on the other hand buttons pop up later, I might
> > already know that they are not there (falsely) or never think to look.
> >
> > I think to solve your point, a message should pop up saying something
> > like, "Not Yet Implemented", just as it would on a beta web site.
> >
> > The other plus of this, from a design point, is that we have a well
> > designed UI. Putting together a UI in bits is how we ended up with the
> > mess that is the 2.49 UI. It was made by years of people adding bits
> > here and there as best they could. 2.5 is a total redesign to address
> > problems like this, at least I think it is. Why not decide where all
> > the button will go early on? Maybe even plan for buttons that might be
> > needed years down the road. (not saying they should be seen yet)
> >
> > Also the work is not useless, if the buttons go to planed but not yet
> > implemented features. The UI is a totally key part of the puzzle of
> > making a great work flow and a great piece of software. It should be
> > one of the most thought out and tested bits of the whole thing.
> >
> > A bit of auto testing would not be a bad thing. :-)
> >
> > On Tue, Nov 17, 2009 at 4:31 PM, Roger Wickes <rogerwickes at yahoo.com>
> wrote:
> >
> >> With all due respect, I disagree totally with the request to add
> >> all button, even if they go nowhere. I think it is misleading,
> >> and a lot of useless work, to put in buttons that go nowhere.
> >> I would only agree if we were using an automated GUI testing
> >> tool that clicked on certain coordinates in executing the script.
> >> In that case, we would want to preserve those coordinates
> >> for later regression testing. If the goal of the release was to
> >> get feedback/work out UI placement and arrangement, cool,
> >> but that is not one of the goals of the release, afaik.
> >>
> >> Users that see a button like to click it. Otherwise, you are
> >> introducing a decision point into the process, which is "Is this
> >> feature implemented in this beta?" and I would bet dollars to
> >> donuts they would not know. Hence, if a feature WAS supposed
> >> to be in there, but was broken, clicking the button with no response
> >> masks the error, as the user will assume it was not in the release.
> >>  ----------------
> >> Sent by Roger Wickes for intended recipient. If you are not the intended
> recipient, please delete this message and contact Mr. Wickes immediately.
> >>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>