Hide Command on View Menu

 From:  Michael Gibson
988.3 In reply to 988.1 
Hi Jon, I'm glad that you like MoI and thank you for the feedback!

> I am impressed that you have incorporated shelling into the program.

I should mention that MoI's shelling is not really as robust as programs like SolidWorks, etc... It will tend to get confused on more complex models, particularly where stuff would start running into each other during the shelling. But nevertheless it is still very useful for quite a lot of simple models though.


> I think it would be more intuitive to place the Hide Command on the "Views"
> pallete versus the Edit Pallette.

Hmmm, that is a good point. I originally put it on the Edit palette because strictly speaking the "hidden" state is a property of an individual object. "View" is kind of intended to be short for "Viewport", I want to put stuff that are properties of the viewports over there. But I can see this one is kind of a toss-up. I think for practical use purposes, it is handy to keep it under Edit, since there is a tendency to keep edit open quite a bit of the time while modeling. Sometimes I end up taking some liberties with strict categorization in order to improve workflow.

One side effect of MoI's tabbed palette approach is that it is nice if things that are used frequently together are all clustered in the same tab so you don't have to switch quite as often.


> Just clicking in a particular window to expand that window seems more efficient.

You mean click anywhere inside the window? Right now that type of click is used for deselecting objects, so that makes it difficult to use it for a different purpose.

One nice efficiency that is gained with the Split / 3D / Top / Front / Right tabs is that it is possible to switch to any particular view with just one click. Like for instance you can go from the maximized Front view to the Maximized Top view in one click. If you clicked inside of a window to switch, in that situation you would have to go from Front to Split then to Top view, causing an extra step in between.


> Another point is having construction palletes float so I can change their
> ordering to suit might be nice for some people.

I would like to try this eventually, but it takes quite a large amount of work to make a floating / docking type system that functions well. I decided early on to pour my energy into making a default UI that worked as well as I could make it, rather than working on drag/drop type customizations at least for a while.

Actually, the current UI is very customizable, just through a more manual method of editing the text files that hold the UI definitions - these files are accessible under the \ui sub-folder under MoI's main folder in \Program Files. If you really really want to change the order of things, let me know and I can walk you through how to edit the UI to change it.


> Keep the number of ways to access the interface simple. We don't need
> multiple ways to access a command.

One thing that is interesting is the old "multiple ways" method of having stuff duplicated between a menu system and toolbar system was pioneered by Microsoft Office. But eventually they found it untenable and switched to a more unified model with their latest version, kind of similar in a lot of ways to MoI's approach.

- Michael