Hi Martin,

> Select one curve and apply the Join tool - obviously nothing happens, except the edit frame
> remains on screen (and selectable), until another item is selected. You can even draw more
> curves etc., without it clearing.

Thanks for reporting this bug - I've got it fixed up now and the fix will be in the next v3 beta release.

- Michael

Hi Martin,

> I think I might be getting an unnecessary scroll bar appearing on the right hand side
> of the screen and it seems to be slightly corrupting the layout there, as well as making
> things jump about a bit.

I think this is due to some unwanted word wrapping happening, it's difficult for me to reproduce over here since it's dependent on your particular font, font size and screen size.

Can you please try using the attached update to the chamfer command and see if it behaves any better with that in place? Just copy the attached Chamfer.htm file over the previous version inside of the \commands sub-folder inside of MoI's main installation folder.

- Michael

Michael.

I think you've cracked it with that - it works perfectly in Chamfer now and is much, much nicer on the eye!

In between times, I've found that the Array tools are acting in exactly the same way and give a pronounced judder to the screen as I switch between each array tool. The right hand side of the screen sort of shuffles about as it updates itself to make way for the scroll bar and the Curve (array) tool moves down a line too - I'm pretty sure this was a significant part of the effect I was experiencing when I asked you about changes to the toolbar area a little while ago.

Could you do a similar fix here by any chance please?

Thanks very much for sorting this out!


Martin (2).

Hi Martin, I'm glad that the chamfer UI is behaving better for you with that update in place!

> Could you do a similar fix here by any chance please?

Right now I'm not sure which specific piece of UI needs tuning up, I'll need some more information in order to know where I should apply a tune up.

Can you maybe post a screenshot showing what things look like when the scroll bar is showing?

One thing to note is that it's totally normal for a scroll bar to show if you simply have more UI needing to be displayed than will fit within the given area. If that's what you are running into then it's possible that there may be nothing to be done to tune it up, you would need to slightly decrease the UI font size or switch the scene browser to be in the other "Adjacent" mode where it is a separate panel rather than the "inside" mode where it occupies space at the bottom of the side pane, or get a higher resolution display that just has more space on the screen.

Right now it sort of looks like you're very close to having the entire side pane UI all completely filled up - switching the scene browser to the "adjacent" mode would likely help with that quite a bit.

But if I can see what particular piece of UI is misbehaving with word wrap in a screenshot from you there is a chance that I could fix it up - again those things are dependent on your particular UI size and what fonts MoI is using on your system so I do not see the same behavior you are describing over here and so more details about what you are seeing would be helpful.

- Michael

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).