[Bf-committers] Re: UI refactoring (was "IRC meeting minutes sunday 28th nov")

[Jason Saunders]

On Tue, 30 Nov 2004, Michael Reimpell wrote:

>> I don't think this was discussed in the meeting, but there is also a
>> UI refactoring being done for (now) 2.37.
>
> A compliment to the developers of the UI refactoring! You managed to get a
> tidy interace without hindering the workflow or loosing the blender interface
> philosophy. Very good work!

I don't entirely agree, there are lots of things that now need more clicks
and more complex mouse movement to achieve the same - plus in some places,
much less information is displayed at once than before. But there are some
positive aspects of the UI makeover too, I agree.
----------------------
Errm... I'm glad to hear all of your enthusiasm, but the 2.37 ui
refactoring (reorganizing the buttons window) has NOT entered bf-cvs
or tuhopuu AT ALL. I think you guys are talking about the 2.3(0) UI
makeover, which has been in place for about... a year! :P

> A compliment to the developers of the UI refactoring! You managed to get a
> tidy interace without hindering the workflow or loosing the blender interface
> philosophy. Very good work!

I don't agree , the buttons window needs a lot of work ;) and that is
what we're doing for 2.37. Check out
http://wiki.blender.org/bin/view.pl/Blenderdev/ButtonsInformationArchitecture
for more info, and stay tuned for updates ;) (Just make all those
2.35's into 2.37's :P)

Hope everyone's clear on this!


On Wed, 01 Dec 2004 00:31:58 +1100, Jonathan Merritt
<j.merritt at pgrad.unimelb.edu.au> wrote:
> Alexander Ewering wrote:
> 
> > 2) You would be unable to have different direction mappings for, say,
> > Alpha
> >    and Spec, unless you make seperate sliders for EVERY mapping
> > function. And
> >    I'm sure you don't want that :)
> 
> 
> Just out of interest; why wouldn't I want my specular coefficient to be
> different from my alpha coefficient (without having to apply a texture
> twice to achieve that effect)?  :-)
> 
> Personally, I'm in favour of representing the texture application
> process in a more obvious way.  I think the current system is a little
> confusing because textures are presented very much as an
> "after-the-fact" modification to a material.  We also have three
> different zones where coloring / texturing information might arise:
>    1. The original material parameters in the material buttons.
>    2. The texture mapping area of the material buttons (with its
> arbitrary combinations of effects).
>    3. The texture buttons, where the actual parameters to generate a
> given texture can be changed.
> I don't think this system is straightforward.  You may find it
> straightforward because you have become accustomed to it, but if
> somebody sends you a .blend file with a complicated shader (as happened
> to me several times when I was working on RenderMan export), you find
> you have to check loads of different areas to find out what's actually
> going on...  How is a texture generated?  How is it mapped?  What
> parameters is it affecting?
> 
> I think we could do with a system in which it is more directly obvious
> how a particular texture will affect a material.  So, for example,
> instead of having the material color in one place and a texture that can
> affect that color in a different place, we would have some kind of link
> that is placed right next to the material color.  For those parameters
> that don't involve "set point" values (eg: surface normal vectors),
> there would need to be a separate area, but there are relatively few
> non-set-point modulators.
> 
> Anyway, I guess this will all be a moot point if ever the proposed
> node-based shader construction is implemented. :-)
> 
> Jonathan Merritt.
> 
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>