subagent transcript

session 17f09f89 · workflow wf_a3d8d75a

delegated task

CONTEXT: FreeCAD 26.3 compiled to WebAssembly (emscripten, single-thread, ASYNCIFY, static Qt 6.11.1 + OCCT + Coin3D + CPython 3.14, NO dlopen/subproc

▸ Magik

CONTEXT: FreeCAD 26.3 compiled to WebAssembly (emscripten, single-thread, ASYNCIFY, static Qt 6.11.1 + OCCT + Coin3D + CPython 3.14, NO dlopen/subprocess/threads). After a big push it now has 17 workbenches, numpy, Draft/TechDraw/Assembly all working. The 3D VIEWPORT RENDERS WELL (Coin3D -> WebGL via an offscreen FBO + QPainter blit). Toolbars/menus/tree are functional. THREE PROBLEM AREAS TO RESEARCH (be concrete, grep the real source + deploy, cite files): A) UNSTYLED UI (from a screenshot): the right "Tasks" panel (Gui::TaskView, shows "Start Part"/"New Body") has NO background — floating text on the 3D view. Context menus (right-click tree) are plain white, no hover highlight. NO hover states anywhere (buttons/menu items don't react on mouse-over). Font looks slightly oversized. This is the classic signature of FreeCAD's Qt STYLESHEET (.qss) + assets not being applied. FreeCAD ships stylesheets in src/Gui/Stylesheets/*.qss ("FreeCAD Dark.qss", "FreeCAD Light.qss", "Behave-*.qss") and the overlay/taskview qss; the active one is set by the preference MainWindow/StyleSheet and applied via qApp->setStyleSheet / Gui::Application. Icons/qss may be in a Qc qrc compiled into the wasm OR need FS packaging. B) The RENDER PERF hot path (from a profiler trace of a single mouse-wheel zoom = 96ms): dominated by Coin's IMMEDIATE-MODE GL emulation — emscripten's ffVertex/ffEnd/ffNormal3/ffColor4 (per-vertex glBegin/glVertex emulation) called from Coin scenegraph traversal (recursive wasm-function[15570]/[48370]), plus _glTexSubImage2D (~4ms, the FBO->texture blit) and _glReadPixels. deploy/index.html sets `COIN_VERTEX_ARRAYS=0` and `COIN_AUTO_CACHING=0` in Module.preRun ENV — these DISABLE Coin vertex arrays (forcing the slow immediate-mode path) and render caching. There are NO wasm debug symbols so wasm-function[N] can't be resolved. C) NEXT PARITY STAGES: (1) browser-reload PERSISTENCE is broken — IDBFS mount+hydrate work, but FreeCAD's user.cfg ParameterManager serializer is created in Application::bootstrapEarly()->LoadParameters() with a stale root path ("/user.cfg") before the real UserConfigPath is known; App.saveParameter() then writes to /user.cfg (or no-ops). An attempted fix re-pointed the serializer in LoadParameters()'s idempotent-guard using getUserConfigPath() but it did NOT work (user.cfg still not at /tmp/.config/FreeCAD/v26-3/). (2) CAM is blocked because pybind11 is absent from /opt/toolchains (CAM's area/tsp_solver need it). (3) BIM/Arch could partially load now that Draft+numpy exist (IFC needs ifcopenshell, but non-IFC Arch modeling may work). PATHS: FreeCAD source /home/magik6k/lcad-wasm/freecad-port/FreeCAD (git branch wasm-parity-push). wasm build tree /opt/toolchains/src/freecad-gui-build. deploy /home/magik6k/lcad-wasm/freecad-port/deploy (index.html + *.data + *.data.js — grep the .data.js manifests to see what's on the FS). Toolchain env: source /home/magik6k/lcad-wasm/env.sh. To check what's packaged: the .data.js files contain a JSON "files" manifest with "filename" paths. The base freecad.data mounts at /freecad (share at /freecad/share, modules at /freecad/Mod). getResourceDir()=/freecad/share/. Qt wasm plugin + qt.conf considerations apply. DIMENSION B — Qt-for-wasm platform issues behind the unstyled look. Investigate: 1. FONT: why does the font look oversized? Check the Qt wasm default font/DPI. Is there a devicePixelRatio / QT_SCALE_FACTOR / QT_FONT_DPI issue? Does index.html or the Qt wasm plugin set a scale? FreeCAD's default font size preference (General/FontSize)? Is a font database loaded (Qt wasm bundles a font)? Determine if the "big font" is DPI scaling or a default-font-size issue and the fix. 2. HOVER: "nothing reacts on mouse-over" — is this (a) missing QSS :hover styling (fixed by loading a stylesheet), or (b) a Qt-wasm event-delivery problem (enter/leave/hover events not delivered)? Check Qt wasm mouse event handling + whether FreeCAD relies on WA_Hover. Distinguish these — grep, reason about Qt wasm's known hover behavior. 3. Qt STYLE: what QStyle is active on wasm (Fusion? windows?)? Does FreeCAD set a style? A missing/basic style contributes to the plain look. 4. CONTEXT MENU: plain QMenu — styled purely by qss, or also style-dependent? Produce concrete fixes ranked by impact/effort and note which overlap with dimension A's stylesheet fix (so we don't double-count). Determine the ONE change that most improves the look.

Fable

thinking

I'm shifting focus to the Qt-for-wasm platform issues that might be causing the unstyled appearance—specifically looking at fonts, DPI scaling, hover event handling, QStyle configuration, and context menu behavior. Let me dig into the source code and test a deployment to see what's actually happening.

Fable

⚙ Bash

{"command": "cat /home/magik6k/lcad-wasm/freecad-port/deploy/index.html 2>/dev/null | head -300", "description": "Read deploy index.html"}

tool result

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>FreeCAD in your browser — WebAssembly</title>
<style>
  html, body { margin: 0; height: 100%; font-family: system-ui, "Segoe UI", sans-serif; background:#2b2b30; color:#eee; }
  #bar { position: fixed; top: 0; left: 0; right: 0; z-index: 20; display:flex; align-items:center; gap:12px;
         background:#1d1d21; border-bottom:1px solid #000; padding:6px 12  …[truncated]

Fable

⚙ Bash {"command": "ls -la /home/magik6k/lcad-wasm/freecad-port/deploy/ 2>/dev/null", "description": "List deploy dir"}

tool result

total 419988
drwxr-xr-x 1 magik6k magik6k      1070 Jul  5 22:26 [0m[01;34m.[0m
drwxr-xr-x 1 magik6k magik6k       742 Jul  5 23:19 [01;34m..[0m
-rw-r--r-- 1 magik6k magik6k       941 Jul  5 22:27 boot.py
-rw-r--r-- 1 magik6k magik6k  15229294 Jul  4 20:36 freecad.data
-rw------- 1 magik6k magik6k   8977277 Jul  4 20:36 freecad.data.gz
-rw-r--r-- 1 magik6k magik6k    135559 Jul  4 20:36 freecad.data.js
-rw------- 1 magik6k magik6k     17642 Jul  4 20:36 freecad.data.js.gz
-rw-r--r-- 1 magik  …[truncated]

Fable

thinking

I need to dig into boot.py to see if it's configuring fonts or styles, then check how Qt's WebAssembly platform handles DPI and device pixel ratios. I should also search the FreeCAD codebase for how it applies stylesheets and manages the main window appearance.

Fable

⚙ Bash {"command": "cat /home/magik6k/lcad-wasm/freecad-port/deploy/boot.py", "description": "Read boot.py"}

tool result

# Default deploy startup: demo document + report the now-available workbenches.
import FreeCAD as App, FreeCADGui as Gui
P = App.Console.PrintMessage
try:
    doc = App.newDocument("Demo")
    box = doc.addObject("Part::Box", "Box"); box.Length=20; box.Width=20; box.Height=20
    cyl = doc.addObject("Part::Cylinder", "Cyl"); cyl.Radius=7; cyl.Height=25
    cyl.Placement = App.Placement(App.Vector(10,10,-2), App.Rotation())
    cut = doc.addObject("Part::Cut", "Cut"); cut.Base=box; cut.Tool=cyl
   …[truncated]

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && git branch 2>/dev/null; echo \"---\"; ls src/Gui/Stylesheets/ 2>/dev/null", "description": "Check branch and stylesheets"}

tool result

  main
* wasm-parity-push
  wasm-port
---
CMakeLists.txt
defaults.qss
FreeCAD.qss
[0m[01;34mimages_classic[0m
[01;34mimages_dark-light[0m
[01;34moverlay[0m
[01;34mparameters[0m
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

I notice the stylesheets folder location doesn't match what I remembered, so I'm investigating how FreeCAD actually applies stylesheets and determines the default style by searching for key functions like setStyleSheet, setStyle, and checking how it handles QT_FONT_DPI and devicePixelRatio.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"setStyle\\b\\|setStyle(\" src/Gui/Application.cpp src/Gui/MainWindow.cpp src/App/Application.cpp 2>/dev/null | head -40", "description": "Grep setStyle usage"}

tool result

src/Gui/Application.cpp:3020:void Application::setStyle(const QString& name)
src/Gui/Application.cpp:3044:        qApp->setStyle(style);
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"StyleSheet\\|setStyleSheet\\|QStyleFactory\\|setStyle(\" src/Gui/*.cpp | grep -i \"style\" | head -60", "description": "Grep style handling in Gui"}

tool result

src/Gui/Application.cpp:45:#include <QStyleFactory>
src/Gui/Application.cpp:474:        {"ThemeStyleParametersFiles", "Theme", "StyleSheet"},
src/Gui/Application.cpp:479:            std::string sheet = hGrp->GetASCII("StyleSheet");
src/Gui/Application.cpp:482:            setStyleSheet(QString::fromStdString(sheet), tiledBG);
src/Gui/Application.cpp:2879:void Application::setStyleSheet(const QString& qssFile, bool tiledBackground)
src/Gui/Application.cpp:2916:    mw->setProperty("fc_currentStyleS  …[truncated]

Fable

thinking

I need to look at StartupProcess.cpp, specifically the setStyleSheet() and setStyle() methods, and check what the default StyleSheet preference and style values are around lines 300-560.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && sed -n '110,160p;300,360p;520,570p' src/Gui/StartupProcess.cpp", "description": "Read StartupProcess style setup"}

tool result

    }
    // By default (on platforms that support it, see docs for
    // Qt::AA_CompressHighFrequencyEvents) QT applies compression
    // for high frequency events (mouse move, touch, window resizes)
    // to keep things smooth even when handling the event takes a
    // while (e.g. to calculate snapping).
    // However, tablet pen move events (and mouse move events
    // synthesised from those) are not compressed by default (to
    // allow maximum precision when e.g. hand-drawing curves)  …[truncated]

Fable

thinking

So `setStyleSheet()` pulls from the "StyleSheet" preference, and if that's empty it falls back to the branding config. When both are empty, no stylesheet gets applied at all, which is why the interface looks unstyled. I'm checking what the default StyleSheet value should be in the recent FreeCAD versions to see if something's changed there.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && sed -n '2879,3050p' src/Gui/Application.cpp", "description": "Read setStyleSheet + setStyle"}

tool result

void Application::setStyleSheet(const QString& qssFile, bool tiledBackground)
{
    Gui::MainWindow* mw = getMainWindow();
    auto mdi = mw->findChild<QMdiArea*>();
    mdi->setProperty("showImage", tiledBackground);

    // Qt's style sheet doesn't support it to define the link color of a QLabel
    // or in the property editor when an expression is set because therefore the
    // link color of the application's palette is used.
    // A workaround is to set a user-defined property to e.g. a   …[truncated]

Fable

thinking

Even without a custom theme file, the default stylesheet from the qss resource path gets applied automatically, which means there's always a baseline styling in place. I need to verify whether defaults.qss is actually compiled into the resource file and check how the qss search paths are configured to locate it.

The real issue is that applying any stylesheet variables requires the styleParameterManager to replace those variables in the qss content. In FreeCAD 1.1, there's a default StyleSheet preference that gets set—likely something like "FreeCAD Dark"—so I should check what the default parameter value is for MainWindow/StyleSheet in the preferences configuration.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"StyleSheet\" src/Gui/Stylesheets/CMakeLists.txt; echo \"=== defaults.qss head ===\"; sed -n '1,60p' src/Gui/Stylesheets/defaults.qss", "description": "Check defaults…

tool result

=== defaults.qss head ===
/*
 * This is a file with default QSS styles that will be preincluded for all themes. It should cover only the styles for
 * our own controls and not alter visuals of stuff like buttons etc. This is created so we can use QSS to add color
 * to links or control certain aspects of program looks that should be shared across all styles, including classic.
 */

/* Gui::SplitButton --------------------------------------------------------- */

Gui--SplitButton QToolButton[spli  …[truncated]

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"stylesheets\\|Stylesheets\\|defaults.qss\\|FreeCAD.qss\" src/Gui/*.qrc src/Gui/Icons/*.qrc 2>/dev/null | head; echo \"=== find qrc with stylesheets ===\"; grep -rln …

tool result

(eval):1: no matches found: src/Gui/*.qrc
=== find qrc with stylesheets ===
(eval):1: no matches found: --include=*.qrc
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

So the defaults.qss file explicitly doesn't style buttons and other elements—that's handled by the actual theme file with color parameters. This means the default StyleSheet parameter is what creates the visual appearance. I need to track down where the qss files are installed in the resource directory and check if they're accessible on the WebAssembly filesystem, so I'm searching the manifest files for stylesheet references.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/deploy && grep -o '\"[^\"]*Stylesheets[^\"]*\"' *.data.js 2>/dev/null | sort -u | head -40; echo \"=== count ===\"; grep -c \"Stylesheets\" *.data.js 2>/dev/null", "description": "Grep St…

tool result

freecad.data.js:"/freecad/share/Gui/Stylesheets"
freecad.data.js:"/freecad/share/Gui/Stylesheets/defaults.qss"
freecad.data.js:"/freecad/share/Gui/Stylesheets/FreeCAD.qss"
freecad.data.js:"/freecad/share/Gui/Stylesheets/images_classic/arrow-double-leftright-black.png"
freecad.data.js:"/freecad/share/Gui/Stylesheets/images_classic/arrow-double-leftright-black.svg"
freecad.data.js:"/freecad/share/Gui/Stylesheets/images_classic/arrow-double-leftright-blue.png"
freecad.data.js:"/freecad/share/Gui/St  …[truncated]

Fable

thinking

The stylesheet files are actually present in the filesystem, but the real problem is that a fresh user configuration has no StyleSheet preference set, and there's no default branding stylesheet to fall back on. When an empty stylesheet gets applied, it only loads the base defaults.qss which deliberately skips styling buttons and menus, resulting in that unstyled appearance.

I'm realizing there's a persistence issue too—the user.cfg isn't being saved, so every boot starts fresh with an empty StyleSheet parameter. The stylesheet fix (setting it to "FreeCAD.qss" or applying a theme) could be handled in boot.py, but that runs after startup when the stylesheet is already applied, so I'd need to   …

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"FontSize\\|setFont\\|QFont\\|pointSize\\|application.*[Ff]ont\" src/Gui/StartupProcess.cpp src/Gui/Application.cpp src/Main/*.cpp 2>/dev/null | head -30", "descripti…

tool result

zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rln \"FreeCADStyle\" src/Gui/ | head; echo \"===\"; grep -rn \"QT_FONT_DPI\\|QT_SCALE_FACTOR\\|devicePixelRatio\\|QT_AUTO_SCREEN\\|HighDpi\\|EnableHighDpiScaling\\|QT_ENA…

tool result

src/Gui/FreeCADStyle.h
src/Gui/FreeCADStyle.cpp
src/Gui/CMakeLists.txt
src/Gui/Application.cpp
src/Gui/StartupProcess.cpp
===
src/Gui/GLPainter.cpp:155:        const qreal dpr = glWidget->devicePixelRatioF();
src/Gui/MouseSelection.cpp:301:        qreal dpr = _pcView3D->getGLWidget()->devicePixelRatioF();
src/Gui/MouseSelection.cpp:514:        qreal dpr = _pcView3D->getGLWidget()->devicePixelRatioF();
src/Gui/BitmapFactory.cpp:511:    qreal dpr1 = p1.devicePixelRatio();
src/Gui/BitmapFactory.  …[truncated]

Fable

thinking

I'm searching through FreeCAD's GUI code to understand how the General/FontSize preference gets applied at the application level, looking for references to FontSize and setFont calls.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"FontSize\\|setFont(\\|QApplication::setFont\\|qApp->setFont\" src/Gui/ 2>/dev/null | grep -iv \"editor\\|report\\|python\\|console\\|dialog\" | head -30", "descripti…

tool result

src/Gui/ElideLabel.cpp:40:    painter.setFont(font());
src/Gui/InventorAll.h:109:#include <Inventor/elements/SoFontSizeElement.h>
src/Gui/SoDatumLabel.cpp:386:    painter.setFont(font);
src/Gui/InputHintWidget.cpp:158:    painter.setFont(font);
src/Gui/NotificationBox.h:111:    static void setFont(const QFont&);
src/Gui/NaviCube.h:63:    void setFont(std::string font);
src/Gui/NaviCube.cpp:289:void NaviCube::setFont(std::string font)
src/Gui/NaviCube.cpp:732:    qreal minFontSize = texSize;
src  …[truncated]

Fable

thinking

So the oversized font issue stems from Qt's WebAssembly implementation rather than FreeCAD's preferences—Qt for wasm uses its platform's reported DPI to convert point sizes to pixels, and historically defaults to a specific logical DPI that's causing the scaling problem.

Qt for WebAssembly bundles a limited font set, so when FreeCAD requests a font family that isn't available, Qt falls back to a bundled font like Bitstream Vera Sans, which may render at a larger size. The default application font on wasm is typically Helvetica at some point size, determined by Qt's platform theme integration. I need to dig into the Qt wasm source code to understand exactly how the DPI and font metrics are b  …

Fable

⚙ Bash

{"command": "source /home/magik6k/lcad-wasm/env.sh 2>/dev/null; ls /opt/toolchains/ 2>/dev/null; echo \"=== find qwasm platform ===\"; find /opt/toolchains -path \"*platforms/wasm*\" -name \"*.cpp\" 2>/dev/null | head; find /opt/toolchains …

tool result

[0m[01;34mboost-wasm[0m
[01;34memsdk[0m
fix-freetype-sjlj.sh
[01;34mfmt-wasm[0m
[01;34mfreecad-gui-web[0m
[01;34mgtest-wasm[0m
[01;34micu-wasm[0m
[01;34minclude[0m
[01;34mocct-wasm[0m
[01;34moscad-deps[0m
[01;34moscad-src[0m
[01;34mpyside-host[0m
[01;34mpython-wasm[0m
[01;34mqt[0m
[01;34mqt-asyncify[0m
[01;34mqt-jspi[0m
[01;34mqtsrc[0m
[01;32mrebuild-deps-407.sh[0m
rebuild-deps-jseh.sh
[01;32mrebuild-deps-wasmeh.sh[0m
rebuild-qt-asyncify-412.sh
[01;32mrebuil  …[truncated]

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && grep -n \"logicalDpi\\|Dpi\\|dpi\\|96\\|devicePixelRatio\\|LogicalDpi\\|physicalSize\\|geometry\" qwasmscreen.cpp | head -40", "description": "Grep DPI in qwasmscree…

tool result

142:QRect QWasmScreen::geometry() const
144:    return m_geometry;
157:QDpi QWasmScreen::logicalDpi() const
159:    emscripten::val dpi = emscripten::val::module_property("qtFontDpi");
160:    if (!dpi.isUndefined()) {
161:        qreal dpiValue = dpi.as<qreal>();
162:        return QDpi(dpiValue, dpiValue);
164:    const qreal defaultDpi = 96;
165:    return QDpi(defaultDpi, defaultDpi);
168:qreal QWasmScreen::devicePixelRatio() const
170:    // window.devicePixelRatio gives us the scale factor  …[truncated]

Fable

thinking

Looking at how `Module.qtFontDpi` controls the logical DPI, which defaults to 96 DPI if not set—at that resolution, a 9 or 10 point font would scale to around 12 pixels, which should be normal size. But the font appears oversized, likely due to how the devicePixelRatio scaling is being applied. Let me trace through the devicePixelRatio calculation to understand what's happening.

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && sed -n '168,200p' qwasmscreen.cpp; echo \"=== theme font ===\"; grep -n \"font\\|Font\\|pointSize\\|pixelSize\" qwasmtheme.cpp 2>/dev/null | head -30", "description"…

tool result

qreal QWasmScreen::devicePixelRatio() const
{
    // window.devicePixelRatio gives us the scale factor between CSS and device pixels.
    // This property reflects hardware configuration, and also browser zoom on desktop.
    //
    // window.visualViewport.scale gives us the zoom factor on mobile. If the html page is
    // configured with "<meta name="viewport" content="width=device-width">" then this scale
    // factor will be 1. Omitting the viewport configuration typically results on a zoo  …[truncated]

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && sed -n '40,135p' qwasmtheme.cpp", "description": "Read qwasmtheme font construction"}

tool result

Qt::ContrastPreference getContrastPreferenceFromMedia()
{
    if (matchMedia(contrastPreferenceMore)) {
        return Qt::ContrastPreference::HighContrast;
    } else {
        return Qt::ContrastPreference::NoPreference;
    }
}
} // namespace

using namespace Qt::StringLiterals;

QWasmTheme::QWasmTheme()
{
    m_colorScheme = getColorSchemeFromMedia();
    qCDebug(lcQpaThemeWasm) << "Initializing Wasm theme. Color scheme: " << m_colorScheme;
    m_contrastPreference = getContrastPreferenceFro  …[truncated]

Fable

thinking

I'm finding some key insights here. The Fusion style is actually the default on WebAssembly and it does support hover effects, which are enabled at the theme level. However, the font system is falling back to hardcoded defaults since the theme isn't providing a general font, so Qt uses Helvetica as the base typeface.

The real issue is that font sizing on WebAssembly depends on the logical DPI (which defaults to 96) and the default point size, which is why text often appears oversized. The most practical solution would be to either set the application font explicitly or adjust the `qtFontDpi` value to something lower like 72 or 80 to scale fonts down. I should also check whether FreeCAD's Ge  …

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"setFont\\|GetInt(\\\"FontSize\\|applicationFont\\|app_font\\|QApplication::font\\|QApplication::setFont\" src/Gui/DlgGeneralImp.cpp src/Gui/PreferencePages/*.cpp 2>/…

tool result

src/Gui/PreferencePages/DlgSettingsEditor.cpp:279:    ui->fontSize->setValue(hGrp->GetInt("FontSize", ui->fontSize->value()));
src/Gui/PreferencePages/DlgSettingsEditor.cpp:365:    ui->textEdit1->setFont(ft);
src/Gui/PreferencePages/DlgSettingsWorkbenchesImp.cpp:129:    textLabel->setFont(font);
=== broad ===
src/Gui/NotificationBox.cpp:451:    QApplication::setFont(font, "NotificationLabel");
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

FreeCAD isn't setting a global application font—the oversized text is coming from Qt-for-wasm's default font settings. I'm trying to figure out what Qt's actual default point size is on wasm, specifically how QGuiApplication determines the default font when the platform theme doesn't provide one.

The practical issue is that on wasm, without a platform theme font, Qt falls back to its built-in default of around 12pt, which at 96 dpi translates to roughly 16px—much larger than the typical 9pt desktop default. The solution is to explicitly set the application font rather than relying on these defaults.

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase && grep -rn \"defaultPointSize\\|pointSize = 12\\|pointSize(12)\\|setPointSize(12\\|= 12.0\\|Times.*12\\|Helvetica\" src/gui/text/qfont.cpp src/gui/kernel/qguiapplication.cpp 2>/dev/null | head; …

tool result

src/gui/text/qfont.cpp:67:      us to compare e.g. "Helvetica" and "Helvetica [Adobe]" with
src/gui/text/qfont.cpp:556:    If you had both an Adobe and a Cronyx Helvetica, you might get
src/gui/text/qfont.cpp:562:    in the above example will be set to "Helvetica
src/gui/text/qfont.cpp:714:    e.g. "Helvetica [Cronyx]". If the \a family is
src/gui/text/qfont.cpp:731:        pointSize = 12;
src/gui/text/qfont.cpp:761:     a foundry name, e.g. "Helvetica [Cronyx]". If the family is
src/gui/text/qf  …[truncated]

Fable

thinking

Looking at the qfont.cpp code, I can see that the default point size is hardcoded to 12pt, which translates to 16px at 96 DPI — noticeably larger than the typical 9-10pt used on desktop Linux. The issue is that on WebAssembly, the system theme font is null, so Qt falls back to this oversized default instead of respecting the platform's preferred font size.

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase && grep -n \"app_font\\|SystemFont\\|font(.*Font)\\|QFont(\" src/gui/kernel/qguiapplication.cpp | grep -i font | head -20", "description": "Trace app_font default"}

tool result

197:Q_CONSTINIT QFont *QGuiApplicationPrivate::app_font = nullptr;
227:    if (!QGuiApplicationPrivate::app_font) {
229:            if (const QFont *font = theme->font(QPlatformTheme::SystemFont))
230:                QGuiApplicationPrivate::app_font = new QFont(*font);
232:    if (!QGuiApplicationPrivate::app_font)
233:        QGuiApplicationPrivate::app_font =
234:            new QFont(QGuiApplicationPrivate::platformIntegration()->fontDatabase()->defaultFont());
239:    delete QGuiApplicationP  …[truncated]

Fable

thinking

When the system font is null in the wasm environment, it falls back to the platform's default font, which I need to trace through the font database to see what it actually returns—likely a standard 12-point QFont.

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase && grep -rn \"defaultFont\" src/gui/text/qplatformfontdatabase.cpp; sed -n '/QFont QPlatformFontDatabase::defaultFont/,/^}/p' src/gui/text/qplatformfontdatabase.cpp", "description": "Check platfo…

tool result

src/gui/text/qplatformfontdatabase.cpp:387:QFont QPlatformFontDatabase::defaultFont() const
QFont QPlatformFontDatabase::defaultFont() const
{
    return QFont("Helvetica"_L1);
}
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

The default Helvetica 12pt font is rendering at 16px on WebAssembly due to the 96 DPI scaling, which explains the oversized appearance. I can fix this either by setting a smaller explicit font size like 9 or 10 points through QApplication, or by lowering the Module.qtFontDpi value to 72 to scale down the 12pt default appropriately.

The qtFontDpi approach is particularly elegant since setting it to 72 makes the default 12pt render at 12px (matching desktop behavior where 9pt at 96 DPI equals 12px), and this can be done with a single line in index.html without rebuilding the WebAssembly binary. This affects font rendering and DPI-dependent layout uniformly across the application.

Now I'm inv  …

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && grep -n \"Enter\\|Leave\\|enter\\|leave\\|pointerover\\|pointerout\\|mouseover\\|PointerEnter\\|handleMouse\\|MouseMove\\|pointermove\\|HoverMove\\|processMouse\" qw…

tool result

qwasmevent.h:27:    DragEnter,
qwasmevent.h:28:    DragLeave,
qwasmevent.h:35:    PointerEnter,
qwasmevent.h:36:    PointerLeave,
qwasmevent.h:112:                    QEvent::MouseMove : QEvent::NonClientAreaMouseMove;
qwasmwindow.cpp:167:    m_pointerMoveCallback = QWasmEventHandler(m_window, "pointermove",
qwasmwindow.cpp:176:    m_pointerEnterCallback = QWasmEventHandler(m_window, "pointerenter",
qwasmwindow.cpp:177:        [this](emscripten::val event) { this->handlePointerEnterLeaveEvent(Po  …[truncated]

Fable

thinking

Qt's wasm implementation routes pointermove events through handleMouseEvent for MouseMove, while pointerenter and pointerleave are handled at the window level. QApplication then synthesizes widget-level enter/leave events from those mouse movements, so hover states should propagate correctly through the widget hierarchy. The catch with FreeCAD's wasm build is that its 3D view renders to an offscreen framebuffer object, which complicates how mouse events interact with that rendering surface.

But actually, I'm realizing the real issue might not be about event delivery at all. When FreeCAD applies defaults.qss as an application-wide stylesheet, Qt wraps the base Fusion style in QStyleSheetStyl  …

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && sed -n '330,360p' qwasmwindow.cpp; echo \"=== deliverUpdateRequest / hover throttle ===\"; grep -n \"mouseInWindow\\|m_mouseInWindow\\|deliverUpdate\\|HoverMove\\|ho…

tool result

void QWasmWindow::onMaximizeClicked()
{
    window()->setWindowState(Qt::WindowMaximized);
}

void QWasmWindow::onToggleMaximized()
{
    window()->setWindowState(m_state.testFlag(Qt::WindowMaximized) ? Qt::WindowNoState
                                                                   : Qt::WindowMaximized);
}

void QWasmWindow::onCloseClicked()
{
    window()->close();
}

void QWasmWindow::onNonClientAreaInteraction()
{
    requestActivateWindow();
    QGuiApplicationPrivate::instance()->clos  …[truncated]

Fable

thinking

I'm examining the handlePointerMoveEvent function in the client area section around line 360-420.

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && sed -n '360,430p' qwasmwindow.cpp", "description": "Read client pointer handling"}

tool result

            MouseEvent::mouseEventTypeFromEventType(event.type, WindowArea::NonClient),
            event.modifiers);
}

void QWasmWindow::initialize()
{
    auto initialGeometry = QPlatformWindow::initialGeometry(window(),
            windowGeometry(), defaultWindowSize, defaultWindowSize);
    m_normalGeometry = initialGeometry;

    setWindowState(window()->windowStates());
    setWindowFlags(window()->flags());
    setWindowTitle(window()->title());
    setMask(QHighDpi::toNativeLocalRegion(  …[truncated]

Fable

thinking

I'm tracing through the pointer event handling in Qt WebAssembly—the pointermove handler delivers MouseMove events, and enter/leave events are also being dispatched properly. Now I'm reconsidering the overall approach and looking at how QWasmWindow::paint() works, which seems to be a key piece of the behavior.

The rendering path uses a backing store that gets blitted to a 2D canvas via putImageData, and when a button's hover state changes, it triggers update() which requests a repaint. This should theoretically work for hover effects. So the real issue isn't that hover events aren't being delivered—they are—but rather that without the FreeCAD.qss theme stylesheet, the visual feedback is min  …

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"QtStyle\\|AA_Enable\\|HighDpiScaling\\|AA_Use\\|setAttribute\" src/Gui/StartupProcess.cpp src/Main/MainGui.cpp src/Gui/Application.cpp 2>/dev/null | head -20; echo \…

tool result

src/Gui/StartupProcess.cpp:70:    QCoreApplication::setAttribute(Qt::AA_ShareOpenGLContexts);
src/Gui/StartupProcess.cpp:71:    QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
src/Gui/StartupProcess.cpp:83:        QApplication::setAttribute(Qt::AA_DisableHighDpiScaling);
src/Gui/StartupProcess.cpp:89:        QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
src/Gui/StartupProcess.cpp:100:    QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps);
src/Gui/StartupProcess.cpp:  …[truncated]

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && sed -n '75,101p' src/Gui/StartupProcess.cpp; echo \"=== wasm block Application.cpp 2733 ===\"; sed -n '2700,2760p' src/Gui/Application.cpp", "description": "Read HighDPI decisi…

tool result

        "User parameter:BaseApp/Preferences/HighDPI"
    );
    bool disableDpiScaling = hDPI->GetBool("DisableDpiScaling", false);
    if (disableDpiScaling) {
#ifdef FC_OS_WIN32
        SetProcessDPIAware();  // call before the main event loop
#endif
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
        QApplication::setAttribute(Qt::AA_DisableHighDpiScaling);
#endif
    }
    else {
        // Enable automatic scaling based on pixel density of display (added in Qt 5.6)
#if QT_VERSION < QT_VERSIO  …[truncated]

Fable

thinking

The HighDPI scaling attributes are all conditional on Qt versions before 6, so they don't apply to Qt6 where scaling is always enabled. For the QtStyle default, when it's empty, the style factory receives an empty string which doesn't match "FreeCAD" or "System", so it returns nullptr.

With no explicit style set, Fusion remains as the default. The most impactful improvement would be applying the FreeCAD theme stylesheet, though for this specific dimension the font DPI setting (around 72-80 in the index.html) is the standalone fix that directly addresses the oversized font issue without requiring a rebuild.

I'm checking whether the context menu styling is affected by the app stylesheet. Whe  …

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -n \"QMenu\\|QToolButton\\b\\|QPushButton\\|^\\*\\|QWidget\\|:hover\\|QAbstractItemView\\|QTreeView\" src/Gui/Stylesheets/defaults.qss; echo \"=== total lines ===\"; wc -l…

tool result

9:Gui--SplitButton QToolButton[splitRole="menu"] {
17:Gui--SplitButton QToolButton::menu-indicator {
=== total lines ===
20 src/Gui/Stylesheets/defaults.qss
=== FreeCAD.qss has hover? ===
88
35
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

So defaults.qss only modifies the SplitButton styling, which means when the theme is empty, the app stylesheet consists solely of those splitbutton rules. QStyleSheetStyle wraps around Fusion, delegating everything else to Fusion's native rendering. This means buttons get their hover states from Fusion's State_MouseOver, menus are styled by Fusion with blue highlights on interaction, and tree widgets use Fusion's selection and hover behavior.

But the user's report describes plain white menus with no hover effects at all — which contradicts what bare Fusion should produce. This makes me wonder if the stylesheet isn't being applied on WebAssembly at all, or if the theme is actually something   …

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -rn \"StyleSheet\" src/App/Application.cpp src/Main/*.cpp | grep -i \"default\\|config\\|=\\\"\" | head; echo \"=== branding/config default ===\"; grep -rn \"\\\"StyleShee…

tool result

=== branding/config default ===
(eval):1: no matches found: src/Gui/DlgSettings*
=== defaultpref packs ===
FreeCAD Dark.yaml
FreeCAD Light.yaml
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

Themes are applied through preference packs stored as YAML files that set the StyleSheet parameter and color values. In a fresh FreeCAD installation, the default theme is typically applied, but in this WASM build without persisted configuration, the StyleSheet parameter appears to be...

Let me check if those parameter YAML files are actually packaged in the WASM filesystem by searching the data manifest for "parameters" and ".yaml" references.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/deploy && grep -o '\"[^\"]*\\(parameters\\|\\.yaml\\)[^\"]*\"' *.data.js 2>/dev/null | sort -u | grep -i \"stylesheet\\|yaml\\|parameter\" | head", "description": "Check theme parameter y…

tool result

freecad.data.js:"/freecad/share/Gui/Stylesheets/parameters/FreeCAD Dark.yaml"
freecad.data.js:"/freecad/share/Gui/Stylesheets/parameters/FreeCAD Light.yaml"
freecad.data.js:"parameters"
zshexit:1: parameter HISTDB_FD does not contain a file descriptor

Fable

thinking

The theme parameters are already packaged, so the StyleSheet preference just needs to be set. I can fix this by using Python in boot.py to retrieve the preferences and apply the theme setting through the parameter system.

However, applying the preference pack "FreeCAD Dark" would be cleaner since it sets both the StyleSheet parameter and the color parameters that the style system uses. The theme yaml file specifies which StyleSheet value to use, so I should check that yaml to give the exact command for the report.

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && grep -n \"StyleSheet\\|\\.qss\\|name:\\|MainWindow\" \"src/Gui/Stylesheets/parameters/FreeCAD Dark.yaml\" | head; echo \"=== how prefpack applies (SetString StyleSheet) ===\"; …

tool result

=== how prefpack applies (SetString StyleSheet) ===
src/Gui/PreferencePackManager.cpp:91:bool PreferencePack::apply() const
src/Gui/PreferencePackManager.cpp:120:    applyConfigChanges();
src/Gui/PreferencePackManager.cpp:148:void PreferencePack::applyConfigChanges() const
src/Gui/PreferencePackManager.cpp:372:bool PreferencePackManager::apply(const std::string& preferencePackName) const
src/Gui/PreferencePackManager.cpp:378:        bool wasApplied = preferencePack->second.apply();
zshexit:1: pa  …[truncated]

Fable

⚙ Bash

{"command": "cd /home/magik6k/lcad-wasm/freecad-port/FreeCAD && sed -n '1,30p' \"src/Gui/Stylesheets/parameters/FreeCAD Dark.yaml\"", "description": "Peek theme yaml head"}

tool result

3DViewBackgroundRefColor: "@BackgroundColor"
ButtonBackgroundHooverColor: "@ButtonTopBackgroundColor"
ButtonBorderColor: "@GeneralBorderColor"
ButtonBorderHooverColor: "@GeneralBorderColor"
ButtonBottomBackgroundColor: "@PrimaryColorLighten2"
ButtonTopBackgroundColor: "@PrimaryColorLighten3"
CheckedButtonBottomBackgroundColor: "darken(@ButtonBottomBackgroundColor, 5)"
CheckedButtonTopBackgroundColor: "darken(@ButtonTopBackgroundColor, 5)"
DefaultButtonBottomBackgroundColor: "blend(@ButtonBottomB  …[truncated]

Fable

thinking

So the prefpack applies the color parameters and sets the StyleSheet to "FreeCAD.qss", then reloadStyleSheet completes the dark theme with all the styling for hovers, task panels, and menus. I need to verify what the actual StyleSheet value is.

For the boot.py recipe, the simplest approach mirrors what the Preferences dialog does: apply the prefpack, set the StyleSheet parameter, and reload. That's the complete fix for dimension A.

Now I'm moving into dimension B findings. The font oversizing stems from Qt-for-wasm lacking a platform system font, so QWasmTheme returns nullptr and the fallback chain lands on Helvetica at 12pt with 96 logical DPI, which renders as 16px on screen compared to   …

Fable

I have enough evidence. Let me verify one more detail about the qtFontDpi read path to be precise.

Fable

⚙ Bash

{"command": "cd /opt/toolchains/qtsrc/qtbase/src/plugins/platforms/wasm && sed -n '157,167p' qwasmscreen.cpp; echo \"=== qwasmtheme font lines ===\"; sed -n '124,132p' qwasmtheme.cpp", "description": "Confirm qtFontDpi + theme font nullptr"…

tool result

QDpi QWasmScreen::logicalDpi() const
{
    emscripten::val dpi = emscripten::val::module_property("qtFontDpi");
    if (!dpi.isUndefined()) {
        qreal dpiValue = dpi.as<qreal>();
        return QDpi(dpiValue, dpiValue);
    }
    const qreal defaultDpi = 96;
    return QDpi(defaultDpi, defaultDpi);
}

=== qwasmtheme font lines ===
const QFont *QWasmTheme::font(Font type) const
{
    if (type == QPlatformTheme::FixedFont) {
        return fixedFont;
    }
    return nullptr;
}

bool QWasmThe  …[truncated]

Fable

thinking

Now I'm ready to generate the structured output.

Fable

⚙ StructuredOutput

{"area": "Dimension B — Qt-for-wasm platform issues behind the unstyled look (font/DPI, hover event delivery, active QStyle, context menus)", "rootCause": "Two independent roots. (1) OVERSIZED FONT is a genuine Qt-for-wasm default, not a DP…

tool result

Structured output provided successfully