Hi there. Great software.
It would be wonderful to be able to control the 3D view with some user defined keys.
I know it is possible to control zoom with ctrl+[
and ctrl+]
, but I'd like to have more control in order to not use the mouse at all.
As a Vim user for years, I'd like to control for example the draging of the view with the Vim keys as in
k
^
|
h <--- ---> l
|
v
j
This would improve my workflow a lot once I'm always resting my right hand on top of those keys.
I'd also like for this feature to be user defined if possible. I'd like to put zoom action to keys like i
and o
.
In fact, I think it is a waste of fingers to use ctrl+[number]
to change views. Why is it not as it is in Blender, where you can change view directly with number keys. It would make more sense.
Is this already possible in the 2019 version? If so, how?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Is this with the editor window hidden, as it has focus and gets plain keycodes? Or are you proposing a command mode toggle?
There is currently no keyboard remapping built-in.
I agree, some form of keyboard control of the preview window is needed, both translation and rotation on top of the existing zoom. Particularly helpful for accessibility.
The Ctrl+n is pretty baked-in, but if there was some toggle, maybe 'n' just could be used.
For info this list, is probably a little out of date, but it looks like k/h/l/j are almost unused, i/o not so much. See also the links, in particular to Qt, which has 4 OS flavours which need to be corralled. Choosing key combos is like herding cats on ice [the frozen water variety, I imagine the other would be difficult too..].
I think a command mode toggle, such as Vim's, would be wonderful, but once I'm not aware about the guts of Openscad's code development, I'm afraid it would be a pain to implement such feature.
Instead, I'm proposing the idea of leaving all it's current default keyboard mappings untouched - so it doesn't change everyone's lives - and implement some sort of API of it's keyboard mappings for advanced users to tweak.
For example, we could have a hidden file in Home folder (.openscadrc) where we put the new mappings and possibly other settings, so every time openscad opens, it reads the file and sets itself based on it.
And yes, without the command mode toggle, this would only make sense with the editor being hidden.
Yes, this is the one feature I'm waiting for! It would make the work so much more comfortable.
I think, reading some "hot keys" from a text file would be sufficient and easy to implement for somebody who is familiar with the code. I would even prefer a file based configuration over a "hot key dialog". Key bindings should allow to also use modifiers, especially âčCtrlâș. Such key bindings should work globally, no matter where the GUI focus is currently located.
I â and I think many others â don't use the editor, but only the viewer and the console. So, vim modes are not really necessary. Only the "scene navigation" for the 3D model and showing/hiding, scrolling and maybe resizing the console would be sufficient (and a huge enhancement). Also remapping of the existing hot keys (rendering, STL export...) is of course highly desirable.
I have some view on this like it's good to implement a user-defined keyboard shortcut feature. But I think, allowing users to control modifier 'Ctrl', can lead to trouble. Think of the shortcuts related to the toolbar, like show Edges, Axes, they use 'Ctrl'+'some number' key as a shortcut. We can't allow the user to remove that Ctrl modifier, as qscintilla will override, and instead of action triggering, that number would be typed in the editor. The same thing will happen if, user modify the shortcut by changing 'Ctrl' to 'Shift', as 'Shift' is occupied for special symbols. So, I think, the main modifier in Key-Sequence, here 'Ctrl' should remain fix and the user should be able to modify the second option in Key-Sequence. Any view on this?
We may need some sort of validation, e.g. also to prevent setting duplicate values and such. But in general we probably want users to be able to set combinations of modifier characters.
Well, I think most of the programs I use allow the use of modifiers for the key bindings. Ranger, alacritty, moc,... Even most GUI/mouse programs offer this freedom. I think itâs a pretty basic feature.
If the user overrides some combination like âčCTRLâș-a, well, then he probably wants to do exactly that and is fine with not having his complete code selected. Most people asking for this feature will anyway come from the VIM mindset and not use the editor at all. Personally, I would prefer to use single letters (h, j, k, l, u, i,...) for navigating (rotating, zooming) the main view. But people are different and with having this freely configurable, you have the VIM/Tiling WM people happy as well as the mouse guys who just want something like âčCTRLâș-âčcursor-keyâș to quickly rotate the view while editing in the OpenSCAD editor.
A validation â IMO â is not really necessary. Last definition wins. Most programs do it like this. Of course one has to check the dotfile for valid syntax. :)
I think what is missing maybe, is a separation of shortcuts depending on widget focus, such as whether the mouse is hovered over text editor or 3d view (or console). Or in a more strict version, which one it has clicked in last.
Also some shortcuts should probably remain global to the overall window like F5, F6, etc.
Single letters would obviously be interpreted as text input by the text editor. Similarly arrow keys would move the text cursor. If there was code to enable/disable different groups of shortcuts depending on focus, then that would be the ideal way to enable such 3d navigation shortcuts without interfering with text editor operation.
Yes, that would be one option, but I think it also has some downsides to use those âper-widgetâ hot-keys. For a user who works with the inbuilt editor, changing the focus each time he wants to inspect a change is maybe unnecessarily clumsy. Also, OpenSCAD doesnât use a focus at the moment: Rotating the view with the mouse leaves the editor focused and active. So, this solution would even require changes of the existing interface. And: If the focus is not clearly visible, users always have to look twice to check where their âkey commandâ is sent to.
As an alternative, just check input events when they enter. If they are a global shortcut, âconsumeâ them. If not, delegate them further to the GUI framework so that the focused widget can do whatever is its standard behavior. Most GUI frameworks provide such a event hook, I guess. Furthermore, I assume that this is much easier to implement, less bug-prone, intuitive for the user and fulfills the purpose perfectly.
In the end, the solution must provide a comfortable way to use OpenSCAD as a viewer without touching the mouse. So if you go for for a âcheck focusâ solution, it should be possible to quickly put the focus wherever the user wants it, without TAB panic and without using the mouse. The focus solution feels somehow cumbersome for me. I would go for a simple and straight âglobal keyâ solution. If I â as a user â assign a single letter to an action, then I can live with the result. If I recognize that it was a bad choice for me, I change it back.
Most helpful comment
Yes, this is the one feature I'm waiting for! It would make the work so much more comfortable.
I think, reading some "hot keys" from a text file would be sufficient and easy to implement for somebody who is familiar with the code. I would even prefer a file based configuration over a "hot key dialog". Key bindings should allow to also use modifiers, especially âčCtrlâș. Such key bindings should work globally, no matter where the GUI focus is currently located.
I â and I think many others â don't use the editor, but only the viewer and the console. So, vim modes are not really necessary. Only the "scene navigation" for the 3D model and showing/hiding, scrolling and maybe resizing the console would be sufficient (and a huge enhancement). Also remapping of the existing hot keys (rendering, STL export...) is of course highly desirable.