Bug 347347 - change height of individual tracks
Summary: change height of individual tracks
Status: RESOLVED FIXED
Alias: None
Product: kdenlive
Classification: Applications
Component: User Interface (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-06 22:02 UTC by farid
Modified: 2017-03-04 22:46 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description farid 2015-05-06 22:02:17 UTC
would be great if we could individually change the height of tracks... i find it helpful for editing in sync with a song to have the audio track bigger than the video ones.. 

Reproducible: Always
Comment 1 qubodup 2015-11-09 21:59:53 UTC
I can confirm the lack of this feature in current git.

By comparison, Audacity allows resizing the tracks vertically.

This video demonstrates the feature in Audacity & the lack of it in Kdenlive:
https://youtu.be/3CYvThe0YRg

In comparison to others: Adobe Premiere Pro 9.0 allows this by dragging top borders, mousewheel-scrolling and there is a "scale bar" on the right. Very fancy controls (video:  )
Shotcut, Wondershare Filmora, Avid Media composer and Lightworks seem to not allow it while the following apps allow it:
Premiere Pro 9.0 allows dragging borders, scroll with mousewheel and has an interesting scale-bar on the right side of the timeline to resize all https://youtu.be/OEUrDi8oNMY
Smoke 2016 allows dragging borders and has +/- buttons to resize all https://youtu.be/SOkf4ntzORY
Final Cut Pro X 10.2.2 allows changing the look (thumbnail-audioimage ratio in videos) with different style icons and has a slider for the size of all tracks https://youtu.be/3_ZRix_RHRw

Personally I would benefit from being able to see the audio better as well. I especially like the idea of the video thumbs not disturbing the audio without having to disable them and would prefer them smaller.

Should this be implemented at some point:
1. Controlling the size should probably be made possible by dragging the top and/or bottom borders of the info area of tracks (left) and not by dragging the space between tracks (right), as this would probably cause accidental changes and frustration about the cursor changing while moving in the timeline.
2. Adobe's scale bar method seems uncommon and might be hard to implement with good feeling. Either or both +/- and slider solutions might be a good method for controlling all tracks at once.
3. Adobe's mousewheel-over-track-info-area method would be useful for quick changes but it would probably be hard to not have all the interfaces in that area (buttons, name field) interfere with this control.
Comment 2 A. Berkl 2015-11-18 23:26:22 UTC
Another thought, just slightly different: I sometimes wish I could collapse/minimize a track completely i.e. a "watermark-track" which is always "hot" but does not require permanent attention and thus only wasting valuable vertical space.
Comment 3 Wegwerf 2016-07-13 20:34:23 UTC
Be very cautious when it comes to company-specific fancy Ui controls. There may be IP on it, and I'm not talking about the Internet Protocol. Round corners, anyone?
Comment 4 Wegwerf 2016-10-22 15:17:46 UTC
If this is low hanging fruit then I will be absolutely positively surprised. This will need refactoring of a lot of code that today assumes that all tracks have the same height. A quick glance some time ago showed me that this needs to touch a lot of code, but it would surely worth the work. What needs to be done is to factor our any scattered code that works in the timeline using the scene coordinates, especially Y axis, and then unify this through two functions, such as getTrackTopY(t) and getTrackBottomY(t). The main work is to find all the places where need to use these new functions, and this includes all timeline operations.
Comment 5 farid 2016-10-22 15:28:25 UTC
Wegwerf, thanks for the input. This would be then a mid complexity bug that hopefully someone can give some love. Do you think we can keep it flagged as is?
Comment 6 alcinos 2016-10-22 17:21:07 UTC
I've taken a look as well, and I agree with Wegwerf to say that this is probably *not* low hanging. It would probably require some refactoring, and significant rewrites.
Comment 7 farid 2016-10-22 17:27:13 UTC
OK, removing flag.
Comment 8 farid 2017-03-04 22:46:58 UTC
To be done after refactoring, closing.