Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the minimum width of the B&B editor #2808

Merged
merged 1 commit into from Jul 5, 2016
Merged

Conversation

@Umcaruje
Copy link
Member

Umcaruje commented May 31, 2016

Adresses #2636 (comment)

Before:
screenshot from 2016-06-01 00 43 06

After:
screenshot from 2016-06-01 00 41 38

@RebeccaDeField
Copy link
Contributor

RebeccaDeField commented Jun 1, 2016

Perfect, thank you!

@IvanMaldonado
Copy link
Contributor

IvanMaldonado commented Jun 1, 2016

What happens when you add more steps?

@tresf
Copy link
Member

tresf commented Jun 1, 2016

Changing the default width for better sane defaults/cosmetic reasons versus changing the minimum width are two separate things. As long as we allow shorter step counts, shouldn't we allow smaller window sizes?

Edit: Looking at the code suggest this may be somewhat based on step size already. If that's the case, great.

@RebeccaDeField
Copy link
Contributor

RebeccaDeField commented Jun 1, 2016

@tresf I see what you are saying. I thought that making a minimum size would help with having just one less variable that made the BBeditor pixelated, but if it causes usability issues, then just making it default to the right size, while still allowing people to scale the window down could be a great solution too.

@tresf
Copy link
Member

tresf commented Jul 5, 2016

It's a benign change. We'll get more feedback when RC2 is release and it's easy enough to revert if people complain.

BTW, we're still dealing with magic numbers here... The value of 384 I assume is the width of the other components to the left such as the track label, etc. This WILL be problematic if anything changes size due to a theme, a higher resolution display, etc. The proper fix would be to eliminate the magic number completely.

@tresf tresf merged commit d84263e into LMMS:master Jul 5, 2016
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Umcaruje
Copy link
Member Author

Umcaruje commented Jul 5, 2016

The value of 384 I assume is the width of the other components to the left such as the track label

No, actually those are some hard-coded variables that are taken to account. The 384 is actually the width of a default B&B pattern (16 step pixmaps + the various spacing between them).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.