Not "Using the keyboard" was not a start intention of Moi ? :)

> Not "Using the keyboard" was not a start intention of Moi ? :)

Certainly! :) But it is not a guarantee that every single minor feature will never use it!

I think that having some lesser-used or very expert-oriented features only on the keyboard is not so bad. I'll certainly try not to do even that, but one big benefit of having a keyboard feature is that it prevents clutter in the interface, which can also be a big problem.

But it will always be the case that the functionality required for just basic operation will not require the keyboard.

- Michael

Jonah wrote:
> But then i've accidentally deselected everything because i've clicked on a face

The other thing that will help with this is making undo work to recover a selection change. I mean if you make a selection mistake and everything gets deselected, just hit undo right then to restore the previous selection.

I've been meaning to do this for a while, maybe I will see if I can crank that out right now!

- Michael

sounds like a perfect solution on one hand, if only to revert one step backwards in the selection set. But it might create the need for extra undo steps for many other situations. and since Moi has no feedback for what action is being undone, it may create a problem for someone who intends to undo the last action, but not realize they've only undone the last selection. Maybe they realize 50 steps later that something was not undone properly... So i think this "revert selection" would best be handled in one of two ways:

1) have a seperate undo stack (and seperate command) for selection states. Maybe not the best idea though.

OR

2) limit the undo function to act only on selection states within a running command. Selection state is cleared when the command is cancelled or completed.

jonah

There is somewhere a little script for That : "hide the invert selection" :)
Very useful, you have not it?

I haven't made any attempts to use scripts. How does the script "hide the invert selection" apply in this case? We are discussing a way to go back one step in the selection history stack. I don't see the connection of the 2 purposes... ?

> and since Moi has no feedback for what action is being undone,

Well, there is graphical feedback - really the vast majority of the time there are pretty obvious changes when you do an undo, and you are usually watching for some specific result.

But yes, this is possibly a problem.

Re: #1 Separate undo stack

This solution I don't think is so good since it involves duplicated UI. And a lot of people just wouldn't find the alternative "undo", it is a lot easier to use when there is just one undo.


Re: #2 - only allow selection undo within commands.

Well, I was definitely planning that it would be cleared when you exited a command - the selection undo action will be a pretty transient thing, it will just store one entry for the last selection and any type of change should clear it away. It is really for use only immediately after you have done a selection.

But I don't think it would be good not to offer it at all if you are not in a command - there are certainly a lot of things where it is natural to build up the selection set before you go into the command, and it is easily possible to get a selection error there as well.


I think I'll just give it a try and see how it works. If it becomes a problem with undoing geometry changes then it can be fine-tuned a bit, perhaps only "large" selection actions such as deselection of many objects could be recorded...

- Michael

Right no "connection", just complementarity :)

Hi Michael,

>After all you don't frequently need Deselect all neither,
>just really for this one situation again....
>But I worry a lot about adding buttons... ;)

I start thinking about removing SelectAll, DeselectAll buttons completely! hmmm.... These are very special-purpose buttons and none of other functions can be linked to them. Maybe they should be attached to the "click and pause menu" or to mouse gestures once mentioned.
....perhaps, it's time, time to call an election and users should vote on "how frequently do you use the SelectAll, DeselectAll buttons"? hehe...

The ResetAll button in the View tab is quite funny as well. It could be shifted to the middle of the screen where the viewport boundaries are crossed - in the shape of a small ball.


>In addition you could select all of those types of
>objects by just doing a "Select all" with the
>appropriate filter active. This way it would serve 2
>purposes - for clicking and for selecting
>all of a certain type.

....for clicking, for selecting all of a certain type and for area (window) selecting as well, I guess. Perfect!


I have noticed that the buttons in the middle section of a command palette (Edit, View, Select) are quite colourful while the others aren't. Is there any reason for this?


Petr

p.s. I'm in a good mood so I hope you excuse me that I "kick against the pricks"..... hehe..

> I start thinking about removing SelectAll, DeselectAll buttons completely! hmmm....
> These are very special-purpose buttons and none of other functions can be linked
> to them. Maybe they should be attached to the "click and pause menu" or to mouse
> gestures once mentioned.

Well, the select all can be pretty useful. The problem with the click+pause or mouse gesture is that is very hard for someone to discover it just by messing around with the software. So I would worry about hiding that one away.

I don't think I mentioned it before, but select all also currently pays attention to the implicit drill-in filter.

I mean if you have an object and you select an edge of it, then select all will select all edges of that object.


> The ResetAll button in the View tab is quite funny as well. It could be shifted to
> the middle of the screen where the viewport boundaries are crossed - in the
> shape of a small ball.

Hmmm.... Kind of a lump in the middle of the screen? I think I'd have a hard time making that look very nice. I had been thinking about making right-click on any viewport's reset button doing a reset all - I've got that set up now for the next beta.


> I have noticed that the buttons in the middle section of a command palette
> (Edit, View, Select) are quite colourful while the others aren't. Is there any
> reason for this?

Just a coincidence. The commands in the top and bottom sections happened to tend to be easier to represent with more geometric shapes and actual shaded 3d object examples. Those tend to be less colorful. Icons that have a more interpretive graphic stylized symbol are more colorful.


> p.s. I'm in a good mood so I hope you excuse me that I "kick against the pricks"..... hehe..

Certainly! Kick away! :)

- Michael

>I don't think I mentioned it before, but select all also currently
>pays attention to the implicit drill-in filter.
>I mean if you have an object and you select an edge of it,
>then select all will select all edges of that object.

Not only all edges of that object, but also all other objects in the scene (ok?)


>I had been thinking about making right-click on any viewport's reset
>button doing a reset all - I've got that set up now for the next beta.

I will like it. (Although, this spot might be "abused" by you sometime.)


Petr


p.s.: I've inflicted a punishment on myself because of my impudence. I just have to translate the MoI's introductory documentation into my native language. So I say goodbye......

> Not only all edges of that object, but also all other objects in the scene (ok?)

Yes - this is also consistent with window selection. If you have edges turned on for one object, and you window select it but also include other objects in the window selection, those other objects will also get selected.


> (Although, this spot might be "abused" by you sometime.)

I was thinking that clicking and dragging there would eventually allow you to resize the proportions of the split views...

It's a little hard to think about putting something useful at that spot, since it will be gone when you switch from the split view into a single view...


> I just have to translate the MoI's introductory documentation into my native language.

Cool! It's always good when others benefit from your self-imposed punishment!! :) :)

- Michael