[Bf-committers] Panels (was Re: Undo system design)

[GSR - FR]

roel at spruitje.nl (2004-11-17 at 2106.19 +0100):
> I'm a bit confused, what kind of docking are we talking about?
> you can already collapse panels to the bottom of the 3d view...
> 
> Roel
> 
> -----Oorspronkelijk bericht-----
> Van: bf-committers-bounces at projects.blender.org
> [mailto:bf-committers-bounces at projects.blender.org]Namens Jean-Luc
> Peuriere
> Verzonden: woensdag 17 november 2004 21:01
> Aan: bf-blender developers
> Onderwerp: Re: [Bf-committers] Undo system design
> 
> 
> 
> Le 17 nov. 04, à 20:08, Alexander Ewering a écrit :
> > I like the secondary headerbars in instinctive-blender a lot better:
> >
> > http://pub.instinctive.de/newui.png
> >
> 
> I'm very surprised to agree with Alexander on UI design stuff, but his
> secondary bar is good.
> 
> However, I like panels too, and the solution of docking them has some
> appeal.
> 
> --
> Jean-Luc (lukep)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers

But they do not collapse in place, so it is a hunt task, uncollapse in
bottom, they jump to top... and then you can do things. Fast... not.

I have been passing arround some ideas about the panels, both floating
or button windows, and have recieved positive comments from some
people already, like WH or basse. These ideas are more conservative
than intrr edge "header" (or less, he is testing old "out of the way"
style), but I think the general idea is that things can be improved,
otherwise we would not be talking about this:

[Note: I have not followed Blender changes in last months, so I could
be pointing things already solved in some other way]

1. Floating panel key toogle (new and solved in clearest case)

Any panels that have a keycombo as launcher will have it as close key
too. IE, NKEY NKEY to make the obj panel flash.

The purpose is making errors quickly fixable, as well as
confirmations, if you use mouse for input between key presses or just
want info.

NKEY one already does it, good example to follow. Just take note and
do the same where applicable.



2. Floating panels, new mode (some changes)

Currently you have to hit Esc or hit the X to close panels and they
jump arround from invokation to invokation. Every time a panel is
invoked, it should appear in the place it was closed last time instead
(already done with sticky pref). It should shade / collapse in place
too.

The purpose of this is to make panels more like persistent objects and
avoid mouse traveling trying to hunt them.



3. Floating panels, old style mode (all new)

Mouse out and Esc will close the panel. To keep on screen, user will
hit the Sticky icon that has replaced the X icon, and the icon will
change to show the panel will stay. To vanish, UnStick it and move
out, or just Esc (auto unsticks). Panels when in this mode will always
appear under cursor. Shade / collapse will be in place (and assumes
pinning then).

Quick sketch of the icons (based in the size of the X one, it could be
used directly, there is not much space to do complex things), two
states:

 #####  <- Icon meaning "stick me", start status
  ###      (panel will vanish in mouse out)
 #####
#######      #####  <- Icon meaning "i am sticked",
   #          ###      user have clicked "stick me"
   #         #####     (panel will stay on mouse out)
   #        #######
                    <- Both align like this ASCII art, so
                       the tip "disappears" and the head moves
                       making pretty clear that the poster pin is
                       keeping the panel attached to screen

The purpose of this point is making the old style (prefered by some
due the "speed" it had in the workflow) come back, and improve it to
allow persistance when the user has the need. Do not confuse with
current sticky feature.

Old / New mode will be a UI pref, default New.



4. Button window panels (all new)

I realized why I (and probably others) hate the new panel system:
workflow suffers compared to a non panelized one. And I doubt anybody
is going to demostrate that having to click tabs every now and then is
faster than not doing it at all. Yes, there are more things now... but
there is not excuse that related things are harder to access, same way
you do not get F7's Effect tab with F5's Material tab (they are
grouped with some logic, and the groups attached to F4-F10 keys).

Some posible solutions:

A. Simplest one: when cursor is over a panel, 1KEY ... 0KEY activates
the 1st ... 10th subtab of that panel, like if you had clicked the
subtab header. Basic Blender's two hand operation principle.

Take material panels for example:

Preview | Material Ramps | Shaders MirrorTransp | Texture MapInput MapTo

When you are working here, you are going to look a lot at Preview, and
then play around with the two or three items of each panel. Spatially
they are grouped correctly, but for workflow (that is, the "time
dimension" and the required mouse ops) they are completly setup
against the user. I would say that default grouping is wrong.

Key activation would improve workflow.


B. A bit more complex: when cursor is over buttons window, 1KEY
... 0KEY activates the 1st ... 10th subtab of each panel in the area,
like if you had clicked all the headers. If a panel has no Nth, it
does not change. Two hand operation principle again, plus related
items are visible.

Case A is simplest for users to understand, but B gives a bigger user
control. It is like the buttons area top level concept, but applicated
at sublevel. When you edit, you want the buttons area set to edit
mode. When you change mappings of a material, you want the mappings,
not the colour or the shaders. But current panel system forces you to
being clicking to jump around and just see what you have.

As in solution A, speed would go a bit up due not having to move the
pointer to the header, click the not so big target and move back to
the place you want. Both, A and B, can be implemented at the same
time, just make the activation be linked or not, like layers setting
can be linked among all 3d views.

For global view of related items they are still wrong, you have to
flip while precious space is wasted in things you are not
interested. When you are working in the global look, you are
interested in Shaders and MirrorTransp as a whole, while Texture and
both Maps are not useful at that moment (right?).

Now using multi activate of case B, and showing active tabs as upper
case, you could easily get while hitting 1KEY, 2KEY and 3KEY:

PREVIEW | MATERIAL Shaders Texture | RAMPS MirrorTransp MapTo | MAPINPUT

PREVIEW | Material SHADERS Texture | Ramps MIRRORTRANSP MapTo | MAPINPUT

PREVIEW | Material Shaders TEXTURE | Ramps MirrorTransp MAPTO | MAPINPUT

Yes, MapInput is some kind of fan that likes to appear in all photos,
that is a problem. But at least you can arrange, most of the times,
the four or so things you want at the same time and view and control
them without spending time changing.

Key activation would improve workflow.


C. Make button view have multiple configs, activable by key, 10
possible combos. Same principle than when you hit F5 or similar keys,
you want to see a concept, not every possible panel. Defaults would
have to be very well thought, showing the related items, as explained
in B.

To reuse Blender concepts, panels could have visibility layers, the
keys would select which one. So to configure use MKEY and click in the
array of small buttons. Of course, panels will be able to live in
different coords in each "layer". But there is no need of inventing a
completly new widget system to handle this.

OK, someone will say that is a bad idea cos you are abusing the layers
widget but panels will not behave like when you toggle layers, lets
say it is painted a bit different to show they are not same layers,
just using same keys. An addition that should be considered is some
way to configure those panels that are not visible (you have to have a
Material to be able to see MapInput, which is not nice, you should be
able to rearrange without materials).

New defaults based in relations as well as user configs would improve
workflow.


D. Some other global rearrangement to make related things visible and
controlable at the same time, and that does not impose extra steps
every change you want to do. AKA, "other ideas welcome".


I would go for C, it is like B without the orphan case, but means more
code than the others. Case A would be simplest to code (just plug key
events to correct activate code). B would be simple too (same code
than A, but plug to all panels) except the damn orphan case that can
happen in some button windows. D, I do not know, you have to write it
first. :]



5. Handle area (new)

Panels can only be moved by a tiny handle at the top, while they have
lots of space that do nothing, which could work as handle (transparent
or not).




GSR