Add a dark theme for the Options dialog - #1178
Conversation
2d8e803 to
9fca02e
Compare
|
Quick observations:
|
9fca02e to
ff8cf9b
Compare
|
Thanks for the feedback! I've pushed an update that addresses all three points, and here's a build so people can try it: Test build (x64 installer): https://github.com/kcinickgx/MPC-BE/releases/tag/dark-options-test On the observations:
The |
|
Good idea — added a portable ZIP to the same release: Portable (x64, ZIP): https://github.com/kcinickgx/MPC-BE/releases/download/dark-options-test/MPC-BE.1.9.0.24.x64.zip Just extract and run |
|
On several option pages, when I make changes and press Apply, some of the text labels become invisible. |
|
Makes the Options property sheet (the "O" dialog) follow the dark look of the rest of the player instead of always rendering in the light system style. It covers the whole dialog: the navigation tree, the property pages, group boxes, edits/combos, list controls, spin buttons, sliders, tab headers, checkboxes and the scrollbars (flat, drawn through the bundled CoolSB, matching the playlist). The sheet also re-themes live when the setting is toggled while it is open. Everything is gated on the existing "Use the 'dark' theme" setting (bUseDarkTheme) and reuses the existing ThemeRGB() palette, so when the flag is off every control falls back to its original light appearance and there is no behavioural change. A new helper (controls/DarkTheme.*) centralises the theming so most of the ~26 pages are covered from CPPageBase / CPPageSheet. Small, flag-gated tweaks are made to the bundled coolsb (expose one global as extern so the header can be included from more than one TU) and to the TreePropSheet page frame (dark caption/background colours). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ff8cf9b to
d9bf9c9
Compare
…alogs - Scrollbars: drop the CoolSB custom scrollbar for the native dark one (SetWindowTheme "DarkMode_Explorer"). The custom bar fought the OS repaint and flickered/froze while dragging; the native bar is solid and consistent. - Palette is now fixed and independent of the R/G/B/Brightness sliders (those tint the player only), so the Options dialog never half-repaints or blackens its text. - Theme each page once on first activation instead of every activation, so switching pages is instant. - Owner-drawn push buttons: keep the Win11 rounding + icon, stay dark when enabled (Apply no longer flashes white), and honour BS_MULTILINE captions. - Dark-theme the internal/external filter configuration sheets (CComPropertySheet): frame, owner-drawn dark tab, page background/controls, and light radio captions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Pushed an update (
Main change: I dropped the custom (CoolSB) scrollbar and switched the Options dialog to the native dark scrollbar ( Other fixes in this build:
|
- Colour-well buttons (Interface / OSD / Subtitle Default Style) are push buttons that their page fills with the selected colour via NM_CUSTOMDRAW; skip owner-drawing them so they show the colour swatch again instead of their "B"/"O" caption. - Formats checkboxes: render them with the native visual style (unchecked / checked / mixed for the partial state) in both light and dark, and move them from the item icon (LVSIL_SMALL) to the state image (LVSIL_STATE) so the row-selection highlight no longer paints the checkbox. Rebuilt when the dark theme is toggled at runtime. This also changes the light-mode Formats checkbox from the custom SVG glyphs to the native ones, to match the other checklists. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Another update (
Fixed:
One heads-up: to make the Formats checkboxes consistent with every other checklist, the light-theme Formats checkbox now uses the native Windows checkbox (unchecked / checked / indeterminate for the "only some extensions registered" state) instead of the old custom SVG glyphs. That's a small change to the non-dark appearance — calling it out explicitly since it touches the light theme. Thanks again @Freem-di for the detailed reports! |
|
Disabled text look's "bad": Incorrect colors - check the settings and color of the header and toolbar: |
This doesn't need to be reverted; it's not a bug. I just mentioned it to highlight the change. |
…dressing review - The Options background now follows the R/G/B/Brightness sliders (ThemeRGB), so it matches the player, and the title bar is tinted with DWMWA_CAPTION_COLOR like the player's caption. Text stays a fixed readable colour (never driven to black). The sheet re-tints when a slider drag ends (repainting standard controls on every tick flickers, and WS_EX_COMPOSITED breaks the list controls), so it snaps to the final colour on release while the player follows live. - Theme sliders are owner-drawn and paint from a committed colour snapshot, so the one being dragged doesn't recolour under the cursor; all four move together on release. - Disabled text labels are owner-drawn flat instead of the embossed grey Windows draws on dark (addresses maintainer feedback). All Options text/glyphs are fixed, never tinted. - Elevated "Modify" Formats dialog now loads bUseDarkTheme, so it matches the theme instead of always appearing dark. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Update (
Addressing @Aleksoid1978's review:
A few honest limitations, up front, since they're inherent to theming the native Win32 controls rather than owner-drawing everything:
Making it fully live and arbitrarily-coloured would mean owner-drawing every control from scratch (a framework like MPC-HC's Happy to adjust the trade-off on any of these if you'd prefer something different. |
via
|
The elevation shield set via BCM_SETSHIELD is drawn internally by the button and is not returned by BM_GETIMAGE, so owner-drawing the button dropped it. Flag the button (MarkUacShield) and paint IDI_SHIELD ourselves when flagged, so the non-admin Formats "Modify" button shows its shield again in the dark theme. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Build 1.9.0.26:
|
|
Fixed the missing UAC shield (
The Formats "Modify" button (shown only to non-admin users) sets its elevation shield via Note for testing: the shield only appears when running without administrator rights (that's when the "Modify" elevation button is shown at all). |
|
Re-uploaded the build as 1.9.0.28 — the language files are fixed:
The "translations not compatible with this version" errors were my packaging mistake, not a code issue: I'd only been rebuilding the main binary, so the shipped |
|
Build 1.9.0.28: |
- When the dark theme is turned off at runtime, reset the process-wide preferred app mode (FORCELIGHT + FlushMenuThemes) so the main window's immersive-dark menus revert to light immediately instead of staying dark until the app is restarted. Re-arm it when turned on. - Load the UAC shield via SHGetStockIconInfo(SIID_SHIELD) (cached) instead of LoadIcon(IDI_SHIELD), which could return null, so the Formats "Modify" button reliably shows its shield in the dark theme. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
New build 1.9.0.29 with two more fixes:
|
|
External filters have issue with theming. Cursor should hover to trigger repaint some widgets. i.e XySubFilter , VSFilter/xy-VSFilter 
|
Measure the caption width with DT_CALCRECT (which drops the "&" accelerator prefix) instead of GetTextExtent (which counts it), so single-line owner-drawn push buttons whose caption has an accelerator (e.g. the Formats "&All" / "A&udio" association buttons) are centred instead of shifted to the left. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Wrong icon size, DPI 175%: |
|
What about all the other dialogs - Shader Editor, History, etc.? |
|
What about other dialogs? - Check for Updates, Command Line Switches, About..., Reset settings |
|
"File properties - Details/Clip", "Internal filter - Source/Video/Audio", "Add to Favorites dialog" - border turned white. |
Follow-up to the border rework (reviewers saw issues our machine didn't): - White borders (File Properties Details/Clip big field, Internal Filters lists, Add-to-Favorites dropdown): go back to overpainting a dark frame over whatever the theme drew, so the border is dark on every machine. Skipping / clipping the default paint rendered a white border on some systems. - Overpaint now self-skips when the control reserves no non-client border (edge 0, e.g. the MediaInfo NOT-WS_BORDER edit): a frame there lands in the client and gets dragged into the text by ScrollWindowEx. So the bordered multiline edits (Details/Clip) get a dark frame with no scroll drag, and MediaInfo stays clean. - Restore the dark border on scrolling list boxes, and add one to combo boxes (the CFD combo border stayed light on some machines). - CDarkCheckListBox: clip a partially-visible last item to the client bottom (ETO_CLIPPED) so its row no longer spills below the list box into the page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks @Freem-di, @xLn2 — appreciate the persistence, and the detailed screenshots really help. 1.9.0.76 fixes this round:
|
|
Build: 1.9.0.76
|
|
The error about language files should also be dark. And maybe not just it. 
|
# Conflicts: # src/apps/mplayerc/AddCommandDlg.cpp # src/apps/mplayerc/HistoryDlg.cpp
…, and more Round of reviewer-reported fixes on 1.9.0.76: - Edit hover flicker (About / History / Format / Keys filter / Logo fields): the cause was DarkMode_CFD's hover/hot border state, which self-invalidates the edit's non-client on every mouse-move, so our WM_NCPAINT overpaint flashed light->dark each time. Single-line edits now DISABLE the visual style (SetWindowTheme "") instead of CFD, so there's no hover border to repaint; the dark overpaint border is drawn once and the interior stays dark via WM_CTLCOLOR*. - Add-to-Favorites combo showed a WHITE border when focused: a combo paints its border in the CLIENT area and repaints it light on focus, which the NC overpaint never covered. BorderSubclassProc now also overpaints the client-edge frame on WM_PAINT and repaints on focus change - gated on the ComboBox class only. - Keys "edit hotkey" showed a white button: CEditWithButton_Base::DrawButton drew a light themed button; added a dark branch (dark face/border, light caption). - Internal Filters: the next item's checkbox peeked below the box. Our DrawItem cleared the DC clip (SelectClipRgn(nullptr)), so the base CCheckListBox glyph spilled; clip to the client rect instead. - Language-pack version-mismatch message box rendered light: it fires during early startup before the persistent message-box hook exists and before bUseDarkTheme is read. Read the dark flag before SetLanguage, and wrap the box in a CDarkMessageBoxHook guard. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks again @Freem-di, @xLn2 — and rebased onto the latest
|
|
…tch, grid backstop Reviewer round on 1.9.0.95: - White rectangle when repositioning a docking bar / white border when resizing the Shader editor bar: CSizingControlBar never painted its own CLIENT background dark (only the NC frame follows m_bUseDarkTheme; the client was erased by DefWindowProc with the shared light class brush). Added a dark OnEraseBkgnd so an exposed client strip on redock/resize/toggle no longer flashes white. - GoTo time field stayed light: it's a CMFCMaskedEdit (window class "MFCMaskedEdit", a superclass of WC_EDIT), so ThemeControl's class check missed it. Handle "MFCMaskedEdit" in the Edit branch (interior still darkens via the parent's WM_CTLCOLOREDIT). - Shader editor combo twitched when its dropdown opened: last round's combo-border fix invalidated the whole combo on focus (interior + button + border). Narrow the focus invalidate to just the 1px border frame. - "Grid view unnecessary rows": fill the list's empty area AFTER the grid lines so it backstops any line drawn past the last item in the empty space below a short list. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks @xLn2 — solid batch, the detail helps a lot. 1.9.0.96:
Honest notes on the rest:
|
|
Build 1.9.0.96 - continuing the fight against flickering :)
|
Replace the "overpaint a dark frame over the theme's light border" technique (which flashed light->dark on every non-client repaint — hover, tooltip, tab-switch, focus — and had repeatedly regressed to white borders / scroll-drag) with an owning-border subclass that removes the light source entirely. For edits / list boxes / list-views / tree-views / sunken statics (OwnerBorderSubclassProc, ApplyOwnerBorder): strip WS_EX_CLIENTEDGE/WS_BORDER so DefWindowProc draws no edge, re-reserve the identical band in WM_NCCALCSIZE (Def first, then InflateRect — so the scrollbar sizes correctly and the client metrics don't shift), and paint the band ourselves in WM_NCPAINT (fill the control's interior colour, then a 1px stroke, ExcludeClipRect over the scrollbar). The DarkMode_Explorer theme stays only for the dark scrollbar; there is no border style left for it to draw light, so nothing can flash. Hover/focus feedback is restored (frame-only RedrawWindow, dark->dark-tone, never a full invalidate). Borderless controls (MediaInfo NOT-WS_BORDER edit) get logical==0: no reserve, no paint, no subclass — stays borderless, nothing to drag on scroll. All thicknesses via GetSystemMetricsForDpi/GetDpiForWindow (reserve == stroke, no DPI seam); DPI change re-runs NCCALCSIZE. Band fill matches each control's real interior (editable edit/listbox = CtrlBackColor; read-only edit / list / tree / static = FaceColor) so there's no seam. Combos (ComboBorderSubclassProc, ApplyComboBorder): their border is client-area. CBS_DROPDOWNLIST is double-buffered (WM_PRINTCLIENT -> mem DC -> stroke -> one BitBlt); the editable CBS_DROPDOWN keeps the known-good post-Def client re-stroke with a border-ONLY focus invalidate (no dropdown twitch). StripThemeChildProc (toggle-off) restores the stripped styles and frees the heap data via FreeOwnerBorder. The old BorderSubclassProc / ApplyDarkBorder are removed. Design produced by an adversarial multi-agent pass against the regression history; ships behind the dark theme, needs a visual test pass (16-point checklist). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Follow-ups to the owning-border rework, from visual testing: - CtrlBorderColor: ThemeRGB(35,40,45). The old (70,75,80) rendered as a light/near-white line once the user's theme brightness/colour sliders are up (ThemeRGB tints by (brightness+value)*tint/256) - the actual source of every "white control border" report. - OwnerBorder WM_NCPAINT: cover the scrollbar's light inner edge using the scrollbar's REAL rect (GetScrollBarInfo); the earlier band.right-sw guess landed wrong after the custom WM_NCCALCSIZE and never covered it. Also exclude the client rect so the band fill can't blank list content. - Drop the celeste focus / grey hover accent from the owning border and the combo border: a bright frame around the focused Options nav tree read as garish and followed the focus around. Consistent dark border in every state (disabled stays dimmer). - OwnerBorderRefreshFrame uses SWP_FRAMECHANGED (frame-only repaint). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks @Freem-di — the flicker was the real problem, so this build reworks the control borders from scratch to kill it at the source. 1.9.0.98: Border flicker (both of your points) — the old approach overpainted a dark frame on top of whatever light border each control drew for itself. So every time a control repainted its own border — a tab switch, a mouse-move (the themed hover state self-invalidates the non-client), a focus change — you'd catch its light border for a frame before the overpaint landed on top. Fighting repaint with repaint; it was never going to be fully clean. New approach ("owning border"): take the border away from the control instead of painting over it. Strip While I was in there I also fixed the white border a couple of testers hit: the border colour rendered light once the theme brightness/colour sliders are up (the palette helper tints every colour by those sliders, so a high base value goes near-white), and the list scrollbar's own light inner edge wasn't being covered. Both dark now. @xLn2 — a note on your #5 (edits having no hover/click colour): I did try adding a dark hover/focus accent back on this new border, but a highlighted frame around a large focused control — the Options nav tree especially — looked garish and "followed" the focus around the dialog, so I've left the border a single consistent tone for now. Open to a subtler treatment if one comes to mind. |
|
Thanks @kcinickgx , there are some feedbacks.
I didn't notice a difference.
White rectangle appears.
It is still twitching.
I don't know about capabilities of MFC. So as a normal people I think on hover can we draw outline (or inline) to edit box and when clicked color inside solid fill?
I understand situation. If we can't control external windows maybe we shouldn't try to theming these. (white/black list or another methods) 1.9.0.98 dev Color correction edit borders 
Comboedits becomes highlighted when sheet opened and have White line on hover 
Listview's borders too thin 
|
|
Build 1.9.0.98.
Same issue Audio - Sound processing after clicking Default Possibly in other similar forms as well. |
|
When using languages other than English (tested Russian and German), white bars appear in some places. Maybe in other places too. 
|
… thin borders
Localized UIs showed light "white bars" on many pages (Player/History, Web
Interface, Online services, Frame sync, External Filters, Priority, File
Properties). The base .rc draws the page dividers as SS_OWNERDRAW statics that
CPPageBase::OnDrawItem paints dark, but the per-language resources still carry
the older SS_ETCHEDHORZ dividers, which draw their own light 3D line and never
reach OnDrawItem. Own their paint with a subclass that draws the same flat dark
line, self-contained so it also covers dialogs that don't handle WM_DRAWITEM.
The Color Correction value boxes (Brightness/Contrast/Hue/Saturation) are RTEXT
SS_SUNKEN statics. ApplyOwnerBorder only recognised WS_EX_CLIENTEDGE/WS_BORDER,
so it left them at logical 0 and painted nothing - their native sunken edge
stayed light ("white-gray borders"). Recognise SS_SUNKEN (gated to the Static
class, since 0x1000 aliases ES_WANTRETURN on edits) and WS_EX_STATICEDGE as a
1px owned border, stripping SS_SUNKEN because its edge is client-drawn.
A combo's dropdown list (ComboLBox) is a popup, not a child, so the theme pass
never reached it; it only looked dark because comctl32 propagated the combo's
theme. The disable/enable cycle behind Reset (Color Correction) and Default
(Sound processing) rebuilt the list and dropped that, so it reopened in another
shade. Theme it directly and re-assert on WM_ENABLE.
An editable combo's child edit sends WM_CTLCOLOREDIT to the combo, not to the
page, so nothing darkened its interior and it read as highlighted on open; add
the handler. DarkMode_CFD also repaints its border hot on hover (the white line)
- re-stroke it dark once per hover-enter, gated by a flag so it can't churn.
FrameRect is always 1px, so the 2px band reserved for client-edge lists/trees
showed a 1px border - half what it replaced. Stroke the full band with
concentric frames; edits and value-box statics stay 1px.
Dropping the list-type combo's full InvalidateRect on focus removes the twitch
when its dropdown opens: Windows already repaints it on focus, and the border is
state-independent, so the extra full repaint only fought the drop.
Sizing bars erased their client with the lighter NC/caption shade while hosting
dark content, so a strip exposed during a redock/resize flashed pale (near-white
at high brightness). Give the client its own brush at the content shade and keep
the NC frame as it was. Also free each bar brush exactly once - the destructor
released m_hBrush twice and leaked m_hBrushFrame.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks @Freem-di, @xLn2 — the non-English report turned out to be the most useful clue in this whole thread, and it explained more than just the white bars. 1.9.0.99: White bars in Russian/German (@Freem-di) — this was a real bug and not a colour-tuning issue. The page separator lines in the base resources are Color Correction "white-gray" borders (@Freem-di #1, @xLn2) — the Brightness/Contrast/Hue/Saturation value boxes are Dropdown list changes colour after Reset / Default (@Freem-di #2) — a combo's dropdown list is a popup window, not a child, so my theme pass never actually reached it; it only looked right because the control library was propagating the combo's theme. Reset (Color Management) and Default (Sound processing) both disable and re-enable those combos, which rebuilds the list and drops that — so it reopened in a different shade. The list is now themed directly and re-asserted whenever the enable state changes, so it's one shade in every state. Comboedit highlighted on open + white line on hover (@xLn2) — two separate causes. The highlight: an editable combo's text field sends its colour request to the combo, not to the page, so nothing was darkening its interior. Added that handler. The hover line: the dark combo style owns a "hot" border state and repaints the border light on hover — now re-stroked dark once per hover, gated so it can't turn into repaint churn. Listview borders too thin (@xLn2) — correct, and an easy miss: the reserved band is 2px but the stroke call is always exactly 1px, so lists/trees showed half the thickness they replaced. Now stroked across the full band. Single-line edits and the small value boxes stay at 1px on purpose (2px reads heavy on a one-line field) — say the word if you'd rather they matched too. White rectangle on bar resize + Shader editor dropdown twitch (@xLn2) — both were still real, and I'd fixed the wrong thing last round on each. The rectangle: the bar was erasing its client with the lighter caption shade while the content it hosts is the darker page shade — and since those shades scale with the brightness slider, a strip exposed mid-resize read as near-white. The client now uses the content shade (the frame is unchanged). The twitch: all three Shader combos are the list type, and that branch was still doing a full invalidate on focus — the narrowing last round only landed on the editable branch. Clicking to open the dropdown gives focus, so it repainted the whole combo right as the list dropped. Since the border looks the same focused or not, that repaint is simply gone. Grid view "unnecessary rows" (@xLn2) — I owe you a straight answer here: I could not reproduce it on any list I could reach in this build, and looking again, last round's change was a no-op for the empty area (the grid loop already stops at the last item, so there was nothing below it to backstop). Rather than guess at another blind fix, could you tell me which page/list that 250x92 screenshot is from? With the exact control I can pin it down properly. Also fixed in passing: the sizing-bar destructor was freeing one brush twice and leaking another.
@Freem-di — testing in Russian/German again would be the most valuable check, since that separator fix touches every localized page. |
|
Build 1.9.0.99.
No change. As shown in earlier screenshots, they are dark when opening settings, but the color changes after reset or any change. I also tested in other languages — same issue.
The bars in other languages are now gray. If you zoom in, you can see two bars — one gray and one green. And there are white pixels on the left and right. Screenshot from Player - History: 
PS: Subtitles - Default Style - Subtitle font selector: it's a system dialog, so we have no control over its color, correct? |
|
Audio - Sound Processing: 
|
…disabled labels The localized "white bar" fix from the previous build only half-worked: a WM_PAINT subclass drew a dark line over the SS_ETCHEDHORZ separators, but the control's native etched line still bled through (two bars — the themed line plus the native grey one, with white end caps). Instead of fighting the native paint, convert the SS_ETCHEDHORZ/VERT/FRAME separators to SS_OWNERDRAW at theme time: an owner-draw static has no native rendering at all, and the page's existing OnDrawItem paints the same flat dark line it already draws for the English separators. CPPageBase pages get it via their OnDrawItem; pages/dialogs themed through ThemeDialog (File Properties Details/Clip, aux dialogs) get it via a WM_DRAWITEM case added to the dialog subclass, guarded on a conversion marker prop so it only ever touches the separators we converted and never a dialog's own owner-drawn controls. The original style is remembered and restored on a runtime theme toggle-off. Also: labels that were already disabled before the page was themed (Sound Processing disables its Level/Release labels in OnInitDialog, before OnSetActive themes the page) kept Windows' light disabled text — near-white under force-dark — because installing the static owner-draw subclass didn't repaint them. Force a repaint on install so the disabled owner-draw runs immediately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks @Freem-di — the screenshots made both of these clear. 1.9.0.100: Separator lines in other languages (the two bars + white ends) — you were right that my last fix didn't finish the job, and the screenshots showed exactly why: I was painting a dark line over the Audio – Sound Processing: text turns white on Default — found it, and thanks for the clean before/after. Those "Level"/"Release time" labels are disabled in the page's init code, which runs before the page gets themed. My owner-draw for disabled labels was installed correctly but never told to repaint, so the labels kept the text Windows had already drawn — and under forced dark mode that disabled text is near-white. Now it repaints on install, so a label that starts out disabled is dark-grey immediately, like the rest. (This was a general bug, so it should fix any "disabled label is too bright" case, not just this page.) Color Management / Sound Processing dropdown shade still changes — I have to be straight with you: this one I have not fixed yet. My last change themed the dropdown list popup, but that's not what's changing — it's the combo box's own field shade when it flips between enabled and disabled (Reset/Default toggle that). That comes from the system's dark combo rendering, which I don't control the same way, so I left it rather than ship another change that doesn't move it. To pin it down properly I'll likely have to owner-draw those combos (like the buttons/spinners already are). It's on the list. On the font selector (your PS) — correct. That's the standard Windows "Choose Font" common dialog; it's drawn by the OS and that particular one doesn't follow dark mode, so it stays light. Nothing I can theme there without replacing it wholesale, which isn't worth it.
Russian/German again would be the useful check for the separators. |
|
Build 1.9.0.100
|
# Conflicts: # src/apps/mplayerc/PPageAccelTbl.cpp
…elves
The localized resources draw the page dividers with SS_ETCHED* statics, which
paint a light 3D line that dark mode never darkens, so every non-English UI showed
a white separator. Two earlier attempts did not hold:
- Overpainting the line from a WM_PAINT subclass. The native etched line still
reached the screen on some repaint paths, leaving a doubled line with light
end caps.
- Converting the style to SS_OWNERDRAW at theme time, so the existing
OnDrawItem would draw it. A static picks its paint routine when it is
created, so changing the style type afterwards does nothing: the conversion
silently had no effect and the native etched line was drawn in full. This is
also why it looked intermittent - it was never being suppressed at all.
So stop competing with the control for the pixels. Hide it, and draw the divider
from the parent's background paint instead: a hidden window is never painted by
anyone, so no repaint path or timing can leak the native line. The divider is
drawn right after the dark background fill, in the control's own rect, so it
lands exactly where the resource put it and matches the line the English
SS_OWNERDRAW separators already get. Both painting paths are covered: pages via
CPPageBase::OnEraseBkgnd, and dialogs themed through ThemeDialog (File Properties
Details/Clip/Res, Capture, Shader combine, Pan&Scan Edit) via the dialog subclass
- together those account for every dialog that carries an etched separator. A
runtime theme toggle-off shows the control again, so it draws its own etched line
for the light theme.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Sorry for the slow turnaround @Freem-di. Rebased on current master (the branch had gone stale) and fixed the separators properly. 1.9.1.51: Separator lines — third time, and this time I stopped trying to out-paint the control. Your "sometimes it's there, sometimes not" was the clue that unpicked it: the line was never being suppressed at all. My last attempt changed the separator's style to owner-draw at runtime so the existing dark-line handler would draw it — but a static control picks its paint routine when it is created, so changing the style afterwards does nothing. The conversion silently had no effect and the native etched line was drawn in full, which is exactly what your zoomed screenshots show (white highlight over grey shadow — that's the standard etched edge, none of my drawing anywhere near it). Before that I tried overpainting it from a subclass, which is why you saw a doubled line with white end caps. So now the separator control is simply hidden, and the divider is drawn as part of the page's own dark background. A hidden window is never painted by anyone, so there's no repaint path or timing left that can leak the native line — which should also settle the intermittency. I checked every dialog that carries one of these separators (12 of them, including Pan&Scan → Edit that you found, plus Capture and Shader combine) and each one is covered by one of the two background-paint paths, so none of them should end up with a missing divider either. Audio – Sound Processing, white text — still not fixed, and I don't want to claim otherwise. My theory last time (the labels weren't being repainted) was wrong, since the fix changed nothing. Looking at your before/after again, I think I may have had it backwards: the labels might be going enabled after Default rather than staying disabled, in which case the "white" is the normal enabled text colour and the real oddity is that it doesn't match the surrounding text. If you can confirm one thing it would help a lot: after clicking Default, are the two sliders next to those labels usable (draggable) or greyed out? That single answer tells me which of the two it is and I can fix it directly instead of guessing again. Dropdown shade after Reset/Default — also still open, unchanged since last time. It needs those combos to be fully custom-drawn, which I'd rather do as its own change than bundle in here. Note the version jump: this is now based on current master, so it's 1.9.1.51 rather than 1.9.0.x. |
Options > Player > Mouse page and ... dropdown sub menu which leads to open command dialog.
Reset keys washing out dropdowns. You can see last adipose patches (probably New dialog for EVR-Sync renderers) about it. |
|
Build 1.9.1.51:
No, the sliders do not become active when pressing the Default button because the Auto volume control checkbox is not enabled. This is what it looks like after clicking Default: This is what it looks like when the Auto volume control checkbox is activated:
Probably need comments from the main developers on this one :) |
6 participants
What
Makes the Options property sheet (the
Odialog) follow the dark look of the rest of the player instead of always rendering in the light system style.It covers the whole dialog:
The sheet also re-themes live when the setting is toggled while it is open (Interface → Use the "dark" theme → Apply), so it never ends up half light / half dark.
How it's gated
Everything is gated on the existing "Use the 'dark' theme" setting (
bUseDarkTheme) and reuses the existingThemeRGB()palette. With the flag off, every control falls back to its original light appearance, so there is no behavioural change — it's purely visual and opt-in.Implementation notes
controls/DarkTheme.*, centralises the theming (immersive dark mode +WM_CTLCOLOR*+ a few owner-drawn/subclassed controls), so most of the ~26 pages are covered fromCPPageBase/CPPageSheetwith very little per-page code.coolsb: expose one global (fThemeRGB) asexternso the header can be included from more than one translation unit.TreePropSheetpage frame: dark caption / background colours.Screenshot