Note: native color picker run on its own thread for an automated test

[dpc00]

Claude reports: to complete an automated test with GhostShell and sublime-mcp, we had to run the native picker call (use_os_color_picker) on its own thread, because it froze Sublime until the dialog was closed. Did not save the modified code.

[facelessuser]

ColorHelper is not designed to be used this way.

[dpc00]

Claude reports: a follow-up with the numbers. With use_os_color_picker on, "Color Helper: Picker" calls ChooseColorW on Sublime's main thread (ch_panel.py color_picker, then ch_native_picker.py pick). Sublime shows "Not Responding" until the dialog is closed: 125.9 seconds in our test, ended by cancelling the dialog from outside. Cancel returned control at once and the buffer was unchanged. The dialog also opened on white, not on the colour under the caret (#336699 in a CSS file). ColorHelper 6.7.0, Sublime Text 4215, Windows 11.

[facelessuser]

I don't understand what this is trying to convey. When using the native, OS color picker, the process is blocking until it returns results. This is expected and how it must work.

[dpc00]

It is extremely difficult to argue with you. Claude suggested some somewhat complex workarounds to guarantee functionality preservation, but I decided to drop it. This is the only package out of 1328 which completely thwarted my automated test setup. So you are unique. Claude would (and did in test) put the picker off the main thread and somehow proposed to make it work as designed. If you want I can get that coded and submitted for your review. You have pushed up the standards for my GhostShell and sublime-mcp automated test jig and that is good.

…

On Fri, Oct 9, 2026, 7:14 PM Isaac Muse ***@***.***> wrote: I don't understand what this is trying to convey. When using the native, OS color picker, the process is blocking until it returns results. This is expected and how it must work. — Reply to this email directly, view it on GitHub <#283?email_source=notifications&email_token=BYZWW72MZL6ZOONWEZY3DM35TGEN7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2DSNJTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18844953>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BYZWW72INYK2KDS2ZSEFSNT5TGEN7AVCNFSNUABHKJSXA33TNF2G64TZHMZTCNRUGE4DIMR3IRUXGY3VONZWS33OHMYTAOJYGQ4DAOFBOYBA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[facelessuser]

If you have something, I don't mind looking at it. If it isn't too convoluted or fragile we may consider using it.

[dpc00]

Claude reports: following the question in this discussion, here is a change for the native color picker, on a branch of dpc00's fork: https://github.com/dpc00/ColorHelper/tree/native-picker-off-main-thread (one commit, ch_panel.py only, flake8 clean).

What it does: with use_os_color_picker on, the OS dialog now runs on a worker thread, so Sublime and the other packages in the same plugin host stay responsive while the dialog is open. The result goes back to the selection the picker was started from, even if the user edited, moved the caret or switched tabs meanwhile, and is dropped if that file was closed. A second picker request while one dialog is open only shows a status-bar message.

Tested: Windows (the stock release froze Sublime until the dialog was closed; with the change it stays responsive) and Linux under WSL with kcolorchooser. Cases: OK and Cancel, edits and a moved caret while the dialog is open, switching tabs, closing the file, reloading or unloading the plugin with the dialog open, two overlapping dialogs, and the built-in picker unchanged. macOS is untested.

It is one function, about 60 added lines. Feel free to take it, change it or ignore it.