[Bf-funboard] Full RVK proposal plus more UI proposals

[Thorsten Wilms]

On Mon, Nov 24, 2003 at 11:36:19PM +0100, William Reynish wrote:

> LMB click: select
> LMB drag: border select
> Ctrl+LMB click: set 3d cursor
> Ctrl+LMB drag: gestures
> 
> MMB: view manipulation
> 
> RMB: toolbox
> 
> 
> I think this would work very well, adding consistancy
> (RMB used globally for extra options) as well as speed
> (no need for pressing B to border select) as well as
> consistancy with other software (LMB selects -
> LMB+drag borderselects).

I guess with using a modifuer key to access gestures, you 
can as well remove them entirely. That's ok with me, 
since they don't fit well into the proposed scheme. 
But other people are used to gestures and we should think 
about how this affects tablet users.

 
> > Radio buttons:
> > --------------
> > Grouping radio buttons without space between them is
> > a nice and 
> > simple solution to their main problem. But a
> > selected radio button 
> > still looks like a depressed (option) button, and
> > therefor implies 
> > that it should go up if you click on it again. That
> > lead to the 
> > (horizontal) listbox solution in my latest mockup.
> 
> I think grouping them together would be sufficient
> enough if followed, although making a bigger
> distinction might be a good idea too. Other programs
> don't make other distinctions than putting them close
> to each other and I think that works just fine. Maybe
> it will seem a little cluttered with loads of
> different drawstyles.. Don't know.

What other programms make use of just buttons for 
options?

Different functionality/behaviour -> different look.
Of course it has to be conistent as a whole.

> > 
> > Input buttons:
> > --------------
> > The didvison in 3 sections is a good idea, I think,
> > because you can't 
> > be sure what happens when clicking near middle
> > anyway. It also makes 
> > keyboard entry easier. However, it has to be clearly
> > communicated. 
> > I think the sections must not be visualized in
> > advance. Only on 
> > mouse-over there should be an indication of what
> > will happen on 
> > clicking. I might look into this later.
> 
> Why? I really like the current arrows! Or did you not
> mean removing them? The idea was that we should use
> the arrows on the input buttons to show that this area
> is different. 

Current arrows are much smaller than the target areas should
be. And I was already thinking about my widget design. It 
removes the readability problem we currently have if the text 
takes up too much space, so that text and arrowheads colide.

 
> > Toolbox mesh editing:
> > ---------------------
> ...
> > I think buttonswindow is the place for parameters,
> > options and 
> > commands closely tied to either of them.
> 
> But take the Merge function in the toolbox. This has a
> popup too - Why must the settings for Remove doubles
> only appear in the Edit buttons window and not in a
> popup? This is highy inconsistant.

I'm not saying things from edit buttons shouldn't show 
up anywhere else. I'm not against more popups, since 
a part of my toolbox commandline idea needs them.
But I think the contents of buttonswindow should be 
limited in a logical way.


> Good idea! I have just organised things into seperate
> sections like you suggest!

Cool, thanks!


---
Thorsten