Fix overlapping regions in the track properties editor #1366
Conversation
…his has been used in the past as band-aid for aligning the field in the grid layout, it did not prevent fields from overlapping when resizing the widget though.
…label some points down. This label is aligned to the top, and was displayed a little off vertically from the multi-line text field next to it.
… editable fields get as much space as possible, while the right part of the grid (cover image) is resizable on a smaller scale.
…d to ``Ignore``. This is the only way i found to NOT have the fields above overlap on resize. Add a minimal size, approx. 2 lines of text. This should be enough even for long file name/file path. Make sure the field stretches on resize too.
…er to the right when resizing. Previously it was centered to the then fixed text fields below.
…tim from the option in the beat detection preferences, so the Transifex translation memory can pick up and auto-fill the string if available in the respective language.
…alphabetically. Buttons should get focus too when tabbing, but this does apparently not work (macOS).
|
Than you for adopting this. It is better now, but there are some remaining issues. See:
|
|
👍 I tried this once, but then gave up very soon ;) I also noticed that the label on buttons is still truncated. But we need to rethink those buttons anyway and the text length depends on the display language. We could split them into 2 groups and avoid redundant text: Track Metadata: [Get from MusicBrainz] [Reload from File] | [Open in File Browser] I further noticed that the alignment of the cover image could be improved (Fedora, Gnome, Fonts 11 pt, Scaling 1.00). The appearance is very similar to the screenshot that Daniel posted.
|
… in the ``Summary`` tab is not compressed when resizing the widget.
…in the library table.
|
Thanks for testing, i committed a possible fix for the button/row resizing issues. How would you expect the cover to align when resizing? Pinned to the right (current), centered above, neither of the two? Re: last screenshoot I have no solution yet for the magic margin of the |
|
Cover image: Centered inside its bounding box, using as much of the available space as possible. Currently their seems to be a spacer at the top that is also limiting further horizontal scaling by preserving the aspect ratio. |
|
The name 'year' for this field has historical reasons. It may contain year, year + month, date, date + time (ISO-8601). I agree, it is annoying to see only minutes and seconds or the instead of the year ;) Maybe we could change the alignment from right to left bound? Never thought about this. |
|
Thanks for the comments, here´s what´s cooking:
Comments? |
|
There is a bug in AnalyzerKey, m_bPreferencesReanalyzeEnabled is not read from the settings. Analysis results are ignored unless you reset the key manually to an empty string. |
|
@esbrandt Did you forget to push? The branch has not been updated. |
* Editable, and non-editable fields moved into a separate Groupbox. * Wider right column in the ``Details`` groupbox. Allows more characters in the ``year`` field. * ``Cover`` centered when resizing the modal window. Fixed size cover here, otherwise it will throw off the rows in the grid. * ``Location`` is now a label. Previous it was a plaintextedit, and gave some issues with margins and alignments. * Only 2 columns for the ``File`` groupbox, makes easier to read. No more mixed font weights. * Move action buttons into the related groupboxes.
|
…ue, where the cover box did not align to the top of the gridlayout. The cover takes as much horizontal space as allowed by the input fields next to it. It preserves aspect ratio when scaling vertically.
…xed usage for labels in other parts of the preferences, which will be cleaned up in a later PR. Our translation memory will take of the translation automatically, since we use the strings (- colon) already for the track table headers.
… allowed to resize to zero. This was no issue on macOS, but at least on Linux with Gnome.
|
Please test again, hopefully the covers alignment, and the resize issue are fixed. Re: Wasted space between groupboxes. We use the same kind of groupbox layout in other parts of the preferences ( e.g. live broadcasting). Gnome ( i guess thats whats in the screenshot) decided to display groupboxes flat, even if the are supposed to be decorated (see macOS screenshot). |
|
Fixed
Minor Issues
Wishlist
|
👍
Looks like a platform specific issue. Tabbing does not work for buttons at all on macOS. I can only tab between the editable fields. In the code, the tab order went from
Fixed for the summary tab. Still different with the other tabs, requires re-grouping of buttons in the
The groupboxes use the default values here, touching them would mean to me changing them in all other pages they occur, basically all over the preferences pages.
Platform specific issue again,fine on macOS. We could use some feedback from windows, and decide. The cover label is drawn to a horizontal box which sits inside a widget, which both apply margins eventually. Is there a need for the extra groupbox? Could use some help with this.
There is a horizontal line because this gives some kind of separation for groups of items, that are NOT grouped into Groupboxes. Again we face the platform specific issues mentioned before, adding a horizontal line here would feel awkward with other OS. |
|
Tab order now works as expected. Platform-specific layout issues can be figured out later. Upgrading to Qt 5 will change things anyway. 👍 LGTM. I vote for merging this PR, although I haven't tested it on Windows. |
|
This is the minimum size Windows 10 Version: LGTM Thank you. |
See https://bugs.launchpad.net/mixxx/+bug/1708910. Fixed some other quirks as well.
Screen shoot shows the fixed track editor (resized to HMinimum) on MacOS, please test on other OS as well
After:
