LMMS
Make Resizing Tracks more Natural
In this PR, I reworked the resizing functionality for TrackViews to make it more intuitive for users, and I added the ability to horizontally resize a track.
Previously, in order to change the height of a track, the user would have to mouse over it, hold shift, and drag down. This is quite unintuitive, and I only learned how to do it after being told how. New users most likely do not know this feature exists.
Instead, it would be much more natural if the user could mouse over the edge of a track, and the cursor would change to a vertical arrow, indicating that the user can resize it, and then just drag down to change the height.
Additionally, if we allow the user to change the height of a track, it makes sense to let them change the width as well.
So why don't we do that? :D
https://github.com/user-attachments/assets/f052d18c-6eb0-4dab-b36a-40c785d41de5
Also, since compact track buttons are not as relevant after this PR, I have removed much of the code for them. If a user has compact track buttons enabled, the track width will start out at the minimum to replicate how it looked previously. But the user can resize the tracks at any time to be as wide as they please.
Similarly to how track height is saved in the project, the track width is also saved.
Changes
- Added gui functionality to
TrackViewto let users resize via the mouse. Basically checking the position of the mouse relative to the edge, changing the action state, changing the cursor, and handling the drag events. - Removed the hardcoded
m_trackHeadWidthfrom the Song Editor and Pattern Editor, and moved it intoTrackContainerView, along with getter and setter functions. Also upgraded all relevant functions to use the dynamic width. - Reworked/partially removed compact track label functionality. Instead of storing hardcoded widths for the size of each part of the track, everything is calculated on the fly, with only the default and minimum widths stored as constants in
TrackView.h - Upgraded PatternTracks and AutomationTracks to use Layouts instead of hardcoded pixel values.
- When the user resizes a track to be less than the old compact track width, the mixer channel number will disappear to allow the user to make it even more compact.
I'm more interested in why your CPU is through the roof honestly..Off topic so we can discuss it elsewhere if needed.
If possible, I suggest you add the option to remove the mixer display from tracks, or have them automatically removed when the tracks are compacted. It doesn't make sense to compact the tracks and have these displays remain visible as they take up a lot of space on the tracks.
Sure! I've changed it so that the mixer channel lcd hides itself when you resize it to be smaller than the default compact track size.
https://github.com/user-attachments/assets/5354c48f-d5d2-4235-8fd7-c8686c986f26
One thing I noticed, we're using a hardcoded image as the background for the track label button, which tiles as you expand the tracks.
I tried seeing how it looked just by removing the image, and it seems to look about as good? It is a bit more flat, maybe I could change the css to use a gradient. Or maybe that's fine?
Works great, I just think the threshold to hide the track number should be a little wider than it is right now
Wider as in, you don't have to squish the tracks as much before it disappears?
The way I have it currently, if users previously had compact track buttons enabled, the tracks will default out to that size, with the mixer number shown, since that's how it works in master. It's only if you resize it to be smaller than that where the lcd will disappear.
If we change the threshold to be larger, it would mean that users with compact tracks will now have to resize the tracks to see the mixer number. Are we okay with that?
If we change the threshold to be larger, it would mean that users with compact tracks will now have to resize the tracks to see the mixer number. Are we okay with that?
Hm, that complicates it a bit. One option is to just always show the LCD no matter what, when compact is enabled, and only change this behaviour for compact mode.
Another option is to just lock the width when compact mode is enabled.
The best option, in my opinion, is to add back the context menu to change and create mixer tracks from track settings.
This might be getting out of scope for this PR though, so it may be best to just leave it as it is for now.
Tested again, works great.
When hovering over the corner of a track boundary as shown, the vertical scaling seems to take priority over the horizontal, whereas I think it would make more sense for the horizontal scaling to be initiated when hovering at any point of the right side of the track boundaries. Not sure how complicated this is to change though, and it's quite a small issue.
edit: forgot to attatch the image 🤦
I reordered the if statments, so hopefully horizontal resizing is given priority now. I haven't tested it since I don't have time though :sweat_smile:
Works great! I'm starting to feel like the handle size (I apologize if that's the incorrect term) is a bit small which makes it a bit finicky, but increasing that would probably require increasing the padding size of the track labels. If you don't want to do that here, then I'd say this PR is ready for merge.
I made some minor bugfixes with how the cursor was showing up, but it should be good to go now.
I'm starting to feel like the handle size (I apologize if that's the incorrect term) is a bit small which makes it a bit finicky, but increasing that would probably require increasing the padding size of the track labels.
Yeah, unfortunately the track label buttons are quite large, and getting the cursor to change to resize when over them would be a bit tricky. However, the actual handle size is greater than it appears (6 pixels)--even if the mouse is slightly over the button, you can still drag down and the track will resize.
I've updated some code to make the pattern editor track resizing work with the new pattern editor timeline.
