Hi nemuneko, thanks for reporting this problem with Japanese keyboard shortcut keys.

It may be related to this Qt bug mentioned here:
https://codereview.qt-project.org/c/qt/qtbase/+/95050

There seem to be some fixes in the Qt Mac keymapper since the version that MoI currently uses. Probably the first thing to try is for me to update that and see if that helps.

Can you please try using the attached updated version? To apply it, right click on MoI v4 beta Jan-22-2020.app and choose "Show package contents". Then inside there go to Contents > Frameworks > qt > platforms. Rename the existing libqcocoa.dylib something like libqcocoa.dylib.bak and then put the attached one in place there.

Is there any change in behavior with that in place?

If not it may be difficult for me to fix this since I don't have a Japanese keyboard over here. Maybe I can make a couple of test builds to send to you that could gather more information about how those keys are being processed. I will be away on vacation for this next week so we could try that after I return.

I can reproduce the CapsLock making an "A" (on every 2nd keystroke it appears) so that's one I can dig into more easily. But I think the fix will be to just do nothing, CapsLock isn't meant to be used as a shortcut key.

Thanks,
- Michael

Hi Michael,

Thank you for your response.
I replaced the qt lib to your updated version and it work!

Backspace key work as 'Delete' shortcut.
Enter and Tab are recognized as UI shortcut (I think this is correct behavior).
Other keys show same behavior but they aren't meant to used as a shortcut key as you said.

It seems that the updated version of qt lib solved this problem.

Thanks a lot!

nemuneko

Hi nemuneko,

re:
> I replaced the qt lib to your updated version and it work!

Great! I'm glad that fixed it.


> Enter and Tab are recognized as UI shortcut (I think this is correct behavior).

Yes that's correct, since they are used by the UI as an alias for 'Done"/OK and for moving focus between controls they are not recognized as a target for shortcut keys.


> Other keys show same behavior but they aren't meant to used as a shortcut key as you said.

That was for English/Number, Kana, and CapsLock keys, is that correct?

I can reproduce the CapsLock one over here and I should be able to fix that up too.

The English/Number and Kana keys are modifier/mode type keys is that correct? I mean they don't produce a printable character if you press it just by itself?

- Michael

Hi Michael,

>That was for English/Number, Kana, and CapsLock keys, is that correct?

Yes.

>The English/Number and Kana keys are modifier/mode type keys is that correct? I mean they don't produce a printable character if you press it just by itself?
Yes, they are special mode keys which used to switch input methods (English <-> Japanese). They don't produce a printable character.
Also I think English/Number and Kana keys are not used for shortcut.
(I add them to the symptom list just to cover all physical key behaviors. I'm sorry if you recognize these keys are modifier key used for shortcut.)

Thanks.

nemuneko

Thanks nemuneko, I thought it was like that but I wanted to double check to make sure.

Thanks, - Michael

Hi,

I guess this has been mentioned, the fractional display on the dimensions does not work.

Otherwise I like the behaviour of dimensions, maybe the could be a stop on the resizing of the text when you zoom out at a certain point (perhaps when the text touches the arrows?).

Thanks,

Marc

Hi Marc,

re:
> I guess this has been mentioned, the fractional display on the dimensions does not work.

Fractional display should be working if you set Formatting > Distance display > Feet & Inches, but you also need the current unit system (under Options > General > Units) to something other than "No unit system" for it to take effect.

If you have "No unit system" then it isn't able to determine how long a foot is so "feet & inches" type fractional display isn't able to work there.


> Otherwise I like the behaviour of dimensions, maybe the could be a stop on the
> resizing of the text when you zoom out at a certain point (perhaps when the text
> touches the arrows?).

Well there isn't actually any resizing of text currently. Right now text is always drawn at the same on-screen point size regardless of zoom. This does have a kind of sense that it is sizing when you zoom out and objects become smaller but text size remains the same.

I do want to experiment in the future with some options to shrink the text down when you zoom out. But doing it when the text touches arrows would result in a variety of different text sizes on different dimensions if some have plenty of room between the arrows and others do not. The other problem is that text blocks only have a single reference point and so there is no "in between" measurement to use for them.

It will probably need to be a setting for "Max text size in model units" or something like that so you could say make stuff smaller than 5 model units to be shrunk down. That's probably not going to happen for the v4 timeframe. But there is one more related area that I have left to work on for v4 which is an option to make the text size entirely controlled by model size so it both shrinks and grows in size when zoomed same as geometry does. One part that's not good about that is that it then can cause really large sized text. But that way will have better compatibility with how other CAD programs handle text.

Thanks,
- Michael

Dear Michael,

I have some DXF file that can't be offsetted properly. I'm trying to generate roads from curves I imported. I'm using the offset tool using the Bidirectional and Trim settings with a distance of 0,15. The curves get disconnected.

I hope you can take a look at it. I've attached the .dxf as an attachment.

Hi Yanik, re: offset problem - I think the problem is that Offset in MoI is focused on working on a closed loop, not a branching structure like you have here.

It will try to join together segments that touch to try and make a closed loop but that is not good for your branching structure.

I don't think that MoI's offset will produce the kind of result you're looking for here, you've got not just branching but some pieces touching others in spots other than endpoints making "T" junctures. MoI's curve offset is not set up to handle those either.

Maybe a 2D CAD program that has an architectural type "wall" offset might do what you are looking for.

- Michael

Hi Yanik, you might be able to get somewhere with that with Max Smirnov's "Fatlines" script (http://moi.maxsm.net/files/), I think that script will thicken each curve individually instead of trying to join things together to make closed loops like MoI's regular offset function does.

- Michael

Funny that i adviced somewhere ;)

Seems you must trim in some parts before use Fat Lines
Don't know if there too many roads or if there are particular intersections or ...
red = trimming polylines

Hi Michael the lines are all individual lines. Each road is a polyline with multiple points. The concave points have issues when offsetting them. The FatLines script has the same issues.
Not sure what the problem is. It works fine on similar drawn polylines.

Having used FatLines script in complex senarios (recent one was a vitro window for a 3d scene) it helps to separate the project in portions. When I tried to apply it at once to all of the linework things froze up.

If I offset just 1 polyline I get the same issues. So it's not related to complexity. Try the dxf and you'll see.

Hi Yanik,

re:
> If I offset just 1 polyline I get the same issues. So it's not related to complexity. Try the dxf and you'll see.

I am seeing some issues with polylines that are at shallow angles to one another.

In general MoI is not expecting to work with polylines like that which have numerous line segments at shallow angles to one another, it's expecting for things shaped like that to be smooth curves and not polylines.

- Michael

Hi Michael,

I'm not sure I understand, shouldn't the dimension display units be independent of the model's?
Hobbit's foot are something else than 12 inches? :)

Marc

This curious thing of looping was due of an old version of Fatlines!



with the FatLines for v4 no more looping! : even with the DXF above post! ;)
Lignes Epaisses = FatLines

Here is a result I made. 3 or 4 lines are missing, but it could have been dealt with. A little more than just 1 click though.



Since you want to keep the breakpoints of the polylines, that is what kindof makes the offsetting hard.

So I joined and rebuilt the original file (Rebuild to remove all the corner points)

Then I extruded the new curves and shelled them on centerline. I could then Boolean together the shelled solids into a single solid.
(This is where I lost 4 lines. they would need to be addressed at the extrusion level to get good solids to bool)

From the single solid, I can extract the bottom edges to create the thickened curves.

I can now bring in the original file and extract the points I wanted to keep (As waypoints I guess?)

Anyway, I can make a video if this file looks like what you are after and you wanted to see more.

The curious is the FatLines works fine with only certain measures of lines...

Not sure if rendering bug or performance optimization: