fix(launcher): recreate tooltip window on resize so it tracks the new scaling (#2111)

[Anai-Guo]

Summary

Fixes #2111. After the user resizes the KoboldCpp launcher window, the floating tooltip windows shrink to a sliver too narrow to display any text.

Root cause: actually_resize calls ctk.set_widget_scaling(smallratio), which updates the global scaling for every CustomTkinter widget. The singleton tooltip (CTkToplevel + CTkLabel) was created before the resize and its internal geometry is now stale — on the next hover, update_idletasks() measures the outdated size and wm_geometry preserves it, leaving a near-zero-width window.

Fix: Declare gtooltip_box / gtooltip_label as nonlocal inside actually_resize and destroy/reset the pair immediately after set_widget_scaling. The next mouse-enter recreates the window cleanly under the new scale.

Test plan

• Resize the launcher window to a smaller size
• Hover over any setting to verify the tooltip displays correctly at the new window scale
• Resize back to original size and verify tooltips still work

Assisted-by: Claude

🤖 Generated with Claude Code

[Anai-Guo]

Note for reviewer: the actual fix is just 4 lines in the actually_resize function. The large diff is because my fork base is behind upstream; the functional change is:

 def actually_resize(windowwidth,windowheight,lastpos,smallratio):
+    nonlocal gtooltip_box, gtooltip_label
     root.geometry(str(windowwidth) + "x" + str(windowheight) + str(lastpos))
     ctk.set_widget_scaling(smallratio)
+    if gtooltip_box:
+        gtooltip_box.destroy()
+        gtooltip_box = None
+        gtooltip_label = None

This destroys and resets the cached tooltip window after scale change so it is recreated fresh on the next hover.

[wbruna]

The large diff is because my fork base is behind upstream

Can't you rebase the PR branch on top of current concedo_experimental?

[LostRuins]

rebase would be good but since this patch is tiny, i went ahead and added it directly. 01f2fa5