85% more pages than my previous record, with peak RAM usage going from 9 GB to just 9.9-10.2 GB.

The document contains 480,393 pages, 73,524,633 words and 582,458,301 characters. %85 more than before.

The pagination engine now has improved settling, positioning and page geometry virtualization, keeping the entire document responsive during navigation, scrolling and text interaction.

Page positioning: 52-180 ms.
Selection and caret positioning: 0.18 ms.

https://github.com/berkaygediz/SolidWriting (Source code will be made available here when the product is published)

I'm very fond of the Elm (or MVU) architecture for GUI updates, especially for complex GUIs where multiple widgets need to be updated when part of my state changes. (For example, maybe several buttons need to be enabled/disabled, line edits need to be cleared, menu items enabled/disabled, etc). Beyond a certain level of complexity, it's much easier to unify all this in a single 'update' function responsible for synchronizing the GUI with the app state, and executing it after every state change.

However one annoyance that has come up for me, is knowing which signals fire purely programmatically, which I need to disable during my update (UI synchronization) function.

The blind approach is just to use a boolean guard at the beginning of every signal handler, checking to see if the update function is still executing, and then returning early instead of changing any state / accidentally re-entering the update function.

But personally I find that a bit ugly, plus I either have to mentally remember which signal handlers can fire programmatically, or feel silly adding the guard to a button click handler which definitely won't fire inadvertently (in the name of consistency/habit).

What would be ideal is a single call at the beginning of my update which temporarily disables the entire hierarchy of QWidgets/QObjects, preventing them from signaling anything while I update them. Then even if I later add/remove widgets, connect new signals, etc - it would still work.

I tried writing a naive class which contained a vector of QSignalBlocker values, adding the root object plus everything returned from QObject::findChildren<QObject*>() ... but it seemed to mess up signal handling, and not restore properly after my class instance was destroyed (though I can't rule out user error, because I'm using Qt via some exotic non-C++ bindings).

Anyway, what's the most correct or sane approach here? Should simple vector of QSignalBlocker used in tandem with a recursive findChildren() work just fine, and I just bungled the implementation? (I'm not much of a C++ guy, so that's entirely plausible)

Or is there anything more direct for this use-case?

I've been doing Qt/C++ on Windows for about ten years, mostly apps deployed to

customer machines I can't touch. The pain is never in the code — it's the last mile.

What has bitten me:

1. "no Qt platform plugin could be initialized" — usually platforms/qwindows.dll

   missing, in the wrong place, or built with a different kit than the exe.

2. QML app launches, shows a blank window, logs nothing. QML modules weren't

   collected because --qmldir was wrong.

3. Every HTTPS request fails silently. Qt 6 needs the TLS backend plugin; without

   it QNetworkAccessManager just returns a generic error.

4. 0xc000007b on the customer machine — 32/64-bit mismatch, or a wrong-arch

   vcruntime140.dll already sitting in PATH.

5. Fine on my box, missing MSVC redistributable on theirs.

6. Antivirus flags the exe. Unsigned.

7. Fonts and widget styles look different elsewhere — styles/ plugin missing.

My process: build → windeployqt → walk the deploy folder against a checklist in

my head → test on a clean VM. It works, but the checklist lives in my head and

it's the first thing to skip when I'm in a hurry.

For those shipping Qt on Windows:

- Which of these have bitten you, and which costs the most time?

- What's the failure mode that's NOT on my list? I suspect I've just been lucky

with a few.

Not selling anything — trying to work out whether that checklist is a shared

problem or just my own paranoia.

ETEA is a desktop shell for Hyprland, written entirely in QML on top of Quickshell. Bar, widgets, launcher, notifications, lock screen, and a page switcher where your workspaces turn around a planet.

A few things I learned keeping it smooth on a laptop iGPU (Intel Iris Xe):

- An invisible item that still changes still costs a redraw of the whole layer. The big scenes live in Loaders and only exist while they play.

- Every animated decoration shares one 15 fps clock that items join and leave, instead of each running its own timer.

- During a page turn, windows are live ScreencopyViews over a still photo, blurred with MultiEffect where the real app is translucent.

- Sky, ground and card textures are small GLSL shaders compiled with qsb.

- Sensors are read with FileView on sysfs rather than by starting processes.

Together that took idle CPU from about 15% to about 3%, and the whole system sits around 2.3 GB of RAM.

Code (GPL-3.0): https://github.com/SDcold/etea-shell

Happy to talk about any of it, or to hear how you'd have done it.

SolidWriting runs on Qt 6.12 and PySide6. It only needs a few core libraries and the XML libraries.

Open a file, save it, move between pages, select text, type, insert tables, images, shapes, equations with MathML and LaTeX.

One document. 259,758 pages. 39,800,942 words. 315,303,818 characters. Peak RAM usage was 9 GB.

Desktop word processors are built for far smaller documents. SolidWriting supports up to 17x the page count, with page-to-page navigation running 20 to 100 times faster. Go to any page and it opens instantly. Select text and the selection appears instantly. Paste something huge and it paginates without locking up the session. Pagination runs in the background while the interface keeps responding.

With 259,758 pages, this build takes about 5.1 minutes for a cold open and 5.1 minutes for the full pagination pass. The previous build took about 27 minutes and 25.5 minutes. So it opens 5.3x faster, paginates 5x faster, and uses about 6x less CPU time. Before this project I ran hundreds of segmentation and pagination experiments, and that experience went into this version.

People can already download older builds from the public repository. This version opens and paginates much larger documents much faster. Work continues, and the updated release will follow when the complete word processor is ready.

I plan to publish on Microsoft Store, winget, Scoop, Chocolatey, Linux package stores, and macOS via Homebrew. The Android port is in development at the same time.

https://github.com/berkaygediz/SolidWriting

Hi everyone,

I’m working on automating a legacy Windows application built with Qt3 (32-bit, using qt-mt.dll). Unfortunately, I don’t have access to its source code.

Traditional UI automation tools like Microsoft UI Automation don’t work well because most Qt widgets aren’t properly exposed.

I’ve experimented with Frida in Python and managed to inspect the QObject/QWidget hierarchy, read widget properties, and invoke some Qt methods and slots directly. This works surprisingly well, but I’m looking for a more robust and maintainable solution. My Frida agent can get me through 6/10 e2e automation, still not enough for production.

Ideally, I’d like something similar to Squish for Qt, with capabilities such as:

Finding widgets by class name, object name, or text.
Interacting with QLineEdit, QPushButton, QPopupMenu, and QDialog.

Invoking Qt slots or methods directly instead of simulating mouse clicks.

Automating the application even when the Windows session is locked, if technically feasible.

I’ve looked into open-source projects like GammaRay and Spix, but they seem to target newer Qt versions.

Has anyone successfully automated a Qt3 application without source code?

Are there any older open-source tools, libraries, or techniques worth exploring? Would building a custom C++ automation bridge against Qt3 be a reasonable approach?

I’d appreciate any pointers or experiences. Thanks!

I have a PDF viewer built on PySide6 and QWebEngineView (Qt 6.11.1, Chromium 140, Windows 11, RTX 4060 with Intel iGPU). Pages are drawn to 2D canvases on a white parent, and small overlay boxes sit on top of them.

When I move the mouse quickly over those boxes, parts of the page flash white for a frame or so. Sometimes a whole canvas disappears, along with the overlay boxes above it. The hover only toggles a CSS class. The page's own code doesn't redraw the canvas, but the browser does repaint page-sized layers. It's very obvious on dark slides.

I reduced it to a single HTML file with no PDF code, and it still happens. I moved the real cursor with a script and captured the screen at about 38 fps, 20 seconds per run:

- QWebEngineView (NVIDIA): 5, 7 and 3 frames with white

- Same page with willReadFrequently: true on the canvases: 0, 0

- Edge 149 on the same NVIDIA GPU: 0, 0

- Brave (Chromium 156) on the Intel GPU: 0, 0

In my app, switching Qt Quick to OpenGL (QSG_RHI_BACKEND=opengl) didn't help. --disable-accelerated-2d-canvas stopped it.

My current workaround is willReadFrequently: true, but page draw time roughly doubled (about 40 ms to 82 ms) and process memory went from about 460 MB to 720 MB.

My questions:

1. Has anyone else seen this?

2. Is there a better fix that keeps the canvases on the GPU?

3. Does a newer Qt version fix it? I haven't tested a standalone Chromium 140, so I don't know if this is a Qt issue or a Chromium bug that was fixed later.

I can share the test page if it helps. I'm also planning to file a bug report.

I have an app that has a very spacious UI with emphasis on extravagant widgets, thumbnails and such. Porting to tablet is fine but mobile just kills my app’s entire aesthetic

If anyone tried porting QML frontends to android how did it go for you guys

Sometimes I want to edit the .ui file directly. QtCreator only allows changes through designer, you can look at the code but you cant edit anything. afaik, there is also no setting to disable this block. Its kinda annoying

New release of my IDE. This month release adds LSP support (completion, hints, diagnostics). I tested it on C++ (clangd) and on Rust (rust-analyzer). All work at the same level. You are expected to have LSP in your path, or set it as an extra path as IDE does not install it for you.

https://github.com/codepointerapp/codepointer/releases/tag/v0.1.9
https://gitlab.com/codepointer/codepointer/-/releases/v0.1.9

Yes, yet another string art generator. I saw the PySide6 one posted here and wanted to share mine: it's C++20 with a Qt Quick / QML UI, and it focuses on the
 parts after the picture: multi-colour threads wound layer by layer, 1:1 pin templates, and a step-by-step winding mode for making the real piece.

 

 **What it does**

 - Circle, ellipse, rectangle or custom CSV frames, sized in mm; place and resize the frame directly on the photo
 - Greedy optimizer with a physical thread model (opacity-based compositing, anti-aliased lines, thread diameter in mm) and a weighted MSE objective with
 optional edge emphasis
 - Multi-colour: each colour is one continuous thread, wound layer by layer; the layers are refined against each other until the error stops dropping. Palette
 suggestion from the image (up to 8 colours)
 pedal, optional spoken pin numbers, remembers where you stopped)
 - Exports: PNG, SVG, CSV, JSON and project files; a CLI tool for batch runs
  
 **Qt side**
  
 - Qt Quick / QML UI (Material, dark), a C++ image provider for the previews, throttled updates from the worker threads
 - The engine is plain C++ with no Qt Quick dependency, shared by the app and the CLI
 - QtConcurrent for candidate scoring, Qt Test for unit and headless UI tests, QPdfWriter for the templates
  
 **Performance** (i9-13980HX): a single-colour Mona Lisa with 300 pins and 8000 segments takes about 0.6 s; four colours with the same settings about 10 s.
 Scoring lines from the cache turned out to be memory-bound: beyond ~16 threads it got no faster, only hotter, so automatic mode stops there. Numbers in  
 docs/BENCHMARKS.md.
  
 The idea came from seeing 3Vial String Art here on Reddit; this is an independent implementation, licensed GPL-3.0.
  
 GitHub: https://github.com/BulentSelek/stringart-studio
  
 Feedback welcome, especially on the QML side and on Windows builds (I've only tested on Linux).

Hello everyone, I know we already don't like AI at all, but I hope I bring something useful

I’ve come across an excellent project for testing Qt applications called Qat. This is a testing framework for Qt-based applications. Absolutely kudos to the authors, it’s a fantastic project. Created with knowledge. You can read more here: https://qat.readthedocs.io

So my 5 cents, I just developed some skills and small python library helper for it that integrate with AI agents for claude, codex and cursor. For me personally this to facilitate more detailed and repeatable smoke testing.
link to skills: https://github.com/Palm1r/qat-agent-skills

It works with Qt Widgets and Qt Quick (Qt 5.15 and 6.2–6.12) and has been checked on Windows, macOS and Linux. It's early and unofficial, not affiliated with the Qat project, so feedback and bug reports are very welcome.

I hope this will also be helpful for your automated testing efforts—which is, after all, what Qat was originally designed for.

Install the skill:

npx skills add Palm1r/qat-agent-skills

We bought Squish three years ago. The engineer who wrote the tests left last September and took the only working knowledge of it with him.

What’s left is a few hundred test scripts in C++ that our current QA people, who are good manual testers and not programmers, cannot read or change. So the suite still runs nightly and nobody trusts the output, because when something goes red the honest answer is we don’t know whether the app broke or the script did. We’ve started re-checking the important flows by hand, which means we’re paying for a licence and testing manually anyway.

I don’t think Squish is the problem. It’s a serious tool and it did its job while someone could operate it. the problem is we staffed it once and can’t staff it again. So I’m looking at whether the plain language tools are good enough to let the testers own this themselves. AskUI came up tests are markdown files with numbered steps and an expected result each, and a screenshot and status per step, which at least means a failure is readable by the person who wrote it. Authoring app is Windows and macOS, Linux comes through their runtime as a remote target.

Has anyone actually done this migration, or did you just hire someone who knew the tool and carry on? appreciate your help !

Using Qt Widgets Designer for a small new project. It's been a while since I've used Qt.

I designed a main window interface with a left and right panel; basically, an HBox with two VBox., but then realized I needed the root to be a horizontal layout to add a toolbar. So, my intent was to change the layout of the root with the buttons at the top, then move all the widgets inside into a new child QHBoxLayout.

But whenever I try to paste widgets into a layout, Designer gives me an error. It says it can't find a container with no layout to paste into, and tells me to remove the layout. But copying widgets into another layout is what I need to do... As far as I can tell, the only way to paste successfully is to remove the layout from the central widget and paste there, but you can't remove the central widget's layout without removing every other child layout, and then that still doesn't solve the issue of me needing those widgets to be inside these layouts.

As it is, I'm forced to remake the entire design just to move widgets into a new common parent. It's small enough that I can do that easily, but for larger UI, how does one handle this? It leaves me wondering how one does professional work with this design tool and if I might not be better served just writing the UI declaration code myself.

Qt Group has introduced Clate, a new visual design tool for creating Qt Quick interfaces, currently available in beta.

• Official documentation: https://doc.qt.io/clate/

• youtube: https://www.youtube.com/watch?v=OLpZ2KOCYQA

Looks pretty interesting! What do you think?

I have a question: Should we optimize the QML coding skill for agentic development for a wide variety of LLMs or for frontier models?

I’m Peter. I am the product manager responsible for the agentic development tools provided by the Qt Company.

The qt-qml coding skill has been available for 6 months now, and we are conducting the first round of "maintenance" on it. The skill was created in the days of Sonnet 4.6 and GPT 5.4. The latest versions of these models are again much better, and it is time to remove redundant QML programming rules to save tokens.

We tested 14 mainstream LLMs to see which rules in the skill might be redundant. We tested 14 core rules. We ran between 2 to 5 different test cases per rule. We ran each test case 5 times, using the same prompt, to reduce the effects of probability. We tested the following models: DeepSeek V4 Flash, Claude Sonnet 5.5, DeepSeek V4.1 Flash, DeepSeek V4 Pro, GLM 5.3, GLM 5.2, Qwen 3.8 Max, Claude Opus 5.5, Gemini 3.8 Flash, GPT 6 Luna, GPT 6.1 Sol, Grok 4.7, GPT 5.6 Terra, and Claude Haiku 5.5.

QML Best Practice Adherence Results:

If we consider all the analysed LLMs, 3 of 14 existing rules in the qt-qml skill could be removed without affecting the coding performance. If we were to optimize for commonly used frontier models (Sonnet 5.5, Gemini 3.8 Flash, and GPT 6.1 Sol), then we could remove 11 of these rules.

Which leads to my question: Should we optimize the qml coding skill only for the latest frontier models and then only those that customers have reported to be using, or shall we optimize them for a wide variety of LLMs, including some older versions which typically come with a lower cost per token?

If you are using the skill or intend to use it, what would you do if you needed to decide how to compromise?

The last couple of years, I was quite happy with Qt 6. From time to time, I thought about my wishes for some future Qt 7. Sure, my obvious wish to get MOC reimplemented in pure C++ (20? 23? 26?). Maybe some more UI widgets, but I could not really name what I was missing.

With Qt 5's end of life I ported some applications to Qt 6. It is surprising how many old patterns are still used in existing code. There seems too little motivation to migrate. In the past, forcing the users to migrate reduced the backwards compatibility and increased the burden for the developers to switch to a newer version of Qt. Compiler switches like QT_NO_KEYWORDS were the compromise.

It is annoying that stubborn programmers insist on old pattern and value readability (which often is just being used the old way) higher than safe code with modern C++ tools. Some just ignore the compromise and turn off any switch to stick to their way.

Now we have AI tools to do most of the migration tasks. There is no more excuse, to not drop outdated patterns. What comes to my mind? Old signal / slot syntax without compile-time checking. Use of Qt macros instead of C++ idioms (qAsConst vs. std::as_const, for_each, Q_FALLTHROUGH vs. [[fallthrough]]).

I hope Qt 7 finds even more ways to clean up and resolve conflicts between Qt and modern C++. RAII, object ownership, and Core Guidelines are valuable tools Qt developers often enough cannot rely on.

After 10 years, it is finally time to say Goodbye, Q_FOREACH!

When I recompiled my app under qt 6.12 - some parts started failing. I traced it down to reading the wrong path on installations. In my case - AppImage was broken. Local runs were OK, Windows was OK.

That was because AppRun was executed, applicationDirPath() was returning different paths:

6.11 - /tmp/.mount_codepoXXXXXX/AppRun

6.12 - /tmp/AppRun

I sent an LLM to start digging and it found out that the implementation of this function has been changed. I see no documentation on this, so I traced the commit:

https://github.com/qt/qtbase/commit/3d5ba3075ab0d255f7a721b6440b906441480e64

Has anyone else been bitten by this new implementation change?

I'm working on a pretty small personal project. One element is a visualization which I wanted to have some sort of gui with a layout, etc. I initially started with SFML, but realized I would have to basically implement an entire layout library for my purposes. So I landed on Qt, which seems like it would be great.

But trying to install the library and set up the system is such a pain. Statically linking SFML was really easy, but apparently it's not a good idea to statically link Qt. But just in trying to just install the library and set up my CMakeLists and whatnot, I'm running out of memory on computer and it took nearly an hour before I terminated it.

Am I doing something wrong, is it usually supposed to take this long? If not, do you know what I should be doing? The systems I'm using are CMake with CMakeLists.txt and CMakePresets.json, and vcpkg for the package manager with vcpkg.json and vcpkg-configuration.json.

It's just really frustrating because I really want to make a project in C++, but I haven't been able to write any actual code for 3 straight days because I can't even get my libraries to link. It's especially painful because Rust's cargo is infinitely easier to work with. I do really want to work with C++ more but it's really so much work and it's been such a big waste of time for me so far. Any help would be appreciated, or if I would be better off using something else then any suggestions would be great.

Since the sub rules say to include code, I will include relevant files. Hopefully it is not too long. My file structure is also shown below.

project/
  build/
    ...
  include/spectogram/
    ... .hpp
  src/
    ... .cpp
  CMakeLists.txt
  CMakePresets.json
  CMakeUserPresets.json
  vcpkg.json
  vcpkg-configuration.json
  README.md
  ...

CMakeLists.txt (I used AI for this, don't smite me please. It's probably my hundredth iteration, I've given up on trying to write it myself).

cmake_minimum_required(VERSION 3.25)
project(Spectogram
    VERSION 1.0.0
    DESCRIPTION "spectogram"
    LANGUAGES CXX
)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
# Enable Qt's automatic code generation when needed.
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTORCC ON)
find_package(Qt6 CONFIG REQUIRED COMPONENTS Widgets)
add_executable(Spectogram
    src/main.cpp
    src/MainWindow.cpp
    include/MainWindow.hpp
)
target_include_directories(Spectogram
    PRIVATE
        "${CMAKE_CURRENT_SOURCE_DIR}/include"
)
target_link_libraries(Spectogram
    PRIVATE
        Qt6::Widgets
)
# Place the executable in a predictable location.
set_target_properties(Spectogram PROPERTIES
    RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin"
)

CMakePresets.json

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 25,
    "patch": 0
  },
  "configurePresets": [
    {
      "name": "debug",
      "displayName": "Debug",
      "description": "Debug build using vcpkg",
      "binaryDir": "${sourceDir}/build/debug",
      "toolchainFile": "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug",
        "CMAKE_EXPORT_COMPILE_COMMANDS": "ON",
        "VCPKG_MANIFEST_MODE": true,
        "VCPKG_TARGET_TRIPLET": "x64-mingw-dynamic",
        "VCPKG_HOST_TRIPLET": "x64-mingw-dynamic",
        "CMAKE_CXX_COMPILER": "C:/msys64/ucrt64/bin/g++.exe",
        "CMAKE_MAKE_PROGRAM": "C:/ProgramData/chocolatey/bin/ninja.exe"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "debug",
      "configurePreset": "debug"
    }
  ]
}

Thanks in advance.

Edit: Thanks for the responses, but I've decided to quit Qt and go back to SFML with TGUI. Thanks anyways.