[Bf-interface] Top-bar - Target for 2.8 or not?

Julian Eisel eiseljulian at gmail.com
Tue Nov 21 00:42:41 CET 2017


Let me get into some concerns that were pointed out regarding operator
redo settings in the top-bar:

* Space issues with too many settings in the top-bar. --
We wanted to only show basic operator properties in the top-bar
directly, rest only in a "More..." popup. Support for this is about to
be committed (see [1]).
With this, there shouldn't be any real space issues.

* Operator redo settings may appear and disappear a lot. --
That was a concern of mine too. But users who have tested the branch,
said they don't find this being an issue. Pawel explains it nicely
here [2].
Also note, that with split basic & advanced operator settings, the
appearing/disappearing is minimized.

* Operators depend on context. Tweaking their settings in the top-bar
breaks this. --
I solved this by storing and temporarily resetting the UI context in
which the operator was executed in. This works pretty well. In fact we
already did a similar trick prior to 2.8 (when redoing region
dependent operators from the tool-shelf).

* Lower sub-bar is empty by default, could be confusing. --
Jonathan and Pawel agreed this isn't an issue at all. In fact, we even
agreed it's a nice way to declutter the UI and move focus to the 3D
View. I think Pablo agreed with that too, but don't remember for sure.
I'd love to hear them speak up for themselves though.

* Global tool-settings (for sculpting, painting, grease pencil,
snapping etc.) need more space. --
During the 2.8 workshop we agreed on not having paint settings
(brushes and such) in the top-bar. However, I'd like to recheck on
that since big parts of the top-bar would be empty in paint modes
then. Most basic paint settings (brush, strength, radius, etc) can be
moved to the top-bar. Other apps do this too (i.e. Krita). I think
I'll implement this for testing.
Some other tool-settings should be made local or at least local per
editor type (e.g. snapping). They shouldn't use the top-bar at least.

-----

These are all the concerns people raised IIRC. Let me know if you have
more, I'm happy to handle this openly.

[1] https://developer.blender.org/D2883
[2] https://developer.blender.org/T50845#471020

On 20 November 2017 at 23:57, Julian Eisel <eiseljulian at gmail.com> wrote:
> Hi again ;)
>
> After having cleared up some misunderstanding in regards to the
> top-bar [2], I wanted to get agreement on if the top-bar or parts of
> it should be postponed for after 2.80 or not.
>
> There are still good reasons for the top-bar in general: it matters a
> lot for the usability of workspaces, it communicates hierarchy of
> options better, it resembles what users know from other apps some
> more, etc.
> Pawel's feedback mentions quite some benefits:
> https://developer.blender.org/T50845#471020.
>
> Ton suggested to postpone the part with the operator redo settings
> because there are too many open issues ([2]). I don't think that's the
> case though, which I wanted to discuss here too :)
> In short, I'm not aware of any bigger issues that I didn't address
> yet. Will write a followup mail on some details.
> Also, would we squeeze remaining settings from the lower sub-bar into
> the upper one? That would pretty much remove most benefits of the new
> top-bar.
>
> The part with exposing settings of running modal operators can be
> postponed IMHO. It's probably not a simple change to implement and not
> that important.
> And again, there are no concrete plans of having settings for the
> tool-system in the top-bar. We might work on that in the future, but
> not now.
>
> Also related: https://developer.blender.org/T53139
>
> [1] https://lists.blender.org/pipermail/bf-interface/2017-November/000271.html
> [2] https://lists.blender.org/pipermail/bf-committers/2017-November/048917.html
>
> Cheers,
> - Julian -


More information about the Bf-interface mailing list