Hi Pilou,

> truncated but possibility to go to the end?

Sorry, I'm not quite sure what you mean.... The text will be truncated but you'll be able to see the eye controls for example. I'm not worried about getting this part nailed down right now that can come a bit later if the main design is working well.

- Michael

What append in this case? (I say component but that can be anything :)

Some more refinements - now the section names (Groups, Objects, Types, Styles) have a different visual style so they don't blend in so much with the items:



- Michael

Hi Pilou,

> How see the "component" 7 in the red window?

Your content you show there is bigger than the window, so there aren't a whole lot of choices - probably the method would be either making the window wider, or having a scroll bar. That's something that may not be handled with the initial versions.


> Other thing : moving "component 7" to "component 1"
> with the mouse inside the windows is possible?

No, not initially. At first there will probably be a "group editor" dialog box that has some up/down buttons on to handle arranging things.

Direct drag and drop type re-arranging likely won't happen until the future.


- Michael

Hi Michael,

The lines make things much better, plus the visual style for section names helps to separate the different items.


I do agree with Frenchy though. There seems to be a flaw in the basic design here if it won't accommodate deep nesting. I'm not in favour of a horizontal scroll bar either. I really want to see the structure of my model not have to keep scrolling left and right - seems very anti-MoI :-)

Perhaps you will re-consider putting this in a floating window? Then the window can be re-sized to fit the browser tree as required.

Hi Tony, I'll probably be making some method to adjust the panel size.

Floating windows (other than temporary ones) are something that I have just tried in general to avoid with MoI's overall UI since they tend to hang out overlapping the main work area, making it cluttered and obscuring your view of your model data.

I'm not particularly worried about such a deep nesting to start with though, I'm more concerned with whether the basic UI works well to start with on something with just 3 or 4 levels of nesting. Then I will look at how to handle deep nesting after that.

- Michael

Thanks for the reply Michael,

As you already know, I would really like the window solution so I can put it on my second monitor.

So I may just keep mentioning it every now and then ;-)

Cheers.

Hi Tony, yeah in that situation you would avoid cluttering the workspace. But if I focused primarily on making this UI in a floating window for everybody, then people who only had a single monitor would end up with the cluttering problem.

In the future I do want to enable some methods for re-arranging the UI, for stuff like tearing chunks off and docking them in different areas or possibly on different monitors. But it is going to be a while before I am able to get to that.

- Michael

Just to clear things in my head, it seems to me Ill much prefer to work on the "Inside".and not the "Adjacent" mode...Is that how the UI gonna look in a situation like that?

Hi yannada, it will be similar to that except different with the scrolling behavior.

The inline scene browser is limited to only be a maximum of 40% of the size of the main window height (adjustable in moi.ini), so that it doesn't overwhelm the other controls in there.

When it gets to be long when in "inside" mode, the browser section gets its own vertical scroll bar, like this:



This mode will probably be good if you have a higher resolution monitor, and if you don't have a high level of nested sub-items in groups.

- Michael

Just an idea: maybe the tree could pan to the right when you hover items that are partially hidden and then return when not hovering.

Can't wait to try this browser!

Marc

Or maybe 1 of these......

Hi Marc,

> Just an idea: maybe the tree could pan to the right
> when you hover items that are partially hidden and
> then return when not hovering.

Interesting idea! But unfortunately pretty difficult to implement...

- Michael

Hi danperk - yup that one may be a pretty natural one to add in later.

- Michael

Michael I notice when you are on "Adjacent" mode, Scene browser is on the left side of the tool bar. Will it be possible to switch side?

Hi yannada, I'm not currently planning on making a checkbox option for that, but it will be possible to set it up if you edit a UI file (MainWindowLayout.xml).

Do you think there is some advantage to having it on the other side?

I thought you had said you wanted to use the inline mode...

- Michael

I think Ill be using the inline mode in most cases, but for large projects I may have to switch.

>>Do you think there is some advantage to having it on the other side?

Ill like the main tools to be the first to access (closer to me) Now it fells like I have to jump over the Scene browser to get to the main tools...perhaps is just me.

Hi yannada, well the main tools will be in the same location that they used to be before there was a scene browser. So it is not like you will be moving any further than you have had to previously.

Some things like the main window close / minimize / restore controls currently live in the side pane, it would maybe be a little odd to move those away from the window corner. So I'd probably have to do something about that in order to have such a mode.

Also I expect that it will not be that unusual to want to hide or show the browser fairly often (especially on lower resolution displays), and it seems like it would be kind of weird to have the main tools shift around every time you did that.

At any rate, you'll be able to give it a try, I'll tell you how to edit the MainWindowLayout.xml file to do it, you just move one line up to higher in the file so that it docks first before the side pane is docked.

- Michael

cool... edit the MainWindowLayout.xml it wiil do the job (if needed)

Hi Marc, previously you asked about swiping:

> I don't know if this has been said before but it would be nice
> if you could click+hold and then slide your mouse over multiple
> eye icons to turn them on/off ion a sweep motion.

Earlier I didn't think I would have this at first, but I've managed to add it in.

The way it works is that it remembers whether the initial clicked item resulted in a hide or a show, and when you swipe with the mouse held down, it will apply that same result to all the swiped items.

Does that make sense rather than trying to invert every item you swipe over? Doing an invert seems less of a predictable thing when there are a mixture of states, rather than applying the same thing to all the swiped items.

- Michael