[Bf-taskforce25] User Preferences Mockup and Suggestion

Wed Apr 1 23:08:48 CEST 2009

It is not a matter of dictatorship, but how Brecht said, consistence is very
important! And those rules makes Blender better, IMHO. I think this
discussion here guides us to this question: Setting preferences is part of
the pipeline production? If yes, it needs to follow the rules proposed. But
if not, may be it can be done using other suggestions, like Rob said about
the Color pick, for example? I don't have the answers, I am just an user.
And I trully believe in consistence, BUT the Brian's idea is really nice
either, 'cause we not spend long time setting up. May be to make a new
theme, or setting new hotkeys (in the future) for example, but those things
doesn't sound to be part of the production pipeline. At least wasn't for me
until now. Correct me if I'm wrong.

Cheers.

Moraes Junior - aka mangojambo
3D Artist Animator

2009/4/1 Brian Staub <brian.staub at yahoo.com>

> Agreed!  you're creating a dictatorship in coding if you say everything
> must be a window like all others, even when there's a case where it's not
> the best option and could potentially be messier than an alternative
> solution that is being discounted to follow such a "law".  overlapping
> doesn't necessarily mean "in the way" if it's the user's specific intention
> of having that window open (and might i add, easily exited window [i.e.
> hotkey]) to change settings which kind of have base-level effect, not on a
> particular scene per say, but on all future scenes as well.  that's why i
> think the User Preferences is the reigning champion for such a "compromise"
> to the "non-overlapping" paradigm.
>
> thanks for any consideration
>
> brian
>
>
> *From:* Rob Cozzens <robcozzens at gmail.com>
> *To:* The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
> *Sent:* Wednesday, April 1, 2009 3:18:31 PM
>
> *Subject:* Re: [Bf-taskforce25] User Preferences Mockup and Suggestion
>
> It seems like the only alternative to a floating window is taking over an
> existing view... I can't stand that!There are certain tasks that make
> sense for floating windows (dialogs): loading/saving, color pickers etc. and
> I think preferences is one of those cases that makes sense with a dialog.
>
> The non-overlapping paradigm makes sense for windows that you need to have
> open all the time for you workflow. Anything that's going to pop-up
> temporarily could be a floating window IMHO.
>
> -Rob
>
> 2009/4/1 Brian Staub <brian.staub at yahoo.com>
>
>> 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 <http://invertednormal.wordpress.com/>
>> ------------------------------
>> 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
>>
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>
>
> _______________________________________________
> 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/b0d9837b/attachment.htm 