SUGGESTION 1: Just curious, do you all think the timeline track titles would look more polished if they were centered by default? (See attached pic in this bug). If so, might I suggest that it be considered to have all track titles in track header centered by default? SUGGESTION 2: There's not much real estate where one can click on the track in the track header area to select the track itself. I noticed that clicking the text field in the track header selects the track, but it also mandates that you edit the text you just clicked on. POSSIBLE SOLUTION: Could it be made for the Track text fields in the track headers to behave like the text fields in the project bin widget? So for example, single-clicking highlights or selects the track, and then double-clicking edits the text? BENEFITS: (1) Seems much more congruent with similar text field behavior. (2) It allows a much easier way to select the track while not looking like the user mistakenly clicked on the text for the purposes of editing it (which wasn't their intention). Reproducible: Always Tested using Kdenlive 15.13.0 - built from git source on 2016.02.09 - on Fedora Linux x64, GNOME 3.18.
Created attachment 97130 [details] Track title text - centered example
Just my two cents... (1) Personally, I'm really glad that track titles are not centered. Maybe they should be justified to the right? No, I don't think so. Locking at many tables I've rarely seen centered row headers (first colum). (2) That is something that makes sense to me. Even with a track header context menu.
Hey Wegwerf, (1) Flowblade (https://raw.githubusercontent.com/jliljebl/flowblade/master/flowblade-trunk/docs/Screenshot-1-4-dark.png), Blender video editor (https://www.packtpub.com/sites/default/files/Article-Images/basic-video-editing-blender-img13.png), Lightworks (http://nofilmschool.com/sites/default/files/styles/article_wide/public/uploads/2012/04/lightworks-trim-screenshot.png?itok=UKmLXo36), Lives (http://www.studiotoolz.net/wp-content/uploads/2012/09/livesmt.png), and other Windows-based video editors all have their timeline track names centered. I've always seen it look more polished -- like they were properly positioned. Just my opinion, though. (2) The sense behind it is to give the user a way to select the desired track in the timeline for use easily, without highlighting the track title text. It doesn't seem appropriate that the user should be forced to select the track title text for editing if all they want to do is select the track itself.
Git commit 6e5729f04dc4f64cfcf5d8c04f0d934feabb1aeb by Jean-Baptiste Mardelle. Committed on 11/02/2016 at 23:41. Pushed by mardelle into branch 'master'. Edit track name on double click only M +5 -0 src/timeline/headertrack.cpp http://commits.kde.org/kdenlive/6e5729f04dc4f64cfcf5d8c04f0d934feabb1aeb
@Jesse, thank you very much for the screenshot ... now I see we are talking about completely different types of track titles: your screenshots show terse track titles, such as v1, v2, etc. However, I was talking about descriptive, meaningful titles, such as "Company Logo", "Title", "Paper", "Screencast", "Presenter", "Voice Over", etc. I see that centering terse titles may look appealing, but if you do that to descriptive titles as I use them throughout my project it looks awful when centered. I have around five to eight, nine tracks in my projects, so I need descriptive titles. And quickly reading centered text doesn't work as well as quickly reading left justified text in western languages. Furthermore, I don't see why gradient effects for track headers should make software appear more polished, in fact, my own impression is that gradients in track titles show lack of professionalism in UI design. But just my own two cents.
Lives actually seem to left justify according to your screenshot.
Wegerf, it's all good. :) Now that you've explained it, I agree, making custom track title text would look better aligned to the left; I'd never really made use of customizing it, I suppose. I take back my suggestion about it. :) Looks like the mousse-click function has been modified in the latest git master build. Thanks JB! Marking this bug as resolved.