[Bf-funboard] Space saving UI proposal

joe joeedh at gmail.com
Sun Apr 20 19:38:10 CEST 2014


Isn't this sort of situation what RNA is for?  IIRC, sharing panels across
editors should be as simple as storing the context for the editor the panel
came from in the panel.  I could be remembering wrong, though, and I
imagine there would still be problems and conflicts (e.g. you wouldn't want
the user to drag panels that reference a specific editor instance outside
of that editor).


On Sun, Apr 20, 2014 at 9:31 AM, Paweł Łyczkowski <pawellyczkowski at gmail.com
> wrote:

> Hi
>
> >
> > I'd love if some developers in the UI team to read this and give their
> > thoughts.
>
>
> Dragging panels into the 3d View seems like a good idea from the design
> standpoint (I'm not sure if it's feasible code-wise atm). I would
> consider it when the 3d view layout/organization will be on the table,
> but in my opinion panel migration form the n-sidebar and the following
> n-sidebar removal (the "one sidebar per window policy"), combined with
> the ability to hide unused panels would be a better solution for 3d
> Viewport cleaning-up (yes, there would be some unused space when there
> will be less panels than the height of the sidebar - not that big of a
> deal IMO with one sidebar).
>
> But if I were to comment on your proposal - it adds quite complicated
> functionality (like the floating panel layout presets). I would go for
> UI simplicity first.
>
> That's how I would envision it:
>
> - drag a panel from the toolshelf or properties panel only (I think
> adding them from other windows would be a coding nightmare, and probably
> has scenarios when it fails)
> - place the panels on the edge of the 3d view only (allowing them to be
> placed anywhere would cause problems with collapsing sidebars), in a
> spot that is the percentage of the window width or height (so no panel
> will go out of view - they will be able to overlap though)
> - a button to enable/disable floating panels (automatically turned off
> in 3d Views, turns on in a current window when you drag a panel out), no
> floating panel presets (for simplicity's sake)
>
> Cheers
>
>
> Paulius Mscichauskas wrote:
> >
> > Any one else have thoughts?
> > I'd love if some developers in the UI team to read this and give their
> > thoughts.
> >
> >
> > On 10 April 2014 02:26, Paulius Mscichauskas
> > <pauliusmscichauskas at gmail.com>wrote:
> >
> >>
> >> "What I don't like in this proposal is changing the headers while the
> >> panels
> >> are docked. This creates too much visual clutter. The alignment issue
> >> with
> >> check boxes is easily solved by offsetting text in panels that don't
> have
> >> check boxes by one space."
> >>
> >> I agree with check boxes.
> >> My speculated changes do not strike me as visual clutter. They were
> >> inspired by the Zbrush menu on the right and the old panel appearance in
> >> 2,49. For me, it looks more pleasing. My goal was to tackle these two
> >> points:
> >> The GUI should communicate that floating panels and docked panels are
> the
> >> same thing.
> >> Each panel is a different entity with boundaries.
> >> However, these changes are not essential for the main point of the
> >> proposal - floating panels.
> >>
> >> "Another thing that is a no go is having per 3D view settings for each
> >> modifier."
> >> Could you elaborate on that?
> >>
> >> "Tabs design is slightly weird here and lacks any kind of information.
> >>
> >> Remembering "feature X is in n tab" is harder and more abstract than
> >> remembering "feature X is in the Tools tab".
> >>
> >> The mockups lack icons. There would be icons. I just didn't want to
> >> bother
> >> to draw them.
> >> So it would be more like "feature x is in tat marked as *icon*"
> >> Just like it is in the properties editor.
> >> Icons are easy to recognise and read.
> >>
> >> "* Cursor settings *is* (potentially) specific the the 3D view; aside
> >>
> >> from the scene global setting, each view can have it's own cursor. This
> >> might complicate the proposal a bit."
> >> Can you actually use a different position of the 3D cursor on
> >> different 3D
> >> views?
> >> If you could, I would surely agree with you.
> >> I don't think you can. The location of the 3D cursor right now is a
> >> global
> >> setting, not 3D view editor specific.
> >>
> >> "* Mirroring transformation in the 3D view and Properties by default is
> >> not 'consistent' or 'compact' but it is very pragmatic, as it is very
> >> handy there, less so in properties. So moving it to properties by
> >> default and not in 3D view has the practical effect of taking something
> >> commonly needed and putting it somewhere more hidden.. (the rest of the
> >> proposal helps you get it back, but not by default - new users will
> >> struggle to find it, experienced ones will be forced to tweak their uis
> >> every time)"
> >>
> >> Of course it's consistent and compact.
> >> Consistent, because the panel would not be in the same menu as 3D view
> >> settings, compact because there is no duplicate, less panels in the
> >> 3D view
> >> settings.
> >>
> >> Is the "transform" panel very handy in the N shelf? Of course!
> >> But the same goes for plenty of other panels in the properties editor.
> >> Why should transform have a bigger priority? Priority depends on what
> you
> >> are doing.
> >> If you are modelling, it's handy to have the transform panel in the "N"
> >> shelf, but if you are setting up materials, it's handier to have the
> >> materials panel there instead.
> >> There is no objective priority for one over the other.
> >> And that is why, in my proposal, the user is given a free choice on what
> >> to prioritize himself. He can have the materials panel or the tranform
> >> panel in the "N" shelf or as a floating panel, or both, or neither.
> >>
> >> Btw, as it is written in the proposal - The "N" shelf would have a
> >> "Custom" tab. All panels that were removed from the 3D view settings
> >> because of the changes, could be placed there by default, just so it
> >> would
> >> be easier for users to adapt to the rearrangement.
> >>
> >> Also, there are other defaults to be still thought through... For
> >> example,
> >> the default blender file could have the transform as a floating panel
> >> right
> >> there, on the top right.
> >>
> >> Btw, experienced ones will not be forced to tweak their UIs every time.
> >> That's what floating panel layout presets are for. Also, they are not
> >> forced to use floating panels at all, they can reach the same
> >> controls when
> >> they are in menus too.
> >>
> >>
> >> "* I think needs more design and thought, for instance: can you drag/pin
> >> a panel from the UV image editor or node editor into the 3D view? what
> >> happens when node selection/material/image in the original editor
> >> changes? why floating panels in the 3d view only?"
> >>
> >> As it is described in the proposal, all editors that have the "N" shelf
> >> would have floating panels in them. Not just the 3D view.
> >> Any panel from the "N" shelf would be able to become a floating panel
> >> within that editor. The 3D view was just used in the mockups as the best
> >> representation of the advantages.
> >>
> >> Also, as it is described, the user is not allowed to bring a panel from
> >> one editor to the other. So panels that belong to the UV editor can
> >> not be
> >> dragged to the 3D view or any other editor, but itself.
> >> The only exception is, that the user is allowed to bring floating panels
> >> from the "properties editor" to any "3D view". That's because, these two
> >> editors are exceptionally related.
> >>
> >> These limitations would make context sensitivity identical to what it is
> >> now.
> >> There should be no context sensitivity problems. Not any more than there
> >> are currently.
> >>
> >> "* More design and thought: I see blender in this proposal as a
> sculpting
> >>
> >> application, with no consideration for animation, rigging, compositing,
> >> or any other workflow."
> >>
> >> The proposal describes on how things could work. What can be achieved
> >> with
> >> floating panels is kind of a matter of the users imagination. The user
> is
> >> free to use these possibilities any way he wishes, for anything he does,
> >> for any workflow he has.
> >> Sculpting was just a single example. I could've drawn another kind of
> >> example, but I just happened to draw sculpting. One example, i believed,
> >> was enough to convey the possibilities. Mocking out all possibilities is
> >> simply unnecessary.
> >>
> >> If it's hard to imagine how floating panels could used for, let's say,
> >> rigging, here's an example:
> >> If you are setting up bones, you could drag out the "constraints list"
> >> panel and "transform" and perhaps "Shape keys" panels out of the
> >> properties
> >> editor onto the 3D view for pose mode; "Brush" and maybe "Vertex groups"
> >> for weight paint mode.... You are free to drag out whatever you
> want/need
> >> after all....
> >>
> >>
> >> I did post this proposal on developer.blender.org
> >> Brecht closed it and said that i should upload the proposal to the Wiki
> >> (Which I didn't figure out how to do, so if anyone could do it, that
> >> would
> >> be great) and then post it to bf-funboard to invoke discussion. He said
> >> that developer.blender.org is for things that developers are actually
> >> working on or plan to work on, not proposals.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 10 April 2014 00:09, Antony Riakiotakis<kalast at gmail.com> wrote:
> >>
> >>>
> >>> That is a very valid concern that I see often the paint/sculpt
> >>> community.
> >>> Some people see the software as an exclusive paint/sculpt
> >>> application and
> >>> prioritize presentation of information relevant to that workflow
> >>> only, and
> >>> usually similarly to other software.
> >>>
> >>> I will repeat this here, blender is not Bbrush. For instance I often
> see
> >>> requests about scultping features that can easily be done in edit
> >>> mode. Of
> >>> course solution there is not to replicate the functionality in
> >>> sculpting,
> >>> but make edit mode itself faster.
> >>>
> >>> As Bassam said blender has to cater for all different kinds of
> >>> workflows,
> >>> and while presenting information in a compact way is desirable, doing
> so
> >>> in
> >>> a non specialized software is much more challenging.
> >>>
> >>> I have some opinions on the matter but better separate the proposal
> >>> to sub
> >>> tasks and continue on developer.blender.org,
> >>> _______________________________________________
> >>> Bf-funboard mailing list
> >>> Bf-funboard at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-funboard
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-funboard
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard
>


More information about the Bf-funboard mailing list