[Bf-taskforce25] User Preferences Mockup and Suggestion

[Brian Staub]

hi Brecht.

i was hoping that a design based on my mockup would be able to scale based on the content, so if new options and sections are added the Pref Pane would expand accordingly.  I was hoping the upcoming Auto Layout Code could handle something like this.  Would Python be able to create the Pref Pane as it appears in the mockup without having to create a new Window Type in the core code?  (please excuse my ignorance, i'm not a coder and don't understand the difficulties).  i think having Prefs as a standard Window is rather obtrusive, having to resize windows and whatnot to change a Prefs setting, even if it's Automatice.  not to brag, but i think this is an excellent solution, and maybe worth a new Window type if Python can't compensate.  In addition, it could be incredibly unintrusive if all windows remain responsive while the Pane is visible.  also in my design, i liked the idea of the Top Bar being absolutely stationary (not dragable), which provides
 consistency because you can always find those options, Prefs, File, Edit, etc. in the same place all of the time.

thanks for any consideration.

brian

________________________________
  my site-click here to visit
________________________________
system specs:
OS X 10.5.6
17" 'Unibody' MacbookPro, 2.66 GHz Intel Core 2 Duo w/ 6MB shared L2 cache on 1.07 GHz FSB
4 GB DDR3 SDRAM
128 GB Solid State Drive
NVIDIA GeForce 9600M GT discrete graphics w/ 512 MB VRAM and NVIDIA GeForce 9400M integrated graphics w/ 256 MB VRAM, 1920 x 1200 native resolution




________________________________
From: Brecht Van Lommel <brecht at blender.org>
To: The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
Sent: Wednesday, April 1, 2009 2:35:46 PM
Subject: Re: [Bf-taskforce25] User Preferences Mockup and Suggestion

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.


_______________________________________________
Bf-taskforce25 mailing list
Bf-taskforce25 at blender.org
http://lists.blender.org/mailman/listinfo/bf-taskforce25



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090401/31bd6be9/attachment.htm