[Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
gaia.clary at machinimatrix.org
Sun Jul 7 11:53:28 CEST 2013
I realize that i use only a certain part of blender.
So what about trying to solve the problem of
"too big menus" generically via customization?
I know this is nothing that can be done on a weekend.
But i also believe that thinking about solutions should
not be ruled by "can be done quickly" arguments.
So what about allowing users to customize as follows:
- remove entries from the menus
- allow changing the order of entries
- And still keep a quick access to "all" entries
Here is a mockup i made with an image editor:
* When user clicks on the "C" icon, a custom menu editor
opens up. There users can add/remove entries from
the menu as wanted. They further can move entries
up and down (change order)
* When user clicks on the "All" icon, then all hidden
entries show up maybe marked with a slightly different
background so the extra entries can be identified easily.
The "hidden" entries could be mixed into the list,
Or collected at top/bottom of the menu ,
or in a 2nd column...
* User can switch back to custom setting by clicking
on the All icon again (ok, maybe the name is bad)
* This could be used in all menus. Or maybe only in
menus having more than a certain number of entries.
* In theory this could also allow to add other operators
to the custom menu.
The customization can be stored with the blend file or
stored with the user preferences.
On 07.07.2013 10:48, Thomas Dinges wrote:
> I am not sure what to make of these new layouts yet, imho it's more
> complicated to scan 3 columns with no description or misleading title,
> than scanning through the list we have know.
> So I am not convinced here yet. ;)
> Am 07.07.2013 06:53, schrieb Gavin Howard:
>> +1 to the last 3-column layout with no headers.
>> Gavin H.
>> On Sat, Jul 6, 2013 at 10:36 PM, David Jeske <davidj at gmail.com> wrote:
>>>> Maybe something like this, with 2 columns:
>>>> Not saying this is ideal, but I think trying to fit everything in
>>>> columns with a single title per column constraints things too much.
>>> I think any of these non-flipping layouts would be a big improvement. The
>>> reason I'm going wider is to keep the common views within mouse-reach when
>>> menu opens "up". Below is a reachability comparison. I think the
>>> difference in everyday usability would be significant. (Keeping 3d-view
>>> close is one of the justifications I hear for today's "flipping" menus)
>>> As for the headers, we could just drop them. They are not a very important
>>> part of layout waypointing, memory, or everyday usability. They are mostly
>>> for new-users to get some idea what the categories are. However, if there
>>> isn't enough ontological correctness they confuse more than help.
>>> What do you/folks think about this 3 column layout? .. with no headers
>>> It's the same as your ordering, except I put Node-Editor with the "main"
>>> stuff on the left because I think the compositor is as good a "main view /
>>> start-point" as the other things over there. (ignore the kind of nasty
>>> extra space below "Editor Type".. it's a byproduct of the current menu code
>>> and could be fixed)
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> Bf-committers mailing list
>> Bf-committers at blender.org
More information about the Bf-committers