LMMS
LMMS redesign concept
(Click to enlarge)
Hi all, My previous work for Zynaddsubfx has same purpose to dock all windows in one (link is dead) ~~http://budislavtvp.deviantart.com/art/ZynAddSubFX-UI-Concept-2014-455890191~~
It is in development phase > https://github.com/fundamental/zyn-ui-two
Link to full concept: ~~http://budislavtvp.deviantart.com/art/LMMS-UI-UX-Design-Concept-Single-Window-523696539~~ ~~https://www.behance.net/gallery/38503021/LMMS-UIUX-Design-Concept-Single-Window-Interface~~ https://www.behance.net/gallery/194917259/LMMS-Redesign-Concept
Full version (mirror): full version
Looks very good, you can add pics right here, maybe just not all for ui and zyn
stunning! ..but i am feeling a chill, cause i have spent ...absurd time learning zyn's current UI sigh :hamster:
For your (awesome!) LMMS-UI-Concept I fear this requires a complete rewrite of LMMS's GUI. How do you handle the windows? (switching in fullscreen per button? dragging the corners for sizing?)
Greetz Bara
For your (awesome!) LMMS-UI-Concept I fear this requires a complete rewrite of LMMS's GUI. How do you handle the windows? (switching in fullscreen per button? dragging the corners for sizing?)
I can't speak on behalf of the author, but most DAWs use a collapse/show method and the designated panes are just reused depending on which widget is shown.
you can add pics right here, maybe just not all for ui and zyn
Done. :)
@budislav,
Very interested to know the possibility of this. When you worked with the Zyn team, how involved with the code were you? Did you have to fork the repository? Did they merge the change into base? Last I checked, Zyn wasn't fully Qt compatible but your library seems to make heavy use of Qt and QML (right?)
Tagging @RebeccaDeField @pgiblock
Much overlap with: #880 #1839
I am just UI/UX designer so I can't help with coding.
:+1:
everything you seen is work by Mark McCurry (fundamental)
Thanks for clarification. Yeah, Mark shows up here occasionally. I'm sure his efforts could probably be extended for LMMS as well.
As far as a singleton window, we likely have thousands of lines to clean-up to make this a possibility, but your mockup is delightful and we're likely to use it as a reference point when discussing major UI changes in the future, thank you! :+1:
@fundamental what type of overhaul are we looking at here if we were to adopt this new UI? I assume we'd have to port over pretty much every single widget, but how extensible is this opengl/QML for other projects?
I'll quote the readme for others interested...
- Custom nanovg (opengl 2.0) based rendering
- Custom constraint based layout
- QML based structure/event handling
Progress
As of so far a whole bunch of widget rendering code has been written. A basic horizontal weighted/constrained pack layout has been created (in C) and two simpler pack algorithms have been made in qml. QML/nanovg integration has been establed and it appears to be relatively bug free (though perhaps somewhat inefficient). Some mouse handling has been done. A variety of other widgets have received their design on paper. To test some UI performance/integration a simple equalizer or envelop app might be created.
"your mockup is delightful and we're likely to use it as a reference point when discussing major UI changes in the future, thank you!"
I am glad to hear that, I hope this would be very helpful. I'm tired of floating windows :)
I'm tired of floating windows :)
Yes, many of us all are. Per #519, #765, #1406
And then there's #387, #1185, #1357, #520, #735, #1755, #1849, #1843
Just worked on a track last night and had to make use of the somewhat hidden Qt feature "Always on top" in the left corner of every sub-window. :+1:
"Just worked on a track last night and had to make use of the somewhat hidden Qt feature "Always on top" in the left corner of every sub-window."
That's what I'm talking about :+1: I will upload one mockup that shows how it looks on full HD res.
That's what I'm talking about :+1:
@budislav P.S., you can use the > to quote a messsage. :)
Let's say I have a dual screen setup. Now I can stretch my LMMS window to cover both screens and place the subwindows where I like. In which way would the proposed concept be an improvement in that case?
@tresf
P.S., you can use the > to quote a messsage. :)
Thanks, didn't know that :)
Thanks, didn't know that :)
Sorry, it has to be the first character in order to work properly. :+1:
dual screen setup
Yeah, I was wondering this as well.... If the other usability improvements happen that is certainly an obstacle I'd like to have. My recommendation (even in our current design) would be to have unlimited container windows. This could get ugly for singleton objects though (which we have some other open items on already).
@softrabbit I've been thinking about dual monitor but there probably should be some options in preferences just for LMMS to know if you want to use second monitor. I need to think about this more.
One solution will be to undock desired section and to move it on second monitor which have container than dock it automatically. Now there should be some kind of pattern for each section. Browser should be docked only to left or right, and instrument and effect rack should be always on bottom, because it have fixed height.
On 03-31, Tres Finocchiaro wrote:
what type of overhaul are we looking at here if we were to adopt this new UI? I assume we'd have to port over pretty much every single widget, but how extensible is this opengl/QML for other projects?
At the moment the goal is to just get this to work for zyn, but I'd imagine other projects could adapt the code. The layout routines seem like they should have no problem working in other qml projects (and IMO QML really should have such algorithms bundled by default).
The draw routines should be easily swapped out, as most of them are contained within draw.{c,h} (it has really driven me nuts how many toolkits make it so hard to restyle things by spreading out the draw code over so much space).
The mouse interactions should be pretty much identical for many of the widgets if they're reused.
The bindings of the widgets to the engine will need to change as once I reach that stage they're going to be 99% OSC message driven with some sort of caching backend.
So, there will be some mismatch, but nothing that would prevent another project from reusing components.
Given the current rate of development, there's likely a year to go before I get the current replacement UI completely functional/somewhat-polished.
About multi-display operation:
@fundamental you mean about a year to replace ZynAddSubFX UI? And then you could start working on LMMS?
@fundamental you mean about a year to replace ZynAddSubFX UI? And then you could start working on LMMS?
He was talking about the readiness of his GUI framework for Zyn which will make a good portion of the mockup possible. He never said he'd integrate it into LMMS, but rather was speaking broadly on behalf of its port-ability to non-Zyn uses (which I specifically asked about) :)
I'm curious how the messaging described as 99% OSC message driven with some sort of caching backend can or cannot be leveraged in LMMS. We use signals and slots for quite a bit of our stuff, but Vesa has expressed concern with it for real-time safety operations. Not sure if this message caching mechanism would help us in that regard or if it is more of a MIDI-type-channel that you are describing (or perhaps room for all the above).
-Tres
Very nice. A complete UI overhaul probably won't be any time soon, but I do prefer single-window functionality and would be very pleased if this was implemented. Good work.
On 03-31, Tres Finocchiaro wrote:
I'm curious how the messaging described as
99% OSC message driven with some sort of caching backend.can or cannot be leveraged. We use signals and slots for quite a bit of our stuff, but Vesa has expressed concern with it for real-time safety operations. Not sure if this message caching mechanism would help us in that regard...
Well, QT pretty much anything is very much unsafe to use anywhere near the realtime side of things. I've been procrastinating making a meta bug on the issue of realtime safety and how to make it an achievable goal within lmms. https://github.com/fundamental/stoat does a fine job at pointing out errors as they occur, but it's virtually impossible to fix any of these issues without some proper documentation detailing the overall architecture and assumptions of the components of lmms. Approximately what I think is essential to this is some sort of architecture level documentation (e.g. something akin to http://fundamental-code.com/tmp/architecture.html )
Some sort of message passing is the norm for effectively creating a realtime safe UI, via LV2 atoms, OSC, parameter ID pairs, strings, etc. Since the UI would still be qt based, using it for signals and slots would be possible, but I don't think it's a good idea for the long term plans of this project.
As per why I care about caching, it's mainly to avoid waiting for parameters when changing views which can be noteworthy in some of the cases with the current fltk UI.
--Mark
Is it possible to easily undecorate QWindows (i.e. remove each window's menu bar) and then have some layout engine that positions them in code? This would allow for an easy way to toggle between a tiled interface and the current windowing interface for multi-screen users. Should also reduce the amount of code affected.
A quick search shows that Qt may support this pretty easily.
@unfa
Seriously, I'm gonna put out some cash for implementing this.
Ever heard of bountysource.com? It's made for exactly that purpose :+1: https://www.bountysource.com/issues/10253686-new-ui-concept-single-window
Ever heard of bountysource.com? It's made for exactly that purpose :+1: https://www.bountysource.com/issues/10253686-new-ui-concept-single-window
Oh yeah, bountysource is awesome!
Should we consider putting bounties on some issues with our donation money? That could lead to a faster development of some features.
I'm supportive of that. It allows.non-devs like me to contribute more than ideas.
On Sun, Apr 5, 2015, 1:45 PM Umcaruje [email protected] wrote:
Ever heard of bountysource.com? It's made for exactly that purpose [image: :+1:] https://www.bountysource.com/issues/10253686-new-ui-concept-single-window
Oh yeah, bountysource is awesome!
Should we consider putting bounties on some issues with our donation money? That could lead to a faster development of some features.
— Reply to this email directly or view it on GitHub https://github.com/LMMS/lmms/issues/1911#issuecomment-89831381.
Our donation money does well to break even with expenses. Please don't misdirect funds to our donation account, leave them for the bounties. Bounties are a much more sensible approach to these bugs (any developer can step in). We lack the organization to make promises with our own funds. We're not prepared to dispurse and organize a large amount of funds, nor are we prepared turn our volunteers into paid devs. Separate bounties can attract new help without putting unnecessary burden on a relatively inexpensive and simple to maintain team. :)
So please pledge against bounties you believe in supporting, but don't think the current team can necessarily allocate more time. These bounties would put a price on a feature that anyone can fulfill (like new help). That idea sounds promising. :)
Sorry for bumping this thread, but this UI looks really amazing! Absolutely can't wait for the release. :)
