Skip to content

Show hotcue info in tool tip#15471

Open
Eve00000 wants to merge 5 commits into
mixxxdj:mainfrom
Eve00000:ShowHotcueInfoInToolTip
Open

Show hotcue info in tool tip#15471
Eve00000 wants to merge 5 commits into
mixxxdj:mainfrom
Eve00000:ShowHotcueInfoInToolTip

Conversation

@Eve00000
Copy link
Copy Markdown
Contributor

@Eve00000 Eve00000 commented Oct 10, 2025

I did not want to hijack @mxmilkiib' PR #15462 / Idea / .... but it was turning in my head around and around so it had to get out.
I'm using the knowledge learned with the genrefeature and rconverting the idea of the genreDao to cueDAO.
At the moment the hotcue-overview is in the title-tooltip, but it can be placed in the tooltip of another (single/plural) field.

As the original idea was to show the # of hotcues, that isn't enough for me, I'd like to have an overview of the hotcues

**Number (presented like the hotcuebutton - position - label - type (duration if type is loop) *

Thank you @ronso0 for the presentation like a hotcuebutton (number & colour).

The only problem I still need to solve is the caching., but I this is a bigger problem.
For searchCrates (and other features) I add an bypassing exception in basesqltablemodel->select, but I'm wondering if we still need the caching/temporary tables intermediate.
The original caching was a solution for slower machines, but there was some evolution :-)

The colour indication (writing colournames) is based on the default hotcuecolours (but can be expanded of course)

afbeelding

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 10, 2025

Please squash the commits, all coomits should build on all platforms (in case we need to git bisect).

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 10, 2025

I think rather than having another delegate, it'd better to have this in BaseTrackTableModel::roleValue() (called by data()). It does also composeCoverArtToolTipHtml().

This would allow more flexibility, like easily change for which columns to show the tooltip.

@Eve00000
Copy link
Copy Markdown
Contributor Author

I think rather than having another delegate, it'd better to have this in BaseTrackTableModel::roleValue() (called by data()).
This would allow more flexibility, like easily change for which columns to show the tooltip.

Good thinking, i first started with a class ComposeHotCueTooltip and then reverted to titledelegate ;-) (stupidissimo mi).
You like it?

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 10, 2025

You like it?

Hmm, I don't need it but I see it can be helpful.
Since this is ment for hotcue, let's list only hotcues. Properties I consider relevant:

  • [number] (without # prefix, left-aligned, no indentation)
  • time
  • label if present

So [type] and [Color] can be removed IMO.

Idea: if Cue is on a hocue, add [Cue] or something to indicate that?

@Eve00000
Copy link
Copy Markdown
Contributor Author

Hmm, I don't need it but I see it can be helpful. Since this is ment for hotcue, let's list only hotcues. Properties I consider
relevant:

Now it feels like hijacking somebody else's idea.

* [number] (without # prefix, left-aligned, no indentation)
* time
* label if present

So [type] and [Color] can be removed IMO.

Well, I want to see that info especially as some hotcue icons (loop & jump) are not clear cisible at a distance.
With my big tooltip font I can see everything.

Idea: if Cue is on a hocue, add [Cue] or something to indicate that?

The problem: the tracklist is cached, new created hotcues aren't directly in the overview, vreating a new hotcue and sending a signal to (kind of) highlight / indicate the actual hotkeyposition (if any) can result in nothing.

The first objective wa to have a difference between tracks with / without hotcues,
for me the colours are important in combination with the labels (using my cue-stemvols) to know which cue is which a capela / melody / synth / riff

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 10, 2025

Hmm, are color names really that helpful?
As QToolTip also supports html and RichText, we shoudl be able to insert colored squares in line with html/css:

"<span style='display:inline-block; "
"width: 1em; height: 1em; "
"background-color: green; " <-- put color here
"vertical-align: middle; "
"border: 1px solid #444; "
"margin: 0 0.2em;'></span>"

@Eve00000 Eve00000 force-pushed the ShowHotcueInfoInToolTip branch from e8d190b to ea06406 Compare October 10, 2025 21:22
@Eve00000
Copy link
Copy Markdown
Contributor Author

Eve00000 commented Oct 10, 2025

Hmm, are color names really that helpful? As QToolTip also supports html and RichText, we shoudl be able to insert colored squares in line with html/css:

Thanks, I didn't think of that, great help.

@Eve00000 Eve00000 force-pushed the ShowHotcueInfoInToolTip branch from 86e21a9 to 3b86fd7 Compare October 10, 2025 22:14
Show colours with html

Fix hotcue #

Fix loop
@Eve00000 Eve00000 force-pushed the ShowHotcueInfoInToolTip branch from 3b86fd7 to 2d94a1c Compare October 10, 2025 22:40
@JoergAtGithub
Copy link
Copy Markdown
Member

Shouldn't the loop duration be displayed in beats instead of time?

Comment thread src/library/basetracktablemodel.cpp Outdated
return formatHotCueTooltip(columnValue, hotCues, sampleRate);
}

QString BaseTrackTableModel::formatHotCueTooltip(const QString& columnValue,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think we can merge all hotcue tooltip methods into composeHotCueTooltip()

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The idea was to have clear code and maybe have future other formatting functions.

Comment thread src/library/basetracktablemodel.cpp Outdated
QString tooltip;

// Start HTML
tooltip += "<html><body style='white-space: pre; font-family: monospace; font-size: 15pt;'>";
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

A monospace font and hard-coded font size will make the tooltip inconsistent with other tooltips (using the skin font).
I guess you chose monospace to get the [type] aligned? If yes, is this really an issue?
It'll only be slightly off if we have hoctue > 9

Last resort: create a html table?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This is a regular tooltip:
Image

This is one with hotcues (completely off):

Image

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yes, that was the idea,
as you know (I wrote it before): I'm not a designer/css/qss/specialist, I try to create mathematical-visual correct things. My graphics-inspiration & insight isn't like yours.
I created different views (with a coloured square etc) and for me the 'clear, clean aligned coloured lines' are working best (tested from distance like in a live situation).
At a certain point I know my knowledge/insight/ambition/inspiration/interest stops with 'this is how I wanted/meant/want to use it', while there could definitely things be improved to get it 'in-line' with eg the design of other things.
Design/layout things probably take me 2/3/4/.. times more then it would take others (and it still wouldn't be of the same quality).
So if it comes to design/layout ... I'd be happy to hand over this baby for adoption, instead of having long discussions about formatting/fonts...

Comment thread src/library/basetracktablemodel.cpp Outdated
16,
QChar('0'))
.toUpper();
cueLine = QString("<span style='color: %1;'>%2</span>").arg(hexColor, cueLine);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't think coloring the entire line is a good idea. We may have dark hotcue colors and those are hard to read in skins with dark background.

Did you try the colore square?
We may even try colored square with the hotcue number in it (contrasting color) so it looks like the buttons and waveforms marks.

Comment thread src/library/basetracktablemodel.cpp Outdated
Comment thread src/library/basetracktablemodel.cpp Outdated
Comment thread src/library/basetracktablemodel.cpp Outdated
default:
typeString = "Unknown";
break;
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Let's please stick to hotcues. Intro/outro/fisrt sound is just noise IMO

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 12, 2025

With 2e789bb I get this:
(also note the QColor / mixxx::RgbColor helpers)
image

4 is actually a saved loop 🤔

Eve00000 and others added 2 commits October 12, 2025 08:53
Co-authored-by: ronso0 <ronso0@mixxx.org>
Co-authored-by: ronso0 <ronso0@mixxx.org>
@Eve00000
Copy link
Copy Markdown
Contributor Author

Nice idea, but as I wrote: I don't have the graphivcal inspiration that brings me those ideas.
Was 4 already a loop or did you change it in this Mixxx-session?
I'm testing with saving-reopening the cues table to get the accurate list.

@Eve00000
Copy link
Copy Markdown
Contributor Author

Shouldn't the loop duration be displayed in beats instead of time?

Adding the beats is certainly an option, but:

  • not all loops are based on beats, so the time duration needs to be visible
  • as position & duration are saved as frames in the cues table it needs to be a calculation of frames -> framerate -> time -> actual BPM (can be changed between the creation of the loop and time being, constant/variable BPM) -> we could end up with eg 4.6 beats. Would this be a help?

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 12, 2025

Design/layout things probably take me 2/3/4/.. times more then it would take others

Sure, that's why we collaborate, right?
And also be asured that I also did'n shoot this (colored squares) from the hip, it took me more than an hour (and chatgpt) to get it somewhat 'right' / how I think it should look to be in line with the skins.

for me the 'clear, clean aligned coloured lines' are working best (tested from distance like in a live situation).

I opened the screen shot and stepped back, and I can't read the blue hotcue line and aI have trouble with the red and purple hotcue.
FYI you can overwrite tooltip font size per widget, for example

WLibrary QToolTip {
  font-size: 15pt; /* or try 2em if you want to double the library font size */
}

@Eve00000
Copy link
Copy Markdown
Contributor Author

Ah srry, I thought you fluently wrote those style things, like 'freehand painting', I had no idea you had to look them up. ;-)

trouble red and purple hotcue

ah that's not good, needs to be solved :-(

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 12, 2025

I'm testing with saving-reopening the cues table to get the accurate list.

I think the issues is that CueDAO is not refreshed as frequently as the Tracks.
But you can simply get the cues from the track:
QList<CuePointer> cues = pTrack->getCuePoints();

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 12, 2025

So if it comes to design/layout ... I'd be happy to hand over this baby for adoption, instead of having long discussions about formatting/fonts...

.. and passing commits around. Sure.

I managed to align cue properties with a html table. Looks good I think.
Jumpcues are not considered yet. As for loops I suggest to use an icon after the label (instead of [Hotcue], [Loop] etc.)
image
2458785

Shall I push to your branch or continue in a separate branch?
For sake of simplicity I'd prefer the latter. (I may also squash and rebase and I'd rather do that in my own branches..)

@Eve00000
Copy link
Copy Markdown
Contributor Author

I managed to align cue properties with a html table. Looks good I think. Jumpcues are not considered yet. As for loops I suggest to use an icon after the label (instead of [Hotcue], [Loop] etc.)

table looks good indeed, I can't see the icons, #7 in the image in description = jump cue and type is shown as jump cue.

Shall I push to your branch or continue in a separate branch? For sake of simplicity I'd prefer the latter. (I may also squash and rebase and I'd rather do that in my own branches..)

be my guest, do as you like/prefer ;-)

@Eve00000
Copy link
Copy Markdown
Contributor Author

QList<CuePointer> cues = pTrack->getCuePoints();

You're the King!

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 13, 2025

QList<CuePointer> cues = pTrack->getCuePoints();

You're the King!

Naa, I just checked where WHotcueButton and CueControl get their cues from ; )


Will open a PR soon.

@Eve00000
Copy link
Copy Markdown
Contributor Author

You're the King!

Naa, I just checked where WHotcueButton and CueControl get their cues from ; )

Well I was crashing my brains to find a solution that was quite obvious

@ronso0
Copy link
Copy Markdown
Member

ronso0 commented Oct 13, 2025

Here's my version #15484

@github-actions
Copy link
Copy Markdown

This PR is marked as stale because it has been open 90 days with no activity.

@github-actions github-actions Bot added the stale Stale issues that haven't been updated for a long time. label Jan 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build library stale Stale issues that haven't been updated for a long time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants