-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better Interface: Infinite zoomable and panable Workspace #6266
Comments
Might I suggest changing the title to something more specific like "Infinite interface"? |
I don't know how Carla's patchbay viewer panel works but you can just zoom out to see everything. Here is how blenders node editor works: https://www.youtube.com/watch?v=5GjHpFYU-cU |
Most all of our editors would quickly become unusable when zoomed out, and unnecessarily large when zooming in. They have no inputs or outputs to connect either, so I really don't see any benefit to the infinite-canvas approach (which we in fact already have, just with no zoom). Copping Blender's split/merge/resizeable UI concept is something I agree with, but there are several other issues thqt could be edited to include that (#1911, #3152, #5078) |
"Most all of our editors would quickly become unusable when zoomed out, and unnecessarily large when zooming in." That makes no sense. You keep the zoom that you can work with, there is no zoomed out too much or zoomed in too much. Zoomed out too much would be the overview and zoomed in too much a maximized window. If a user wants to zoom in on one button why not it's their choice but most will keep the zoom to what they can work with. Contrary to that atm depending on the monitor the windows are either too large or too small in lmms. When too large they take up space unnecessarily and when too small the windows are hard to use. The zoom would allow users to adjust the size quickly to their monitor. With that infinite space one could have all windows open have an overview when zoomed out, select a window and then press a focus or maximize button to work with that specific window. Or just pan around to get to the different windows, the panning is esp. good with large 4 or 8k monitors that have a lot of desktop space. Alternatively a slim list of windows like the song editor could be used that is outside the workspace to focus on the different windows. If the windows then are placed adjacent instead of on top of each other. One could use the mouse wheel to scroll through the list (active list element would be focused on) or click on a name to focus or pan with middle mouse button. That would not fix the window size issue but would make the lmms workspace already much more usable. |
Your mockup appears to show the entire editor being scaled. If you want to zoom the contents of the editor, this is already available everywhere where it makes sense (automation editor, song editor, piano roll). If your complaint is that fixed UI elements like toolbars are the wrong size then this should be solved by fixing our resolution scaling, not by making users zoom in and out.
Which should be done via LMMS properly handling the OS's scale factor, and if finer adjustments are necessary via settings. Scale factor should be set-and-forget, if someone needs change it often enough to justify a dedicated zoom control then something is terribly wrong and that should be fixed at the source.
Your proposal doesn't seem to mitigate this, considering it features multiple movable windows. The single-window interface does and would work very well in tandem with blender-esque resizeable views.
I'm not sure how this is more convenient than selecting windows from a dropdown or toolbar, and I've never seen it implemented in any software.
Again, not sure why navigating in space would be better than navigating via menus. What problem does this interface design solve that wouldn't be solved by the single-window proposal with proper DPI scaling? If we're going to use a brand new design it needs a compelling benefit over existing tried-and-tested proposals. |
It's a flexible workflow vs a rigid one. |
@BrahRah I don't think you realize the immense amount of work that this would require to implement. The dynamic zoom is not supported by our current UI framework, and we'd basically need to rewrite everything from scratch. There are already many ideas of a total redesign of LMMS' inteface. One quite popular suggestion is single window mode. But it's still a long way to go. Your design reminds me of gnome shell. It's not a bad idea. Just a momentous task. In the end of the day the issue here seems to be about high DPI scaling. Adding a setting for that should be fairly simple, and it wouldn't require a complete remake. |
That is why I suggested to leave the zoom out first but add the panning. Together with the DPI scaling that should already improve lmms. Single window is just maximized workspace windows. For that a user just needs a list that is outside the workspace. That is quickly implemented and the current workspace doesn't even need to be removed to add that. My suggestion would be to make the current ui more efficient to get more users to use lmms. That will also increase potential developers and funds. |
But that would also work with an infinite workspace and panning. You are right lets just leave the zoom out then but keep the infinite workspace. Let me summarize with the changes:
I'm gonna add this to the main post. Did I miss anything or is there something to add? |
Definitely not a bad idea, but I don't if LMMS is still following that direction, but if so, it wouldn't fit well with the new single window UI that was planned as it's a completely different approach in making the UI better. To b e fair there's no daw that still deals with floating windows (ok, FL Studio does, but has magnetic windows, and also people don't drag windows like hell in it i think) so i still think we should move over that. That said i know a lot of the fanbase still likes the floating windows UI, so i guess the choice is up to the devs or such. |
I'm against removing the canvas workspace lmms already has. Improve it instead I've given many suggestions on how that can be done. #1911 would make lmms just a live clone. |
#3532 combined with linux gives you dual monitor and workspaces |
The singe window approach is discussed for 7 years now. Which steps are done forward to this? |
A lot of discussions with ideas and few PR's splitting Core and UI in some lmms editors and functions. |
I've made a better concept: #6272
Enhancement Summary
I've posted this already in the discord lmms channel where it was so good the whole conversation got deleted :
Make the workspace into an unlimited canvas like blenders node workspace. It resizes already so just make it bigger, add in panning and zooming. Then add screen regions where one can choose to add different components, either another canvas, tool or sidebar. Those regions would allow the use of multiple monitors! A small monitor could be for fixed elements and a big 4k monitor could be split up in multiple canvas workspaces. It would also allow moving the different workspace elements to other sides of the screen for a better individual workflow.
Justification
Lmms reminds me of blender 2.7 very powerful but hard to use. It is rigid, slow to work with and the workspace is messy.
That simple change would declutter lmms and make faster and easier to use. It would also place lmms on the track to industry standard like blender.
Mockup
-Red lines are the regions.
New concept after discussing it:
Just snapping workspace windows to each other without overlap would already work. We could let users overlap windows but they would have to uncheck a checkbox to disable the snapping. Kind of like blenders snap to grid/object.
Then if the user can choose to keep something in the workspace or move it outside to be fixed to the "screen" there could be lists/dropdowns/toolbars used to navigate the inf. workspace or maximized inf. workspace windows. This would be better then clicking on the song editor that is inside the workspace.
The text was updated successfully, but these errors were encountered: