Hi Michael.

I've just come across Steps Recorder in Windows 8, so I've tried to use it to show the situation as it is for me.

There are 15(!) screenshots in the attached .zip file which are apparently viewable in any browser, so you can see how the scroll bar comes and goes, depending on which array icon is chosen and whether MoI is in full screen or super-full screen mode.

Just to be a bit clearer, when in super-full screen mode, the scroll bar never seems to show and there is no fidgeting of the display.

If I try to grab the scroll bar, it disappears and all the array icons arrange themselves back onto one line, but notice the large white area to the right of the Curve icon.

My MoI UI size setting is 13 and Arial seems to be the font that MoI defaults to for its Draw solid Text tool, so is this also the one it's using for its interface?

If I can, I'd like to keep the Scene browser where it is, so as to conserve space for drawing, but if this turns out to be impractical I'll experiment with other the options.


Thanks again for checking this out.


Martin (2).

Hi Martin, thanks for posting the additional information.

Can you please try the attached update file Arrays.htm, this one also goes in place of the previous version in the \commands sub-folder.

Hopefully it may help with this problem.


> My MoI UI size setting is 13 and Arial seems to be the font that MoI defaults
> to for its Draw solid Text tool, so is this also the one it's using for its interface?

It initially tries to look for the font Century Gothic, but if that is not available on your system it will use Arial instead.

But the behavior that you are showing there is system-specific because it's related to running out of vertical space at some point in the display update, and then something like a vertical scroll bar gets triggered when I'm not wanting it yet (it may be a WebKit bug), taking away a little bit of horizontal space from the available UI area, thus triggering word wrap and then requiring additional vertical space. These particular conditions about when you run out of vertical space at one particular time during a UI update is dependent on various things like the font that's used, the window size or your screen resolution size, your MoI UI size, and your system DPI size, and also whether you've set the scene browser to "inside" mode like you have done.

It might be something that could be tuned up in the whole UI layout mechanism or it may be a WebKit bug, but unfortunately either of those are complex areas to deal with and it would be pretty easy to cause worse problems if I were to just fiddle around with it. But with certain UI areas I can fix it by disabling word wrap in strategic spots, the problem is that I cannot always just turn word wrap off entirely in every case because the UI can be run in numerous different languages, and some languages require a lot longer words than others, so often times word wrapping can be beneficial for localization.

The reason it does not happen for you when you trigger "full screen" mode (where MoI expands over the task bar), is that little bit of extra space takes your configuration out of where it's so close to running out of vertical space all the time.

So that's why another possible way for you to solve this particular issue would be to slightly reduce your UI size, or move the scene browser back to the default "adjacent" mode so that you would not always be right on the bubble of running out of vertical space.

Basically it probably wouldn't happen like that if you had either just a little bit more available space or just a little bit less available space, it's when you're at a particular size that has a lot of switching between enough and just not quite enough that is triggering that behavior.

- Michael

Hi Martin, also:

> If I can, I'd like to keep the Scene browser where it is, so as to conserve space for drawing,
> but if this turns out to be impractical I'll experiment with other the options.

Really though the "inside" scene browser mode was designed to be used in cases where you've got a high resolution monitor and there was going to be a whole lot of empty space at the bottom of the side pane.

When you have the scene browser in the "Adjacent" mode where it's a separate panel you can still conserve space for drawing by collapsing that whole panel which happens when you click on the "Browser" button that will show up in the bottom of the side pane.

If you don't have a lot of screen space the scene browser just tends to work better as a separate full panel when you do need to use it, just hide it when you're done using it to reclaim the drawing space.

- Michael

Hi Michael.

Another great result with your updated file - no more jumping about for me!

Thanks very, very much for that and your detailed replies. The display is really comfortable to use now.




If I can ask one more thing of you :) that's not a feature request, I'm just asking if it's already possible.

I see I can switch off the View controls under options, but is there a way I can choose which ones appear?

For instance, I use Area and Reset all the time but never touch Zoom, Pan or Rotate, because they're already conveniently on the mouse. I would find the Hide button convenient to have there instead - is that currently possible?



Cheers.

Martin (2).

Hi Martin, I'm glad that the jumping is under control now!

> For instance, I use Area and Reset all the time but never touch Zoom, Pan or Rotate,
> because they're already conveniently on the mouse. I would find the Hide button
> convenient to have there instead - is that currently possible?

Eventually I want to have some kind of UI editing incorporated into the UI like maybe you would go into some special mode or hold down a particular key and drag on a button to re-arrange it. But right now there isn't anything set up exactly for that, and that's probably quite a ways off.

But the UI is built off of .htm files and it is possible to change the UI by editing those files in a text editor like notepad.

The file for the view controls is named ViewControls.htm and it's in the \ui sub-folder. If you open that up in notepad you can delete the entries for particular buttons, each one is a <moi:CommandButton> tag in the file, and if you open up the file SidePane.htm you can look in there for the hide button and it is possible to copy the <moi:CommandButton> button tag from that file and paste it into the ViewControls.htm file.

You will run into some maintenance problems if you do decide to do this though, because you'll need to repeat this with each new beta release, and sometimes those same UI files are changing of new features that I'm also adding in so it's a moving target.

But yes it is possible.

- Michael

Hi Michael.

After following your instructions, I made the changes and amazingly, everything worked first time!

I've applied this particular mod to MoI v2 so I don't have to keep re-applying it as new betas are released, but at the same time I can get the feel of how it works.

Going by my initial impression, just those three icons seem like an adequate combination for me, so when V3 is finished, I think I'm going to copy the change over.


Thanks for your help.


Martin (2).

Michael.

In the attached file, the cone placed at the origin was generated by extruding a circle to a point and with no end cap selected.

Using the Shell tool to thicken it up a bit, gives a rough result and I wonder if this can be tweaked.

The other cone was made from a revolved line and the surface thickened in the same way as before, but this time, has turned out as expected.





Thanks.
Martin (2).

Hi Martin,

> Using the Shell tool to thicken it up a bit, gives a rough result and
> I wonder if this can be tweaked.
>
> The other cone was made from a revolved line and the surface thickened in the
> same way as before, but this time, has turned out as expected.

I've got this updated for the next v3 beta - in the next beta when using Extrude to point where the base curve is a circle or arc shape, it will make an analytic cone surface out of the result and that will help this case to offset properly.

Thanks for reporting the problem,

- Michael

Ha that sounds cool..

Peace,
Rich_Art. ;-)

Michael.

There seems to be something odd happening when I edit the size of an arc if it lies directly on top of a circle.
Please take a look at the video to see what I mean.

http://screencast.com/t/ixR4gcFS9K


Martin (2).

Hi Martin,

> There seems to be something odd happening when I edit the size of an arc
> if it lies directly on top of a circle.

There's a feature in the resizer where if you're resizing a line or an arc, it scans through all the other objects to see if there are other existing curves that touch the current one at an endpoint, and if they do it uses that endpoint as the scale origin.

That enables behavior like this - when you edit this radius of this arc here:




The edited arc gets scaled like this so that it's still connected to the adjacent line:




The same thing is kicking in for your case with a circle - a circle also has a start and end point to it even though you don't normally see it, and if the arc being sized touches that point at one of its ends it will get anchored to it.

I'll tune this mechanism up so that it will skip closed curves when it's looking for any other touching curves since it's pretty weird behavior in that case.

Thanks for reporting the problem,

- Michael

Thanks Michael.

And thanks also for providing this feature - it's great being able to edit an arc in this way, I usually have to erase and redraw in such cases.



Martin (2).