Hi Michael,

OK, I now follow your path on this.

>Yeah, that is one of the reasons that I posted it. If it seems like it is not going to do the job properly, or if someone has a >better idea of a completely different direction, now is the time to present that.

For a single selected object, I cannot see a simpler way to present that than you have done. My first thoughts/questions would be more about the handling of groups and the possible assignment of an object to an already created group.

I do have a number of questions/thoughts on this, but will try and get some order in my head before posting more and taking your time.


Regards,

- Steve

Hi Steve,

> My first thoughts/questions would be more about the handling
> of groups and the possible assignment of an object to an already
> created group.

I think that probably there will be a separate thing for managing grouping, something along the lines of the panel discussed in this other thread:
http://moi3d.com/forum/index.php?webtag=MOI&msg=1944.1

- Michael

Hi Michael,

I forgot to mention that I was referring to multiple objects selection.

No way to stay with MoI 1.

George

Hi Michael,
i got a few questions.
what if i need to create an object with certain preset properties/style. ie i want to start drawing a red line. In this case how will i access this kind of property without having to create it first..
Does this setup mean you will need to have the object created or selected before you can see its properties dialog to modify? if so what happens if i have a hidden object i need to unhide or select. I assume there will be a dialog readily available somewhere in the viewport to select/deselect hide/unhide objects?
also how will i be able to modify say the swatch of multiple objects simultaneously?

How are grouped object properties being handled especially visibility of objects. my main problem with moi is its inability to reduce clutter by hiding and unhiding objects in my workspace easily and efficiently. You have to basically unhide everything temporarily just to select the objects you need to hide and/or unhide. it is a nightmare if you have quite a few objects already hidden.
I feel visibility templating and grouping properties should be readily accessible

Hi Michael, everybody. Not had much time on MoI for a while but been following the beta threads. Good stuff so far.


However, I think I'm with George here on this one. Though maybe confusing rather than complicated. So, I am not really convinced by this concept. Some thoughts for your consideration:

>>#4 is a swatch to show the current style visually.

Not sure why we need this? The current style is the one the object is displaying in the view port which we can already see.


>>For example with a circle it would list the center of the circle and its radius and let you change those values.

I would really like to see this in the panel not buried in a dialog. I believe that size and position is one of the things a properties panel should show at a glance.


>>Then #5 Tools will drop out a big menu, probably with just lines of text on it instead of icons and it will have a whole bunch of
>>somewhat more "advanced" tools on it that can be applied to the selected object. I think this menu will be where I'll be able to add many
>>commands such as Rebuild, Simplify lines & arcs, etc... This one probably won't be ready for a while longer.

This worries me a bit. Unless I am not understanding this you seem to be saying that you will hide these tools away in properties. I think this should be separate from properties perhaps in an advanced tools panel. Hiding advanced editing away in here doesn't, IMHO, match the clean and obvious way the rest of your UI works.


For the object properties I am also concerned with the idea that this appears and disappears every time I select/deselect something and disappears again when a command is run. I really want to be able to see properties update as I'm editing, not have them disappear as soon as a command is run. Skellos comments in the previous post also apply here. In properties I was expecting:

Object Type - group, line, solid, etc
Object name
Colour
Size x, y, z
Position x, y, z

I was also hoping for each of these to be editable in the properties panel directly not with another pop-up box that needs to be okayed. So you can type in the name of the style if you know it. If not, or you want to create a new style, click the style manager button. For numbers the current 'popup-calculator/type in the number' system seems appropriate here too.

Here's my humble suggestion for a simple properties panel:





As I said earlier, I believe the advanced editing tools would be better placed separate from the properties.

Sorry for the long post, I was going to say this is my tuppence worth - but it ended up more than that :-)

Hi skello, thanks for your feedback!

One thing to keep in mind is that this part that I mentioned here is only one piece of the full object organization tools.

There will be another piece which will a kind of scene browser, which will be the thing that controls many of the grouping and kind of object batching tasks that was a big part of what you are asking about.

You can get an idea on what that part may be like from this previous discussion here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=1944.1

I'm not quite ready to work on that part yet though - the part that I'm working on right now is how to edit the properties and appearance of objects (not including visibility for this part).


> what if i need to create an object with certain preset properties/style.
> ie i want to start drawing a red line. In this case how will i access this
> kind of property without having to create it first..

Currently I have not really placed a big priority on this.

But one idea is that inside of the "Style manager" dialog it could be possible to have a checkbox on a style that says "Use for new objects", and if you checked that box then that style would be the one applied to newly drawn objects.

Another idea involves the scene browser part - maybe it will be possible there to tag a particular group as being the one that newly drawn objects will belong to, and if all the other objects in that group have the same style, that style will get applied to the newly drawn object as well.


Actually, one thing that just occurred to me which may work well is to have a style property that shows up when there is nothing selected - that will show the "active style" used to draw new objects in. That would make it pretty quick to set this. The process would be: before you draw an object, deselect all current objects to make the "New object style" shown in that upper-right area of the window (where command options currently go), click on that to get the styles dropdown and set it to what you want, then when you draw the new objects will have that style applied to them.


> Does this setup mean you will need to have the object
> created or selected before you can see its properties
> dialog to modify? if so what happens if i have a hidden
> object i need to unhide or select.

Generally I try to follow a rule that hidden objects cannot be selected, because otherwise it is pretty easy to do things like unknowingly delete them.

But I think that there may be an exception to this (at least for a few particular uses) when you highlight objects inside the scene browser list, which will be another way for you to select objects rather than clicking on them inside the viewport.

So possibly to do the things you describe, you would go to the browser list, highlight the object, then the properties panel will show the properties for that object (even if it is hidden I think), and there will likely be a control built into the browser for unhiding an object or a whole group of objects at once.

> also how will i be able to modify say the swatch of multiple
> objects simultaneously?

When you have a multiple selection, the swatch control will still be available, it will just say something like "multiple styles" if there are objects with many different styles selected. You will then be able to click on that "multiple styles" entry to get the same style list dropdown as you normally would with a single selection, and when you pick a style there it will be applied to all selected objects.


> How are grouped object properties being handled especially visibility of objects.

The visibility will be controlled by something on the browser panel instead of on this object properties panel. It would otherwise not work very well to try and put it on the object properties panel because you have to have an alternate way to select a hidden object to make it visible. The browser panel will provide that.


> my main problem with moi is its inability to reduce
> clutter by hiding and unhiding objects in my workspace
> easily and efficiently

Yes - that is going to be a focus for the browser panel part.

- Michael

Hi Tony, thanks very much for your feedback and illustrations!

Your UI looks very clean as you have presented it, but I think it will be tough to put in more real-world kind of values into the tight spaces that you've got there.

Numeric values in MoI's UI are specified by default to 2 decimal places of accuracy.

You've currently listed coordinates like 100,226,27 in there - it would certainly be nice if coordinates were always as nice and compact as that!

But a control like that will really need to be able to handle coordinates more like this: 1002.53,225.23,10.6 then with more digits they get hard to read without a space in there, so probably more like: 1002.53, 225.23, 10.6 . Really I don't think it is feasible to have a proper full point control jammed into just half the width of the side pane, I think a point control is going to need to take up a whole line by itself.

Additionally there will probably be some kinds of objects which have different properties that don't map directly to a "size". Like for example an arc could possibly have a radius, start angle, and end angle values. It is probably fine to start with just a radius, but it would be good for the property editor to be set up with the idea of being able to expand to handle more kinds of properties.

Another example - for just a line it would probably be good to have start point, end point, length, and angle in the plane.


Some replies to your comments:

re: Swatch
> Not sure why we need this? The current style is the one the
> object is displaying in the view port which we can already see.

Yeah it is not a truly necessary thing, but it will probably match well with the list of styles that are shown in the drop-down, I think that style picker thing will have a set of swatches with names under them, so having the name + swatch bubble up to the top after you pick it will match nicely.

Also I don't think that the object will always be displayed as you mention here - using the browser panel I think it will be possible to select an object that is currently hidden and edit its properties.

At first the names and swatches will be kind of duplicated, like "Red <red swatch>", but as you add your own custom styles you may want to use the name for a different kind of description, more like: "Outer hull <swatch>". I think having the name + swatch there will could make it a bit more comfortable to use other kinds of names for the styles.


> I would really like to see this in the panel not buried in
> a dialog. I believe that size and position is one of the
> things a properties panel should show at a glance.

For me, just looking at the object on the screen in relation to the grid gives me a good enough general idea of its size... I guess that's why I don't really understand why you would need this always at the top level.

It's unfortunately very difficult to jam a lot of information into a tight area.

One benefit of moving it to a secondary dialog is that I won't need to skimp at all on the information, I'll be able to provide a lot of details there.

I was originally going to have this on the top level but it just does not end up really being compact enough and not very extensible.... That's basically what drove me to push it off to a secondary thing.


> Hiding advanced editing away in here doesn't, IMHO, match
> the clean and obvious way the rest of your UI works.

It's definitely true that it doesn't match the rest of the UI.

But these things are also in a different category of use from the rest of the UI.

This will be a kind of "pressure release valve" UI where I can dump less frequently used tools.

It is not very good to have specialized or less frequently used tools incorporated into the same UI as the more heavily used ones... That leads to clutter and a reduction in the effectiveness of the frequently used tools.

I need to have a secondary mechanism for launching commands that does not kind of pollute the more standard, mainline tools.

Don't get me wrong, I'm not exactly thrilled at putting them there, but I definitely need a kind of auxiliary area to hold a large list of specialized commands. So I need to have a launching point for that somewhere.


> I really want to be able to see properties update as
> I'm editing, not have them disappear as soon as a
> command is run.

That would be cool... But hiding UI and re-using existing space is really needed to keep the UI streamlined and easy to use. There are some sacrifices that have to be made that go along with that though.


Thanks very much for the ideas and feedback! It is definitely useful to get other viewpoints.

- Michael

Does system objects has some mix "group" & "objects" in any order successive infinite arborescence?
Or it's too early time of the conception?

Hi Pilou,

> Does system objects has some mix "group" & "objects" in
> any order successive infinite arborescence?

I think the way it will work is that a group will be able to contain either objects or other groups that are children of the group.

Then I think there will be a special group called "All objects" which is always available and lets you browse through all the objects underneath it, or use the group tools (hide /show / etc..) to apply to all objects that way.

Something like this:



But I am not working on that part quite yet though.

- Michael

Hi Michael,

> ... But hiding UI and re-using existing space is really needed to keep the UI
> streamlined and easy to use. There are some sacrifices that have to be
> made that go along with that though.

Have you considered utilising the left side of the UI with a side pop out panel that people can choose to have it stick or hidden, and as you have collapsible command palettes, you have the same for the object palettes, and more space to play with!
IMHO I don't think this would change the simple clean UI of MoI because as a new user you would be presented with the standard layout, and will look and behave as it is now, as the user becomes more proficient and advanced they can start using the object organisational stuff and what ever else would be added in the future, sort of like modules where it doesn't stop a new user from getting started.

---------

The Danny idea is much like we have in Carrara.

I like it.

Brian

Hi Danny, yes that kind of additional panel being able to be popped out or closed is what I am thinking of doing for the browser panel that will let you manage groups and batches of objects.

By default I expect for it to be closed, so that it won't fill up the screen for small projects where it does not do any good, or get in the way of new users so much.

But I was planning on stacking it on the right side of the screen, to the left of the standard current side pane, along the lines that Grendel showed in this previous thread:
http://moi3d.com/forum/index.php?webtag=MOI&msg=1944.1

It kind of makes for a nice open feeling to have the left and top sides open and without UI on them. Getting UI to all sides of the viewports kind of gives a bit of a "boxed in" feeling instead.

But eventually down the line in future versions there may be other panels that could optionally open up along those edges too, so far I haven't had any ideas for a left-side one but when there is more render stuff available I was thinking of an optional material swatch panel along the top.

- Michael

These are the four pull out panels in Hexagon. Similar to Carrara.

Brian

Thanks for the reply Michael, I see where you are coming from.

>>That would be cool... But hiding UI and re-using existing space is really needed to keep the UI streamlined and easy to use. There are some
>> sacrifices that have to be made that go along with that though.

Then, can I make a feature request for tear off panels please?

I have 2 21" screens here and MoI is limited to only one of them. Modo, Photoshop, etc, let me drag panels out of the main interface and onto the other screen so they don't clutter the main window.

It would be great to be able to leave the advanced tools and stuff on the second screen for speed of access. Especially the proposed browser panel.

Carrara suffers from the same problem. Won't let me pull the panels out onto the second screen.

Thanks for listening.

Hi Michael

Thanks for explaining..
The active style property and others you described sounds great!
i'll look foward to trying the system out when its available.

cheers

Hi Tony,

I was thinking some more about what you had written previously. Maybe instead of trying to cram a bunch of editing directly in there, maybe one possibility is to have some display-only information added to the top level.

Like for example:



To edit the size you would still go to Details to put up the full dialog, and the full dialog would have a lot of additional stuff on it like center point, etc...

For a circle or arc instead of Size: it could show Radius: there, and for a line it could show Length:

That could possibly give some of the most basic information up there at the top level.



> Then, can I make a feature request for tear off panels please?

I would definitely like to have those. Unfortunately it will take a substantial amount of work to make that happen, it is just not going to be feasible anytime too soon.

Early on in the development of MoI it was apparent that it would be very time consuming to attempt to do drag/drop type dynamic UI editing at the same time as trying to refine and develop just one UI to be as good as I could make it. I did not have enough time to pursue both, and I ended up choosing the latter.

At some point in the future maybe I will be able to do a major overhaul of the underlying UI mechanism and be able to add tear off / rearranging and docking of panels at that time, but that will be somewhere down the road a ways.

- Michael

Sounds good Michael, any extra info on size and/or position is useful.

I understand that a movable UI is a lot of work for one man - even you ;-)


A question just occured to me. Will all this new stuff be as configurable as V1 was? If so then I can tweak the interface again to suit my needs as I did for version 1.

Hi Tony,

> Sounds good Michael, any extra info on size and/or position is useful.

One thing that I don't quite follow is the position part.

A general object doesn't particularly have a single special "position" point on it... Like for example what would you say is the position of this object:



Is it the center point of the curve's bounding box? I don't quite understand why you would want to know what that point is at the top level of the UI all the time (as opposed to on a secondary dialog), I mean it is not on any part of the definition of the curve...


> I understand that a movable UI is a lot of work for
> one man - even you ;-)

:) Yup, a lot of work is a lot of work for anyone!

One thing that tends to help keep me reasonably efficient is to kind of pick my battles a bit carefully and try to stay away from areas that would require quite a lot of sustained work.

One area that is particularly difficult with movable UI is to try and handle docking of different sized panels or toolbars adjacent to one another.

It may be possible in the future for me to focus on something more limited than that, like only being able to tear off large panels that take up a whole edge of something rather than trying to stack small pieces together. But even that will probably be a ways out.


> A question just occured to me. Will all this new stuff be as
> configurable as V1 was?

My current version is not too flexible, it depends on specific elements being present in the UI and those controls being updated more directly from the back-end code.

But I should be able to revamp this pretty easily to be much more flexible, so that some script code in the UI will get a notification to update and that script code can be more responsible for dealing directly with the UI controls.

That should help with customization a lot, but it still requires some cooperation from the back-end as far as what properties and values are available to be accessed by the script code.

It would make it pretty easy to add something like a bounding box center point at the top level if you want though.

- Michael

Hi Michael...

When I can use object properties ?

-anis

Hi Michael,

The object properties panel idea looks great.

For another object organization example, Xara has a simple naming concept, having cross-grouping functionality.

In the example, I have assigned the name "two rectangles" on two gray rectangles. (See picture)

When I select only one of them of them, only half of the red circle displays next to the name shows. If I click on the empty circle next to the name tag, the corresponding objects will be selected.

I could have created another name tag with the magenta rectangle and one of the grey ones.

The name gallery also serves as a selection filter as it contains many parameters of existing objects in the current file. For example, if I were to click on arial, all the text of this type would be selected.

This is a relatively misunderstood feature in Xara and few people use it as I understand it.
But I found it quite a good idea and it widely surpass layers as an organization concept.

Marc