[Bf-funboard] Space saving UI proposal

Paulius Mscichauskas pauliusmscichauskas at gmail.com
Wed Apr 9 13:37:03 CEST 2014


The paper was updated since that post. Download the latest version from the
link I provided. Or maybe I should upload it somewhere else, in case
someone here doesn't have a blenderartists account.
Here, uploaded it here:
https://mega.co.nz/#!hEsjWKyT!qZupv6GDtesYOyft1QSmQg3jZMe-FiisL5tKUOIm0ys


In the update, I've edited some sentences to be more clear.  Also added a
section "Some misconceptions and questions". These were gathered from the
blender artists forum.

"The paper suggests "It's impossible to create any floating panels that are
unrelated to the current mode". Well, one often goes in and out of modes
such as sculpting.. I wonder what would the "sculpting brush floating
panel" do in such a case.."

As the paper describes, The floating panel layouts are separate entities in
different modes. Created floating panels only remain in the mode they are
created in.
So, for example: You create two floating panels in object mode: "Transform"
and "Last operator",
When you change the mode to "Sculpt", the "Transform" and "last operator"
panels disappear. Now you create two floating panels "Brush" and
"multiresolution". Now, if you toogle between "Object" or "Sculpt" modes,
you either get "Transform" and "last operator" OR "Brush" and
"Multiresolution".



On 9 April 2014 14:08, Prashant Sohani <prashant.sohani at gmail.com> wrote:

> I found a copy of the paper over here:
> https://developer.blender.org/T39527
>
> On initial (and very rough) scanning of the ideas; I think there are
> several worth considering for sure. Needless to say, the floating panels
> are not consistent with Blender's "no overlap" principle (which I am a big
> fan of :D); yet the Figure 4 screenshot would convince anybody regarding
> the merits of this tradeoff.
> Apart from which; the better look of individual section headings etc, make
> a lot of sense to me as well.
>
> On the coding side though; there are some concerns regarding context
> sensitivity.
> The paper suggests "It's impossible to create any floating panels that are
> unrelated to the current mode". Well, one often goes in and out of modes
> such as sculpting.. I wonder what would the "sculpting brush floating
> panel" do in such a case.. keep auto-showing and hiding when relevant?
> Which would need one to remember the "floating panel layout" specific to
> every "major and minor" mode. (Here major = Sculpt, Edit mode etc; minor =
> more specific; such as the MultiRes panel in Fig 4 ; which is relevant only
> when the object is selected )
>
> Need to read more in detail though.
>
> Regards,
> Prashant
>
> Regards,
> Prashant Sohani <psohani at nvidia.com <psohani at email.com>>
> *Systems Software Engineer*, *NVIDIA*
>
>
> On 9 April 2014 16:33, Paulius Mscichauskas
> <pauliusmscichauskas at gmail.com>wrote:
>
> > Hello.
> > I have written a paper that proposes some changes to the blender GUI that
> > tackles
> > these issues:
> >   1) Inconsistency in the N shelf. Object/scene specific panels are in
> >   one menu with 3D view setting panels.
> >   2) The position of the "Last operator" panel.
> >   3) Claustrophobic 3D view. The view is shorter horizontally, than
> > vertically at some occasions.
> >   4) The user is forced to see to much info at once. The paper explains
> How
> > to give the
> >   user a possibility to clean up his view to the level of sculptris,
> where
> > if the user is just sculpting, only relevant sculpting tools for his
> > specific sculpting workflow are seen on a full screen 3D view. Much more
> > customizavbility.
> >   5) Ability to reach the multires modifier without leaving the 3D
> view....
> >
> > Link to PDF:
> >
> >
> http://blenderartists.org/forum/attachment.php?attachmentid=301256&d=1396947175
> >
> > The proposal has a lot of text, and might not be clear at parts, so feel
> > free to ask if something is unclear.
> > English is not my native language. Be patient and give it a chance.
> >
> > Feel free to discuss.
> > Maybe the proposal has at least a few ideas that might benefit blender.
> >
> > Sincerely,
> > Paulius Mscichauskas
> >
> > P.S. If someone could place this in the blender wiki, that would be
> great.
> > I couldn't figure out how to do that.
> > _______________________________________________
> > 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