[Bf-taskforce25] User Preferences Mockup and Suggestion

[Brecht Van Lommel]

Hi Brian,

On Wed, 2009-04-01 at 09:47 -0700, Brian Staub wrote:
> I've created a Mockup of how i think the User Preferences Pane would
> work well (i'm not a coder, so this is just conceptual artwork)
> 
> http://i307.photobucket.com/albums/nn291/bobStaub/preferencesPanelMockup00.jpg
> 
> the idea is that when you click on the User Preferences Icon at top
> left (or wherever), the Preference Pane does a "Shelf" Pull Down
> animation like with some Mac OS X panes and the user gets access to
> settings organized by tabs.  Other Panels/Windows are still responsive
> (as to not interfere with non-modality) and the Preference Pane stays
> open until user hits Escape (or whatever assigned hotkey), presses the
> 'X', or presses the Preferences Button again which is highlited when
> active.
> 
> ...and there's a full screen shot, too.
> 
> http://i307.photobucket.com/albums/nn291/bobStaub/preferencesMockupFlat00.jpg

The idea at Wintercamp as I remember was that user preferences would be
an editor like any other, in particular like a buttons window.

There are a few reasons for this. First is that it is consistent and
doesn't introduce a new type of window, we just do the same thing as the
buttons window.

Second, using panels means we can easily add more options. With the
fixed layout as in the current user preferences and in your mockup,
after a while it becomes difficult to add more settings without
rearranging, and then you get a mess quickly. With panels it's easy to
add something at the end, or add a new panel.

That still doesn't provide a good answer to where the window should
appear, replacing an existing editor often gives strange results. With
overlapping you don't have that problem, but it also goes against the
non-overlapping paradigm...
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/UIParadigms

> on another note, has it been decided what the max resolution will be
> for icons?  since Jendrzych has a handle on the low res icons, I
> thought i might try my hand at a higher res set.
> 
> here's an icon i helped Jendrzych with
> http://i307.photobucket.com/albums/nn291/bobStaub/shrinkwrapModifier7_00.png
> 
> and for my own set at a higher res for the Shrinkwrap, i came up with
> this quickly
> 
> http://i307.photobucket.com/albums/nn291/bobStaub/shrinkwrap32px_00.png

I think the attitude on this is, we'll wait and see if they are needed
and what they are needed for. If they are added that will be as a
function of some interface element that needs it.

We currently have icons mostly for data types and settings. It's not
clear where bigger versions of those would be used? For operators in a
toolbar bigger than current headers they could be needed, but we don't
have icons for operators currently, and there will be thousands of
operators? We don't have a good answer to these yet I think, it will
depend on design decisions that are not taken yet.

Brecht.