Hi Danny, thanks for the feedback - yes it's fine to just brainstorm and throw out some ideas!

> I like the logic so far, styles and groups. I know you don't like
> the word 'Layers' but does 'Styles' equate to layers in the
> simplest form ?

Yeah, I think it has pretty much turned out that way, which I think will be good because then styles can be used to transfer into "Layers" when doing import/export to some different formats.

You'll be able to use Styles if you want to organize your object primarily based on visual appearance, like Red objects = one category, Blue objects = a different category, etc...


If you want to organize your objects in a separate way than its visual appearance, like make hierarchies and things like that, then you can use Groups to do that. That will then get into some kinds of arrangements that are not possible to do with regular traditional layers. (and will also therefore not map so easily to them during import/export though).


I'm trying to avoid using that term "Layers" because if I name something Layers it will make it look like that is the main thing that you should use for organizing objects.


> With groups, have you thought how you are going to
> define them, titles,numbers......?

Currently the idea is that groups will have a name assigned to them, like when you do a "New group" probably a dialog will pop up at that time to let you enter a name for it.


> Maybe a third option "Side" which would throw it to the
> opposite side of the the screen to the command palettes, I
> feel organisational work flow should be separate from the
> modelling work flow, my feeling anyway

I've generally tried pretty hard to keep the top and left sides clear of UI, it kind of helps to make for a kind of "open" feeling to the viewport with the spotlight kind of put more on your objects rather than on the program UI.

UI that surrounds your objects on all sides gives me a kind of "boxed in" feel that I'd like to avoid.

Anyway, that's kind of the philosophy for not doing that...

If it seems to come up a bunch more then I could certainly add in an option for it! It will be pretty easy to actually make your local copy behave like that by editing a UI file though (I'll give instructions after it is out there) so you'll be able to try it out like that.


> Here's one idea, maybe start using the second click option to
> open another palette, same action as you have for the Viewport
> configuration tabs.

This kind of works best when that second click would otherwise do nothing.

Like for example with the viewport tabs, once you have clicked on "Top" and made it active, it's not like you would expect for a second click there to do the opposite (since that one is a button that is part of a set). So for a while there that second click was not doing anything until I made it do the reversing function instead.

But with the Tree buttons that have a + / - on them, if one click opens that tree item, then a second click would be normally expected to already do the opposite, so it doesn't quite have a "do nothing" state that I can leverage for that case...

- Michael