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

feat: add type toggle to cue popup #13215

Merged
merged 11 commits into from
May 23, 2024
Merged

Conversation

acolombier
Copy link
Contributor

This adds the ability to changes the cue type without having to reset it. It also allow updating the saved loop end using the beatloop size.

I would like to also allow right-click on the button to set the end loop to the current play position to allow more granular control, and prepare the field for saved beatjump. Any component I can use or should I make a custom QPushButton?

Kooha-2024-05-06-14-54-24.mp4

This is a dependency for #13161

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a minor comment. The rest looks good.

src/widget/wcuemenupopup.h Show resolved Hide resolved
@acolombier acolombier mentioned this pull request May 6, 2024
@acolombier acolombier marked this pull request as ready for review May 6, 2024 21:15
@acolombier acolombier requested a review from daschuer May 6, 2024 21:37
Copy link
Member

@ronso0 ronso0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this, much appreciated!

I've lef some comments.

src/widget/wcolorpicker.cpp Show resolved Hide resolved
src/widget/wcuemenupopup.cpp Outdated Show resolved Hide resolved
@ronso0
Copy link
Member

ronso0 commented May 7, 2024

Please also add some styling for Deere.

@Swiftb0y
Copy link
Member

Swiftb0y commented May 7, 2024

When I just toggle a loop cue's type accidentally, the loop size changes, right? Seems like sub optimal UX.

@acolombier
Copy link
Contributor Author

Please also add some styling for Deere.

Done

When I just toggle a loop cue's type accidentally, the loop size changes, right? Seems like sub optimal UX.

Done

@daschuer
Copy link
Member

daschuer commented May 8, 2024

@ronso0 and @Swiftb0y, It this ready to merge now?

Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have the time to test this myself right now. Can you double check that the loopsize still doesn't change when toggling the type and the loop is not aligned to a beat. For example when a user sets up a loop with the in-out buttons (while having quantize disabled) and then assigns a hotcue to that loop.

Copy link
Member

@ronso0 ronso0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some remarks.

Shall we also change the cue color when changing the type?
if (type == loop && color == defaultLoopCueColor) { cue->setColor(defaultHotcueColor }
and vice versa for hotcue -> loopcue.

src/widget/wcuemenupopup.cpp Outdated Show resolved Hide resolved
src/widget/wcuemenupopup.cpp Outdated Show resolved Hide resolved
@ronso0
Copy link
Member

ronso0 commented May 11, 2024

I also have a commit (almost) ready to fix the 'active' icon. For some reason qproperty-icon: url(..); does not style the checked state, but image: .. works (though doesn't allow size adjustments like with the qproperty).

edit: yeah, qproperty-icon is evauated only once, so it can't be used for different state icons.
https://doc.qt.io/qt-6/stylesheet-syntax.html#setting-qobject-properties

I'll share that as soon as I find time next days.

src/widget/wcuemenupopup.cpp Outdated Show resolved Hide resolved
@ronso0
Copy link
Member

ronso0 commented May 11, 2024

This is the button style commit
2af95df

@acolombier
Copy link
Contributor Author

acolombier commented May 11, 2024

Shall we also change the cue color when changing the type?

Good question. I would suggest we don't, but I guess we could change it if the current color matches the current cue type as you suggested, before change? What do you think?

@ronso0
Copy link
Member

ronso0 commented May 11, 2024

Shall we also change the cue color when changing the type?

Good question. I would suggest we don't, but I guess we could change it if the current color matches the current cue type as you suggested, before change? What do you think?

Yup, that's what I meant.
Related code we can adopt is here

if (cueType == mixxx::CueType::Loop) {
ConfigKey autoLoopColorsKey("[Controls]", "auto_loop_colors");
if (getConfig()->getValue(autoLoopColorsKey, false)) {
color = m_colorPaletteSettings.getHotcueColorPalette().colorForHotcueIndex(hotcueIndex);
} else {
color = colorFromConfig(ConfigKey("[Controls]", "LoopDefaultColorIndex"));
}
} else {
ConfigKey autoHotcueColorsKey("[Controls]", "auto_hotcue_colors");
if (getConfig()->getValue(autoHotcueColorsKey, false)) {
color = m_colorPaletteSettings.getHotcueColorPalette().colorForHotcueIndex(hotcueIndex);
} else {
color = colorFromConfig(ConfigKey("[Controls]", "HotcueDefaultColorIndex"));
}
}

src/widget/wcuemenupopup.h Outdated Show resolved Hide resolved
@ronso0
Copy link
Member

ronso0 commented May 11, 2024

Can we remove the obsolete cue end position after switching from loop -> hotcue when closing the menu?

It just feel weird to be left with hotcues that have an end position.

@ronso0
Copy link
Member

ronso0 commented May 11, 2024

Can you double check that the loopsize still doesn't change when toggling the type and the loop is not aligned to a beat. For example when a user sets up a loop with the in-out buttons (while having quantize disabled) and then assigns a hotcue to that loop.

This is taken care of.
The only way to screw up a loop is

  • have a loop cue
  • left-click loop cue button
  • Whoopsy!
  • right-click loop cue button

@acolombier
Copy link
Contributor Author

Can we remove the obsolete cue end position after switching from loop -> hotcue when closing the menu?

Yes, that was fixed in the follow up PR (the saved jump). Going to fix that one instead.

Can you double check that the loopsize still doesn't change when toggling the type and the loop is not aligned to a beat. For example when a user sets up a loop with the in-out buttons (while having quantize disabled) and then assigns a hotcue to that loop.

This is taken care of. The only way to screw up a loop is

* have a loop cue

* **left**-click loop cue button

* _Whoopsy!_

* **right**-click loop cue button

This would require to implement an history of cue modification and I'm not going to do this here. If this a deal breaker, happy to close the PR.

@ronso0
Copy link
Member

ronso0 commented May 12, 2024

This would require to implement an history of cue modification and I'm not going to do this here. If this a deal breaker, happy to close the PR.

I wanted to point out that this is unlikely to happen by accident, and definitely not blocking this.

@acolombier
Copy link
Contributor Author

Ah, I see. I thought you meant there was a missing edge case - I think we slightly lost in translation :)

I think all comments should have been addressed now.

@ronso0 ronso0 self-requested a review May 12, 2024 23:08
Copy link
Member

@ronso0 ronso0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM nox, thank you!

@ronso0
Copy link
Member

ronso0 commented May 12, 2024

@daschuer wanna take a look?

@acolombier
Copy link
Contributor Author

Looks like @daschuer already approved - merge?

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During testing I had the situation that the cue type toggle button was lit, but the cue button in the skin did not change the state to loop. Unfortunately I was not able to reproduce the issue.

At least we should make sure the toogle button state is corrected when changing the cue type fails for some reason.

Comment on lines 58 to 66
tr("Toggle this cue type between normal cue and saved loop, using "
"the current beatloop size or the current play position") +
"\n\n" +
tr("Left-click: Toggle between normal cue and saved loop, using"
"the current beatloop size as the loop size") +
"\n" +
tr("Right-click: If the current play position is after the cue,"
"set that position as loop end and make the cue a saved loop "
"if not"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
tr("Toggle this cue type between normal cue and saved loop, using "
"the current beatloop size or the current play position") +
"\n\n" +
tr("Left-click: Toggle between normal cue and saved loop, using"
"the current beatloop size as the loop size") +
"\n" +
tr("Right-click: If the current play position is after the cue,"
"set that position as loop end and make the cue a saved loop "
"if not"));
tr("Toggle this cue type between normal cue and saved loop")
"\n\n" +
tr("Left-click: Use the old size or the current beatloop size as the loop size") +
"\n" +
tr("Right-click: Use the current play position as loop end if it is after the cue);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if keeping the old loop size is the intended behaviour, because it is invisible, when the cue is an normal cue. We loose the "feature" to adjust the beatloops size of a saved loop by this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was requested by @Swiftb0y
Since you can change the loop size with right-click, I guess it is okay.
Perhaps I could also make double-click to change the loop size with the beatloops size value?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I could also make double-click

I suggest to keep it simple.
The purpose of this button is to quickly change the type, with two loop options.
Adjusting saved loops should better be done with the looping controls IMO.

Adjusting the right-click behaviour might work:

  • if before cue: reject
  • if at cue: use beatloop size NEW
  • if after cue: use play pos

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should be the behaviour. Also with your commit, the end pos is now removed after popup close so the left button may use the beatloop size again on next attempt

Copy link
Member

@Swiftb0y Swiftb0y May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to keep it simple.

I also think thata important. if the functionality for retaining the previous size results in code that is too complicated, we should ensure the code remains understandable. In the worst case, the user accidentally clicks the wrong button (that is not easy to access in the first place) and they learn that it changes the length the hard way.

I'm sorry for being so indecisive on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem. Could you please have a look with the current solution? It will allow to quickly revert the saved loop, and will "clean" the dangling end position when the popup is closed, thanks to @ronso0's work. I think the code remain quite simple, so hopefully we have a good trade-off between usability and code simplicity.

src/widget/wcuemenupopup.h Outdated Show resolved Hide resolved
@ronso0
Copy link
Member

ronso0 commented May 13, 2024

Can we remove the obsolete cue end position after switching from loop -> hotcue when closing the menu?

It just feel weird to be left with hotcues that have an end position.

49c052d

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works good now. Thank you.

@acolombier
Copy link
Contributor Author

@ronso0 friendly ping, in case you missed the notification!

@ronso0
Copy link
Member

ronso0 commented May 23, 2024

Ouh sorry, thanks for the reminder.

LGTM, thank you very much!

@ronso0 ronso0 merged commit ebd51e1 into mixxxdj:main May 23, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants