Improve floating text boxes (TextFloat and TextFloatSimple)

[jlintgod1]

This PR adds some quality-of-life improvements to floating text boxes (TextFloat and TextFloatSimple), including:

• Clamping positions to the screen bounds, allowing them to stay on screen and readable
• Setting floating text position close to mouse cursor when dragging/resizing clips (implements About track position #3577?)
• Layout adjustments to make TextFloat a bit smaller and make it more stable with changing text (particularly noticeable when adjusting the length of a clip)
• Code style cleanup

Comparison Videos

Before (current Nightly):

2026-06-29.15-49-46_small.mp4

After:

2026-06-29.16-23-45_small.mp4

[yohannd1]

Tiny change:

[yohannd1]

Thanks for making this! Code review wise, everything looks alright.
I did find a bug while testing though: sometimes the move action seems to make the text float overflow in the X position, but I'm not sure what the specific condition is as it seems to depend on the difference between the size of the song editor subwindow and the size of the main window itself.

2026-06-29.21-55-09.mp4

[jlintgod1]

sometimes the move action seems to make the text float overflow in the X position

I noticed that too while working on the PR (and isn't caused by it), but I wasn't sure about how to fix it until I actually looked into it.

It's caused by ClipViews getting moved to a negative x position (relative to their parent) if they are outside the visible range of the song editor (or specifically TrackContentWidget). Since the text float's position is relative to the clip view, it gets pushed to the left.

lmms/src/gui/tracks/TrackContentWidget.cpp

Lines 276 to 291 in cd9a0de

	const int ts = clip->startPosition();
	const int te = clip->endPosition()-3;
	if( ( ts >= begin && ts <= end ) ||
	( te >= begin && te <= end ) ||
	( ts <= begin && te >= end ) )
	{
	clipView->move(static_cast<int>((ts - begin) * ppb / TimePos::ticksPerBar()), clipView->y());
	if (!clipView->isVisible())
	{
	clipView->show();
	}
	}
	else
	{
	clipView->move(-clipView->width() - 10, clipView->y());
	}

The simplest solution might be to have clip views not moved from where they're calculated to be (based on the clip's position), but I still need to figure out if there are performance impacts.

[yohannd1]

nooo, why was this closed?

[jlintgod1]

In hindsight, it might've been better to not close it, but I just kinda went through a rough moment (still technically going through it) and feel very unmotivated. Hence why I closed it for no reason.

I probably won't figure out how to test performance impacts for a little bit though.

[yohannd1]

Oh, I see, no pressure. In case you don't want to work on it, you can also signal it and others can chime in to continue the work. Either way, hope you get through your situation, good luck!