[Bf-committers] Weight Modifiers - Issues

Thomas Dinges blender at dingto.org
Thu Sep 8 12:55:27 CEST 2011

Hey Campbell and Bastien,
thanks for the info and the fixes from you Bastien.

I won't argue about my first point, although I still don't like it very 
much. :)

But the third point is an issue.
If I remember correct there is no similar button in the whole UI where 
you can select multiple options *and* has the same look/shading.
Compare to the Vert/Edge/Face Select Buttons in the 3D View Header. They 
look completely different.

My main concern is, that people don't expect your 3 buttons to be 
"Selected all at once". I will have to think about how we can address 
that, but it should be done before 2.60 release imho.

Best regards,

Am 08.09.2011 10:06, schrieb Bastien Montagne:
> Hi Thomas,
> On Thu Sep 8 01:18:22 CEST 2011, Campbell Barton<ideasman42 at gmail.com>
> wrote:
>> On Thu, Sep 8, 2011 at 8:49 AM, Thomas Dinges<blender at dingto.org>  wrote:
>>> Hello,
>>> who "reviewed" the Vertex Weight modifer(s)?
>> me :)
>>> IMHO this is totally rushed in and this is not what should happen. We
>>> agreed only on merge projects which are reviewed well, but on a first
>>> glance I see some problems with this.
>>> 1) Why 3 Modifiers?
>>> I'd rather see 1 with different modes, imo.
>>> This clutters the Modifier menu and really could be avoided. 1 modifier
>>> with different modes are much better (design wise).
>> Originally they were one modifier and I requested they be moved into
>> 3, this was because the interface had a lot of buttons and it was hard
>> to which button effected which functionality - applying a curve on
>> existing weights is very different to weighting based on the vertex
>> distance to another object for example, again mixing weights with
>> another group is different.
>>> 2) The User Interface Code is not good, lots of columns instead of rows
>>> in the code. Why don't you look at the other Modifers in the python file
>>> and take them as an example. And we don't use assignment names such as
>>> col1 or col2. Maybe in the User Preferences (but this is a special case
>>> there).
>>> A column is used for elements underneath each other, not next to each
>>> other in a row. So don't use split.column if label or prop are in 1 row
>>> and belonging to each other. :) (weight_vg_mask function)
>> Not defending bad interfaces but the interface is really easy code to
>> refactor/rewrite compared to the rest of the patch, for example - if
>> you were to make a mockup of an improved interface I'm sure it could
>> be done by Bastian or myself before release.
> Sure! I already made some edits to what you pointed out, let me know if
> there are others problems in the UI code! :)
>>> 3) UI Design misuse:
>>> What is that? Boolean check boxes concealed as Radio Buttons?
>>> <http://www.dict.cc/englisch-deutsch/concealed.html>http://www.pasteall.org/pic/17617
>>> This is wrapped as an enum, but I can select multiple ones, so either
>>> this is wrong or they should be wrapped as booleans.
>>> Anyway this does not fit in the UI design.
>> No: in fact it is the UI which is at fault (if you consider this wrong
>> in the first place) - blender supports enums where multiple options
>> can be selected, this is correct use of the RNA data type - so if we
>> are to fix anything its the drawing/UI.
>> IMHO there are bigger UI issues which this is apart where its hard to
>> tell if buttons are pressed, data vs operator buttons too.
> I’ll just add that I highly prefer current UI, compared to the one we had
> when only using checkboxes…
>>> I am sorry, this may sound a bit harsh and I don't want to offend
>>> anyone, but this is exactly what some people feared talking about the
>>> new release cycle, that not well tested/reviewed code gets into trunk .
>> When reviewing I was mostly checking for bugs, consistency with other
>> modifiers and usability - (testing the modifiers worked as I expected
>> &  in a useful way).
>> IMHO it fine to do some UI cleanup once in trunk.
>>> Please fix the issues.
>> Some of these issues a are not just things we can `fix` - UI buttons
>> need some thought if they are to be changed.
> > From the 3 points you make, only #2 is a straightforward fix, Bastien
>> are you able to look into this?
> Done (I hope :P ).
>>> Best regards,
>>> Thomas
>>> --
>>> Thomas Dinges
>>> Blender Developer, Artist and Musician
>>> www.dingto.org
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> --
>> - Campbell
> Regards,
> Bastien.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

Thomas Dinges
Blender Developer, Artist and Musician


More information about the Bf-committers mailing list