(2016-12-18, 21:53)Milan Vančura Wrote: I may describe this for you. There are two different issues. The first one is that, in past, the Alt key was handled differently than Shift and Control on Linux. Even you might still find some articles about that on Internet, I believe all modern desktop libraries already solved that. For example, with wxWidgets it's a matter of a choice of events. The second issue may be that somebody might configure his/her window manager to use same hotkeys for some actions. That's same as with, for example, alt-tab on Windows. But Alt-[A-Z] are usually not used for that - because even other applications use the same hotkeys (Alt-F, Alt-E, Alt-V, Alt-H for menus: File, Edit, View, Help...). In the end, it's up to the user to configure hotkeys of both LDCad and his window manager to not have conflicts... I do not know about Windows but it's extremely easy on Linux.
I just realized I didn't use the alt key in the hardcoded hotkeys as it woudn't work on all platforms, but there is no reason to not use it now the hotkeys are dynamic. I've enabled them in the current Beta 1 build and also made it possible to open menus using hotkeys. I've set the defaults alt+s to open the 'select' menu and alt+v to open the 'editing views' menu as those two are needed often during editing.
(2016-12-18, 21:53)Milan Vančura Wrote: (2016-12-12, 19:48)Roland Melkert Wrote: Layered groups are a bit experimental. I was planning to iron it out in Beta 2 by allowing users to name layers which will then replace the current layer 1 2 3 placeholders.
I though about a way how the user can have a better overview of defined groups and not needing think about group layers at all, to hide this logic in GUI. However, I must say I do not have a solution for this, it's just an idea. Or, better, a wish 
The reason is that it's very hard to remember which group is defined on which layer now. Or maybe we can keep this layer switching but add a submenu with a list of (optionally named) groups together with a layer number/name? Something like:
Code:
1. front left wheel layer 1
2. front right wheel layer 1
3. front axle with wheels layer 2
...
Actually groups can indirectly be part of multiple layers. The main reason I introduced this is to make it possible to use different configurations in different animations using the same model. I'm going to refine the whole layer thing in beta 2 so if you (or anyone else) has additional ideas please let me know.
(2016-12-18, 21:53)Milan Vančura Wrote: (2016-12-12, 19:48)Roland Melkert Wrote: I could display the 'Selection contains invisible items' label as is done when e.g. a step meta is in the selection.
Yes, good idea. And I believe it would be even better if it is an icon, different for each of these two situations (set independently): "selection contains hidden parts" and "selection contains metadata lines". An icon takes much less space so they can be shown both if needed and still be on the right of "Step" indicator. And you can set up a "hover text" for them.
I've added hidden parts to the 'label' logics. I do like your icon approach though that might also solve another 'complain' mentioned in this thread: 'relative grid active state indidication'. I'll put it on my Beta 2 list.
(2016-12-18, 21:53)Milan Vančura Wrote: And wouldn't be possible to show that plane directly in the Edit window, similarly to the grid or the far plane of the rectangle select? It would be much easier to understand, especially with local coordinates set ("o" key).
I'm not sure I understand this, the compass shows the current axis even when unzoomed. The thicker lines are always the relative ones, the thinner ones show the absolute ones (can be disabled).
(2016-12-12, 9:27)Milan Vančura Wrote: What about that "rectangle unselect" feature? That would help if one takes too much or wants to combine that like "select this rectangle without that corner".
This is pending, the truth is the region select currently uses a 'hack' to add stuff the to selection while re-sizing in means of a temporary extra group. Doing deselect is therefore a bit harder to do
(2016-12-18, 21:53)Milan Vančura Wrote: I may try to create that script for triangles then. (And give it to everybody - if it works )
The approach used in the selection info triangle helper can be scripted I think the only problem might be how to decide on the side to use. The 8071 example uses something very similar through its 'calcTrianglePlacementAngles' function. Let me know if you need some additional low level vector/matrix object math method or something.
