Too short space for "Note Lock"

[anytizer]

The width of note lock dropdown list is small, and hence full text is hiding.

[Monospace-V]

All the boxes have this issue.

Since we don't know the possible length of a user-added scale's name, for instance, we cannot increase it to the fixed length of the longest item in the list (in this case, Minor Pentatonic).
I'm not sure if changing size as per item selected is a good idea, since scrolling over one will then have an ugly effect.

[anytizer]

I tried with some new width values to get the attached images.

Length of	Old	New	in PianoRoll.cpp
Quantization	64	85	lmms/src/gui/editors/PianoRoll.cpp Line 4902 in 507fa23 m_quantizeComboBox->setFixedSize( 64, ComboBox::DEFAULT_HEIGHT );
Note Length	105	105	lmms/src/gui/editors/PianoRoll.cpp Line 4911 in 507fa23 m_noteLenComboBox->setFixedSize( 105, ComboBox::DEFAULT_HEIGHT );
Key	72	72	lmms/src/gui/editors/PianoRoll.cpp Line 4917 in 507fa23 m_keyComboBox->setFixedSize(72, ComboBox::DEFAULT_HEIGHT);
Scale	105	155	lmms/src/gui/editors/PianoRoll.cpp Line 4926 in 507fa23 m_scaleComboBox->setFixedSize( 105, ComboBox::DEFAULT_HEIGHT );
Chord	105	125	lmms/src/gui/editors/PianoRoll.cpp Line 4935 in 507fa23 m_chordComboBox->setFixedSize( 105, ComboBox::DEFAULT_HEIGHT );
Snap Mode	105	96	lmms/src/gui/editors/PianoRoll.cpp Line 4944 in 507fa23 m_snapComboBox->setFixedSize(105, ComboBox::DEFAULT_HEIGHT);

Defaults (max lengths selected):

And,

[Monospace-V]

Again, setting a fixed length may not work. The user can add their own scales, can they not? These can be of any length. Perhaps would be better to show full word on hover?

[zonkmachine]

Again, setting a fixed length may not work. The user can add their own scales, can they not?

Is there a way to add your own scales without editing the source code? I don't know, but that doesn't mean we can't tweak the default values and the ones suggested above look better than before. The scale names aren't translated so that's what it will look like right there.

[Veratil]

Is there a way to add your own scales without editing the source code?

No, but I did throw out a PR with a way to define some. It needs some much better work though, and proper integration into lmms rather than an external file.

[Rossmaxx]

@anytizer if you are still around, would you consider opening a PR? Or if you can't, I'll open on your behalf.

[michaelgregorius]

Again, setting a fixed length may not work. The user can add their own scales, can they not? These can be of any length. Perhaps would be better to show full word on hover?

IMO the solution is to get rid of the custom LMMS combo boxes in most contexts and to use styled QComboBox instances instead. QComboBox already knows how to "behave" in most situations while the LMMS combo box does not.

Most of the combo boxes shown above can also be automated which does not make any sense either.

[anytizer]

@Rossmaxx These numbers (widths of combo boxes) were intended for 1k resolution screen. Other sizes may cause us to vary those widths. Yes, I would suggest, at least let us change these values for now to make the default appearance better.

Regarding automations, and changes to new combo box instances, can we still do that after correcting the existing values? We might also need a way to reject automations in these dropdowns. @michaelgregorius.

[michaelgregorius]

@Rossmaxx These numbers (widths of combo boxes) were intended for 1k resolution screen. Other sizes may cause us to vary those widths. Yes, I would suggest, at least let us change these values for now to make the default appearance better.

Starting with pull request #7185 the combo boxes use pixel sized fonts again. Therefore the corrections should also look identical on other screen sizes, assuming that global scaling is used by the users.

Regarding automations, and changes to new combo box instances, can we still do that after correcting the existing values? We might also need a way to reject automations in these dropdowns. @michaelgregorius.

Sure, this can also be done later. I guess one approach would be to implement something like an LmmsComboBox (or however it should be called) which inherits from QComboBox and that knows how to deal with instances of ComboBoxModel. This combo box would simply not implement any automation abilities (or alternatively make them optional/configurable).

[zonkmachine]

Yes, I would suggest, at least let us change these values for now to make the default appearance better.

@anytizer Can you open a PR with the suggested changes?

[michaelgregorius]

I have a branch called "LmmsComboBox" that introduces a combo box that inherits from QComboBox and that knows how to deal with ComboBoxModel. It can be found here: https://github.com/michaelgregorius/lmms/tree/LmmsComboBox.

For more infos and screenshots see here: #7215 (comment)

[anytizer]

@zonkmachine I have sent a pr to @michaelgregorius 's branch for a test, before affecting the gui in master.

[michaelgregorius]

@anytizer, it would be better to issue a pull request against the main repository. The "LmmsComboBox" branch is for a new implementation of the combo box which might behave differently than the current one.