Feature/ses 598 dark mode icon color - #25
Open
borisbaltesbrickmakers wants to merge 983 commits into
Open
Conversation
This reverts commit 7ee995a.
SesCheckBox only re-themed the text label (color: Style.sesTrayFontColor); the indicator (box/checkmark) was left to the QtQuick Controls style, which on Windows 11 is FluentWinUI3 and draws it with native Fluent colors rather than the SES palette used by the rest of this dialog (password/note field borders etc.). Add a custom indicator matching that existing look (Style.sesTrayInputField border, Style.sesBackgroundColor fill, radius via Style.thickBorderWidth). Deliberately does not set x/y on the indicator - CheckBox/AbstractButton already positions it automatically based on padding/leftPadding, and an earlier attempt that set explicit x/y fought that positioning and produced visibly inconsistent offsets across the several SesCheckBox instances in this file (which each set their own padding/spacing/indicator size). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- indicator implicitWidth/Height were 18 while every call site overrides indicator.width/height to 20 (scrollContentsColumn.indicatorItemWidth); the control's own implicitHeight calc uses the declared implicit value, not the externally forced one, so the 18 vs 20 mismatch threw off the row's height/positioning math. - indicator had no explicit x/y. Replacing FluentWinUI3's indicator wholesale also discards the positioning the style template provides for it (indicator.x/y are set explicitly in that template, not by the generic AbstractButton C++ layer) - restore the same formula: y: topPadding + (availableHeight - height) / 2. - checked state is now a solid accentColor fill instead of a separate inner dot, which read more like a radio button than a checkbox. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ShareDetailsPage.qml had drifted ~99% from stable-33.0's version of the same file, making every future stable merge here a near-total conflict. Two of the drivers were purely visual and had no dependency on the page's sharing logic: - SesCheckBox was a local `component` block reimplementing CheckBox's indicator/contentItem for SES dark-mode theming, duplicated nowhere else but structurally unrelated to the page's share-state handling. - The bordered-input-field background (radius/border/fill for the password, expire-date and note fields) was copy-pasted identically three times. Move both into src/gui/SesComponents/ as standalone, reusable components (registered in ionos.qrc, same as SesErrorBox/SesTrayHeader) instead of inline page-local code. SesCheckBox now takes its accent color as a property rather than reaching up to the page's `root.accentColor`, so every call site passes `accentColor: root.accentColor` explicitly - preserves the existing runtime color (Style.sesIconColor via ShareDelegate/ShareView) rather than silently falling back to the component's own default. The page's actual sharing logic (signals, shareModelData bindings, resetXField() functions) is deliberately left untouched here so future stable-33.0 logic fixes still merge normally; only the parts that were pure, duplicated SES styling moved out. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The checked state was a flat, solid-filled square with no glyph at all, unlike every other checkbox in the app (native QCheckBox in GeneralSettings etc.), which show an accent-filled square with a white checkmark tick. Add theme/black/check.svg (Material Design's check icon, Apache-2.0/Google, annotated in REUSE.toml alongside the other Material icons already in theme/black/) and render it via the same image://svgimage-custom-color mechanism already used for search.svg/clear.svg elsewhere in this app - keeps it cross-platform (no dependency on the Windows-11-only QtQuick.Controls.FluentWinUI3.impl module that stable's native indicator PNG assets live in, which was considered and deliberately not used here). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both icons went through Style.se* properties that resolve to a static, non-recolorable resource path with the color baked directly into the SVG (ses-accountQuit.svg / ses-darkPlus.svg both have fill="#001B41"), so they never followed the app's own dark mode toggle: - Close button: iconSource: Style.sesAccountQuit - no recoloring attempted at all. - "+" (create link share) button: iconSource: Style.sesDarkPlus + palette.buttonText - looks like an attempted recolor, but is missing the image://svgimage-custom-color/ scheme and the "/" separator before the color, so the appended color is inert and the baked-in SVG color always wins. stable-33.0 solves both of these correctly, with "image://svgimage-custom-color/clear.svg" + "/" + palette.buttonText and "image://svgimage-custom-color/add.svg/" + palette.buttonText respectively (clear.svg/add.svg already exist in theme/black/). Use the same pattern but with Style.sesTrayFontColor instead of palette.buttonText, since palette.buttonText isn't bound to our own dark-mode toggle anywhere in this fork (same class of gap as the sharee search field's palette.placeholderText fixed earlier). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…4/B5) buttonPrimaryColor()/buttonPrimaryPressedColor()/pillButtonPrimaryColor() used an indigo/violet (#5B60D6) in dark mode that doesn't match the IONOS design spec (STRUXD-157), and pressed had no distinct darker state at all. Switch dark values to the confirmed Figma tokens Color/Blue Ionos/B4 (#1474C4, default) and B5 (#095BB1, pressed - deliberately darker). Hover keeps no confirmed spec value, so it's set to match the new default as an interim value instead of the old, now-mismatched hue. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SesCheckBox used Style.ncBlue for its checked-state accent, which resolves to a fixed compile-time constant (#0082c9) identical in both themes - no dark-mode value existed. Add Style.sesCheckboxAccentColor (light stays ncBlue unchanged, dark uses the new IONOS Blue Ionos/B4 #1474C4) and point SesCheckBox at it instead, so the checkbox gets an actual dark-mode value without changing its light-mode appearance. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MoreOptionsButtonStyle was the only one of the three ButtonStyle types to use a theme-aware color for its "three dots" icon on hover (buttonIconHoverColor(), dark #C9CBEF); PrimaryButtonStyle and SecondaryButtonStyle both use fixed white for that icon in every state, since the hover backdrop is a solid highlight color regardless of theme. Match that existing convention so the dots stay clearly legible against the hover circle instead of rendering too dark. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
checkboxCheckmarkColor() deliberately flipped to black in dark mode, reasoning that the checkmark contrast should invert with the theme. It doesn't: the checked box's fill is always a saturated accent color (buttonPrimaryColor(), sesstyle.cpp:127) rather than the page background, so a black checkmark on that blue fill is hard to read in either mode. Use fixed white in both themes instead, matching the checkmark color the QML SesCheckBox already uses. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds COLOR_MAP.md sections for: the IONOS Figma (STRUXD-157) vs. code comparison behind the primary-button/checkbox-accent color changes, and the two contrast bugs found via live screenshots afterwards (MoreOptionsButtonStyle hover icon, native checkbox checkmark color). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The avatar/folder/sync-arrow icons on the "add account" wizard page share the brand-colored ses-*.svg fill (#2F2F70), but Theme::createColorAwareIcon() just inverts the source SVG's raw RGB values for dark mode - fine for neutral black/grey icons, but #2F2F70 inverts to an undesigned washed-out khaki/beige that made the three icons in that row look inconsistent (only the uncolored sync-arrow stayed dark indigo). Add a local tintedThemeIcon() helper that renders the SVG via QSvgRenderer and re-tints it with a real themed color (WLTheme.iconDarkColor()) via SourceIn-compositing - the same technique MoreOptionsButtonStyleHelper already uses. Render/target sizes are kept matching the original behavior (64x64 pre-render + pixmap(32) for avatar/folder, 32x32 direct for sync-arrow) - an earlier pass through QIcon(path).pixmap(size) got this wrong for the non-square folder SVG. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same createColorAwareIcon() RGB-invert issue as the wizard icons (previous commit): the folder icon here uses the same #2F2F70-filled ses-folderIcon.svg, which inverted to the same washed-out khaki/beige in dark mode. Apply the same tintedThemeIcon() fix, duplicated locally rather than shared - matching the codebase's existing convention of small per-file color/icon helpers (e.g. MoreOptionsButtonStyleHelper::tintPixmap()) rather than one shared utility. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SecondaryButtonStyle::buttonFocusedColor() returned a fixed WLTheme.white() regardless of theme, so any secondary button (e.g. "choose another folder" in the wizard) flashed to a hardcoded white fill as soon as it received focus (click or Tab) in dark mode. PrimaryButtonStyle already gets this right: its buttonFocusedColor() just repeats the default fill (buttonPrimaryColor()) and leaves the focus ring entirely to the separate, already theme-aware buttonFocusedBorderColor() - SecondaryButtonStyle didn't follow that pattern, likely a copy-paste oversight. Return buttonSecondaryColor() instead, matching the default fill like Primary does. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds COLOR_MAP.md sections for: the wizard/SesFileIconProvider icon color and sizing fixes, a stable-33.0 comparison (it avoids this by using neutral-color source SVGs plus separate black/white file variants rather than a single brand-colored SVG recolored at runtime), and the SecondaryButtonStyle focus color fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two more dark-mode findings from live testing: - SecondaryButtonStyle::buttonFocusedBorderColor() used a fairly saturated blue-grey vs. the bright white default border. Since autoDefault buttons keep focus after a click (normal Qt behavior), that made a just-clicked button look permanently "selected" rather than briefly focused. Blended it halfway toward the default border color instead - no confirmed design token for this, a maintained approximation per user preference. - WizardCommon::customizeHintLabel() (owncloudwizardcommon.cpp) dimmed whatever QPalette::Text the label ambiently inherited by 50% alpha, called from the wizard page constructor before the widget's palette is reliably propagated to dark mode on every platform - reported unreadable on Linux (dimmed light-mode-dark text on a dark background). Switched to the already-theme-aware WLTheme.folderWizardPathColor() instead, used elsewhere in the wizard for the same muted/secondary text role. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Follow-up to SES-576, which disabled interaction (menu, focus, mouse events) but left the lock icon visible. Hide it outright instead.
borisbaltesbrickmakers
added
the
approved
use co.uk instead, since the .com endpoint is not available right now
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.