[Bf-committers] UI issues, both ideas and review of t3

[GSR]

Hi:

It seems UI changes are approaching, so lets do a review of things
that could be done and what I have seen in T3. There have been other
similar posts time ago as
http://projects.blender.org/pipermail/bf-funboard/2003-October/001240.html
http://projects.blender.org/pipermail/bf-committers/2004-November/008314.html

The following points are sometimes from people in IRC or lists,
sometimes mine. I will try to credit, if I forgot people or change
names, please say so. Sometimes I refer to what I have seen in code,
but that is a bit secondary I guess, just for reference.


1. Tool box menu:

T3 and iblender have a menu in which the items always appear top to
bottom and open left to right, if there is space on screen. As it also
requires less space and you can easily predict the size, the forced
flip happens less as it is even easier to avoid (current one too... by
most of times going to center of screen to be sure you are in safe
place).

I think it should be ported. It could even be default, after all it is
labeled "Easy Toolbox", muscle memory is there in more cases, movement
is smaller and path repeats lots of time (top left to bottom right
flow).

It could be named "Plain" too.... ooh, I discovered why I had in mind
that it could be renamed, but wondered why "Easy" did not sound so
lame now, or derogatory against people that want to just guess less
the position of items. It has been already got a name change in the
past (2005/01/17), that is why. Bad luck that I saw the original name
while it was in use... tiny time window, but it seems I managed to
check it out then.


2. Menu flipping:

Related to previous point, menu entries should not flip, as it goes
againt muscle memory. If order can be up or down, you have to let your
brain take over and think or sometimes even read the entries one by
one. If they always appear in same place, basic motion systems see the
rectangle as a context and start to go to the entry with minimal brain
load.

I think Hos was interested in this. I changed own copies to get it
(quicky patch, always return from flipper function), correct would be
disabling in callers or make conditional return based in user pref if
people want to keep the flipping feature.


3. Menu hinting for shortcuts:

Any menu that works with numbers and alt+numbers should have the hint
visible. It would give a clue of what can be done, and for those that
already know about the keys, it would simplify counting to just
reading a number.


4. Huge menus in materials, etc:

When you have many materials, bones, textures... you get a really huge
menu (and in some cases there is a text entry that could make use of
this menu helper too). IMO, for a given size, it should do bilevel
menus, and keep single level for small lists.

It has been commented some times in IRC. Take 20 top level entries,
with 20 level-2 entries, that means 200 items with space requirement
of two menu rectangles. Other values are also possible, 15 and 15, or
even different like 15 (top) and 25 (childs). Just that 20 & 20 seem a
sweet spot, as it is big and can work with menu hinting / keys.

The main unsolved issue is deciding how to sort the items. In general,
alphabetically, but how to make the divisions? If there are less than
top entries, that is easy, no childs.

But if for example, with 20 & 20, you have 21 items? Use two top level
and the two childs with 20 and 1 respectively? Childs with 11 and 10?
Try to make more in top level, for example 4 and childs with 6 5 5 and
5? OK, that is the meat of the issue.

I think it was zr one of the persons that talked about this.


5. Floating panels behaviour:

It would be nice if colapse was in place, for the same muscle memory
and spatial reasoning that with other things. Title could work as
colapse area with double click, as it is happens in some X11 window
manager and old MacOS.

Auto go away with pin button would be interesting too, as option. Some
people prefer to do the changes and keep on working with Blender style
(as with menus). Instead of user pref as proposed in old mails, it
could be per panel, starting in pin mode and then being remembered, so
users of "go away" would just need to hit the pin once.

Do not confuse with current pin option, that one is more like remember
place even if named pin. If anybody have a better idea for go away /
stay icon so it is not like a pin, I have no problem with using other
icon for the title bar.


6. Some theme updates:

I have seen people asking about non rounded corners. It is not hard to
implement IMO, just check theme and adjust round bit field. I think
minimal could at least be this way.

In general theme system seems a bit tricky as the conditional checks
seem to be done with if and numbers, instead of switch and #define or
enum, so sometimes things go weird (trying to reproduce a bug in which
theme style changed "magically"). I think it could be one of those
easy to do things.


7. Packed slider:

Blender could have more space if slider buttons get a bit like num
buttons. Or num buttons get a clear limited range mode for feedback in
some cases. Whichever point of view you prefer.

Current sliders are like:

+-----------------------------+
|                             |
| Text: Value I=====        I |
|                             |
+-----------------------------+

While num buttons are:

+---------------+
|               |
|< Text: Value >|
|               |
+---------------+

Idea would be:

+---------------+
|=====          |
|  Text: Value  |
|=====          |
+---------------+

Adventages of the packed mode are less space keeping the "empty
... half ... full" visual feedback. From a code point of view it could
even be two modes of same thing, arrows for huge range things vs bar
for small and clear limits (r, g, b, specular, etc).

The open issues are code reorg (from my experiments, it seems it would
be helpful to make drawing code simpler, with a top mask over all,
instead of trying to make rounded corners for everything).

And more important, the look for themes like rounded. For minimal
there are two options already, solid bicolour style (changes text
colour on overlap) or simple lines below and or above the text. The
others could be arrows, gauge... dunno. That is the meaty issue of
this.


8. Button area selector:

The buttons have grouping, I believe, to save space. As price, it
sacrifices direct access and breaks the mapping to F keys that existed
in old Blender.

IMO, it could be expanded back, keeping some grouping hints if
necesary, like 2 pix separation between groups or other visual clue
(roundness in the themes that can do so, for example). There are only
two groups currently, Materials and Render buttons, the others are
"single member groups".

Some will say expanding back will make things bigger. The real fact is
that there is no big saving, the saving is mostly due button
size. Check yourself, old blender (creator 2.21) had 14 buttons
(counting the 3d view and constraint ones that do not exist
anymore). New blender (T3 20050918) has 11 buttons in widest mode
(materials) and a separation sized like another button, so I would say
it has 12 "buttons".

It could be:

Logic F4
Script
Shading lamp              | F5
Shading meshes/curves/etc |
Shading world             |
Shading radiosity         |
Texture (as related to the shading) F6
Object F7
Editing F9
Render basics            | F10
Render anim (one panel?) |
Render audio             |

BTW, what is F8 supposed to do now? In T3 it jumps to Shading world,
as it did in Blender 1.x, but then it was considered separate
thing. Could Script be moved between Object and Editing and get F8? It
could also group with Logic and share F4, of course. Something else
that fits between them and deserves a key?


9. Multiple buttons for same key:

Take F10, it selects render buttons, but shares a group with two other
things. Pressing multiple times could cycle thru them if you are
already in the group.

I think Desoto mentioned this.


10. Mode selector:

A couple of issues with this. One that it is in each 3D window, while
it could be in buttons, which would make happy "multiple 3d view"
users but angry "vertical button" users, and indiferent to "single 3d
view with horizontal buttons" users.

The big issue is the mess it has, as it works as single option, while
the guts seem to allow multiple overlapping states. Old blender have
separate buttons, so you could see you had multiple modes on. Now with
VKEY, TAB and FKEY and probably something I miss you can jump between
modes, but it is rather hard where you will end or if all the keys
will work.

As I do not know the plans about the modes, I just mention it without
trying to guess solutions, hoping the logic and the interface match
more clearly again.


11. Vertical buttons:

Some people like it, see points about button area selector and mode
selector. Probably for vertical buttons, header should be split,
rotate to side or some other kind of solution, dunno. As I do not use
such style, I prefer to just note it down and let the users talk
about, and only participate in cases whhere the solutions affect the
other style (the counting of space used in button area selector due
grouping, for example).


12. Tabbed panels and keyboard:

Blender current tabbing forces a lot of clicks in tiny areas to toggle
things. With the work in T3, the tabbing of colliding concepts should
be zero and there have been lots of step in that sense. Still, a
method to access panel configs quickly would be great.

Possible solutions:

A. number keys activate the Nth panel tab in panel under
cursor. Should be easy to understand and use, but also repetitive and
somewhat inflexible. In some cases it would require pressing and
moving multiple times to get into other way of working (different
materials that require different combination of tabs, for example).

B. number keys show a different config (which panels are tabbed, which
are in front, which are colapsed), somewhat like layers do in 3d
areas. This would require a way to configure what each number shows,
but once the user sets his config, it would allow quicker workflow.


13. T3 general look:

By testing other themes, I find that grouping of buttons is not done
in some places, so the hinting of "what goes with what" is lost. Is
that on purpose? Otherwise, please, when doing UI changes, check other
themes and adjust code as needed.


14. T3 lamp buttons:

Specular, diffuse and layer change position, based in which kind of
lamp you have. They could stay fixed.


15. T3 material buttons:

Why seems to start with over 4 panels of width? At least the default
scene does, I thought the plan was trying to make things usable with
4. Maybe it is the same reason the order of panels seems a bit
chaotic, with transparency between Map to channels and Texture. I will
assume it is just an issue of the .B.blend, as wiki says 4.

Why is shadeless not in shading but in panel that is docked to the
preview? It should be Solid (extrange name, as making things with
Alpha will clearly show it seems to be a "shell"... ), Shaderless and
Halo. This way Shaderless would hide all the shaders that do nothing
when it is on (and yes, I know it would require some special coding to
match internal logic, I am pointing the behaviour user would expect
about "shading").

Wireframe could be in Shading group of settings instead of General.

Why is ambient slider also hidden even if you want to check the
preview? And again, makes no sense in shadeless or halo.

Shade as world is yet another case of a thing that makes shading
controls irrelevant, right? So could be Solid, Shadeless, World and
Halo. World could update preview to match.

Still talking about Shading panel, colour button and shader kind could
go in same line than text they refer to. Add packed sliders, and you
can have more controls, for shaders that require it, specially by
allowing a two column slider arrangement... for example avoiding
current arrangement in which Diffuse Toon puts Smooth slider in same
line than Specular label. Trying to arrange this panel in this way is
what gave me the idea of packed sliders, BTW. Packed slider would even
allow tree columns, for example for translucency, emit and ambient, if
names are shortened.

In Map to channels the Colour and the colour area seem to be
disconnected from the rest of channels buttons.

Sliders and toggle buttons seems to be placed separately. Colour is
near colour, but bump is not, while it could be. Also Displacement and
Warp sliders could be near the buttons that enable those mappings.

Transparency, nice thing that ztransp disables IOR controls. OTOH, it
should be only raytracing the one that enables, right?

Frensel buttons should be linked to what they relate, or some kind of
cue of what they are for, as sometimes the relation is in columns
(this) and sometimes in continous lines (shader sliders).


16. T3 texture buttons:

A bit pity that the control for brightness contrast is docked by
default. Would it be possible to make it fourth entry and ramp/colour
the third? That way it will dock with Image and Movie when using
Image, and be visible otherwise (in Image and Movie case, they should
by default take front place). My idea is that people should not have
to play with panels, but good default instead.

It makes sense most people will not use ramp or colour with
images. And adjusting brightness and contrast seems a bit rare with
movies too, you would prefer to have the movie set before loading, as
you can not animate the control, but a bit more common with single
image.

To sum up: Preview, Texture, Image | Controls, Movie | Adjust.

Preview could have a button to show the material one, instead of the
texture only, if that is possible. That would reduce the current
problem of flipping from textures to material buttons and back to
adjust things.


17. T3 radio buttons:

Again another case of things in columns but not grouped, so you wonder
where the relation to Elements and Patches labels ends. They could be
four panels, separating Elements and Patches to their own panel, with
Collect meshes and Free radio data in Calculation panel, probably
renaming it to Operations, and display in the blank area of Radio
Render panel.

So you have first Operations (or Commands, current Calculation plus
two button replacing display buttons), then General and Preview
(single tab, current Radio Render plus preview controls), with
Elements as third and Patches panel as fourth.

Why do general setting appear before collecting meshes btw? To allow
changes for pre render radiosity? Would not then the rest of controls
also be required?


18. T3 world buttons:

No ambient colour area, but all using visible slider. I think I read
in ML someone pointing this, so all places used same style (which now
seems to be an area that popups the selector). Doing it would open
path to other arrangements.

For example: Preview panel could have the name selector on top, three
colour areas with label and the Exp and Range sliders in the side
middle and bottom. We won a panel.

Mist and stars... again columns without 100% clear hints. And engine
things on top. Wiki talks about making engine things be with preview,
which I guess is good, as done in materials.

Texture could use a menu like texture panel in material objects, so
you can select View, Angmap etc from it.

Use the channel we won to undock Map to. Try to make it follow the
same style than in material objects, but not being so picky about
space, as it has less things.


...hhhm...errr I think I will do a part 2 email with object, editing
and scene buttons, as this one has become huge already and is
late. Some of those button areas have suffered changes that make T3
and wiki out of sync with Blender internal, so they require a three
way check, I guess (T3, CVS, older). You have enough thinking fuel
with this one. ;] More in next days.

GSR