Yes I have. It crashed when I ran “[DEV] Run QSS Section Diagnostic”.
sketchup_dark_mode.log_dev.1.1.4.txt (1.2 KB)
Yes I have. It crashed when I ran “[DEV] Run QSS Section Diagnostic”.
sketchup_dark_mode.log_dev.1.1.4.txt (1.2 KB)
Looking at the log, the crash happened immediately at Section 0, which is only basic window rules with zero SVG icons, zero dock rules, and no complex selectors. That’s a huge clue: it proves the stylesheet content itself isn’t the culprit, but rather the Qt C++ ABI call or Qt’s global widget repolishing across loaded plugins.
I updated v1.1.4-dev with an isolated step-by-step diagnostic:
sketchup_dark_mode_v1.1.4-dev.rbz (attached).SketchupDarkMode::QtStyler.debug_micro_test in the Ruby Console).sketchup_dark_mode.log (and the BugSplat Crash ID if one shows up).This test isolates QString allocation from setStyleSheet calls and tests empty strings, comments, and window-level styling individually so we can pinpoint the exact instruction.
sketchup_dark_mode_v1.1.4-dev.rbz (27.0 KB)
Still crashes.
Well done @mickyninja and @jakubix30. Qt manipulation through Fiddle open some possibilities. But unfortunately, it will remain a solution that is highly dependent on each version.
I recently tried using this technique to use the Qt dock system for integrating the Ruby HtmlDialog, and it worked.
But it also seems difficult to put into production, given the sheer number of technical dependencies we don’t control.
Step 3 with an empty string returned OK, but Step 4 with a comment crashed.
In Qt, non-empty stylesheets trigger a global repolish across QApplication::allWidgets(). If any loaded plugin widget has an unbacked style or inconsistent state, Qt crashes during polish().
I updated v1.1.4-dev with window-level styling that targets QMainWindow directly via QWidget::setStyleSheet, completely bypassing foreign widgets in allWidgets():
Install the updated sketchup_dark_mode_v1.1.4-dev.rbz (attached).
Run Extensions > Dark Mode > [DEV] Run ABI Micro-Test (Step-by-Step).
Phase 1 logs your active Qt style and loaded extensions, and Phase 3 tests styling the main window directly and applies dark mode to it).
When prompted after Phase 3, you can choose Cancel to keep the working dark window or OK to test the global call.
sketchup_dark_mode_v1.1.4-dev.rbz (28.1 KB)
FYI, it is confusing when version numbers do not increment and you post multiple RBZs with the same name in the same thread. This is no reason to hold onto tiny version numbers.
I’ll try this afternoon. I have an errand to run now.
Also, Gemini “thinks” that it is a problem (Access Violation) with dealing with QString from Ruby.
require 'fiddle'
# 1. Define fromUtf8 function:
# Hidden 1st Arg (RCX) = qstr_buf pointer (Return Buffer)
# 2nd Arg (RDX) = char pointer (Source String)
# 3rd Arg (R8) = length (qsizetype)
@fn_qstr_from_utf8 = Fiddle::Function.new(
qt_core_handle['?fromUtf8@QString@@SA?AV1@PEBD_J@Z'],
[Fiddle::TYPE_VOIDP, Fiddle::TYPE_VOIDP, Fiddle::TYPE_LONG_LONG],
Fiddle::TYPE_VOID
)
# 2. Allocate a buffer to hold the returned QString instance.
# Qt 6 QString requires 24 bytes; Qt 5 requires 8 bytes. 24 bytes covers both safely.
qstr_buf = Fiddle::Pointer.malloc(24)
# 3. Prepare the source UTF-8 string buffer.
css_text = "/* test */"
str_ptr = Fiddle::Pointer.to_ptr(css_text)
str_len = css_text.bytesize
# 4. Invoke fromUtf8 to populate qstr_buf in-place
@fn_qstr_from_utf8.call(qstr_buf, str_ptr, str_len)
# 5. Pass qstr_buf directly to setStyleSheet:
# setStyleSheet expects a const QString&, which is a pointer to the qstr_buf memory block.
@fn_set_stylesheet.call(qapp, qstr_buf)
#<SyntaxError:".../sketchup_dark_mode/qt_styler.rb:733:
syntax error, unexpected `rescue' modifier, expecting ')'">
This is in a UI.messagebox call.
It is not necessary to test for existence of message box constants as the API has always defined them globally. See: SketchUp Ruby API top-level namespace
For example the next line:
if choice != 1 && choice != (defined?(IDOK) ? IDOK : 1)
… is convoluted. We usually do something like:
if !choice || choice != IDOK
… which covers a falsey result or anything other than IDOK.
Ok, after fixing the SyntaxError and running as instructed, It completes Phase 3, the messagebox is shown and the interface all looks like it’s in dark mode. Then clicking OK it’s crashes on Phase 4.
I’m wrapping up all the BugSplat files and memory dump in a zip along with the sketchup_dark_mode.log.
sketchup_dark_mode_log_dev.1.1.4b.zip (61.3 KB)
Phase 3 proved that styling main_window directly via QWidget::setStyleSheet works 100% without crashing and renders full dark mode cleanly. The BugSplat report (HUDD2M70.xml) confirmed that Phase 4 crashed inside SketchUp!005a3451 during global QApplication::allWidgets() repolishing.
In v1.1.5, apply_stylesheet now targets main_window directly as the default engine. This means the standard Dark Mode toggle (toolbar button, menu, hotkeys, startup) should now work
sketchup_dark_mode_v1.1.5.rbz (28.0 KB)
Okay v1.1.5 does not crash, so far. At first a lot of the elements in the inspector panels stayed light. Switching Dark Material List off then back on restyles them to dark mode. (They did not return to light mode when switched off.)
Dark mode looks good upon restart.
But …
When using the setting inputbox this error is output to the console:
#<NoMethodError: private method `update_ui_elements' called for SketchupDarkMode::Main:Module>
C:/Users/Dan/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/sketchup_dark_mode/settings_dialog.rb:90:in `show'
C:/Users/Dan/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/sketchup_dark_mode/main.rb:278:in `block in setup_ui'
Fantastic that v1.1.5 resolved the crash
I addressed all your observations in v1.1.6:
update_ui_elements to public scope to eliminate the NoMethodError.!important to QHeaderView and QHeaderView::section to suppress native Windows UxTheme header rendering.QTreeView::branch) for clear expand/collapse hierarchy visibility.Please test the updated package
sketchup_dark_mode_v1.1.6.rbz (29.2 KB)
Tried v1.1.6. It is stable.
Could we get an option to switch of the Logging to the Console please?
Issues:
the Tags inspector column headers are still light mode.
the Measurements toolbar entry box (aka the VCB) is white on white, so we cannot read what we are typing.
The Outliner mods do not work. The text is still dark and the icons dark also.
Re, Instructor. There is only one CSS file (per language pack,) but it is in the %ProgramFiles% path on Windows. For example when running in English:
%ProgramFiles%/SketchUp/SketchUp 2026/SketchUp/resources/en-US/helpcontent
the name of the file is: "helpcontent.css". It is a relatively short file, only 9 rules.
Also available via Ruby:
Sketchup.get_resource_path("helpcontent/helpcontent.css")
… but returns the correct path for the language SketchUp is using.
Could be problematic swapping it with a dark edition (from an extension) due to permissions.
I manually edited it, cleaned it up (formatting was terrible,) and added media query blocks to sync with system theme setting. Supported since: MacOS Mojave 10.14, Windows 10 version 1903 (2019) and SketchUp 2021.1 and higher.
helpcontent.css.zip (771 Bytes)
But it is my machine and I have admin rights so I can back up the original and copy this one in. Since SketchUp loads it “on-the-fly” edits can be made and reloaded by SketchUp simply by changing the active tool.
NOTE: It does not attempt change the animated GIFs.
@jakubix30 I need to rescind this. Sorry, but it is not stable. In some SketchUp builds it is still crashing.
But the more important thing I think is memory corruption. I was working on a Ruby module that was acting weird when testing. I was getting silent failures when Ruby should have been raising exceptions.
I had to disable the dark mode extension in order to properly run and test my code.
Hi !
Some key improvements would be to be able to choose the UI background color: since most of our plugins and some SU icons aren’t perfectly balanced for dark mode, some lighter colors would be interesting to tweak.
In the mean time I don’t know if it’s possible to change SU’s Default Tray darker icons such as tags, materials, scene names & icons ? And is it possible to also choose the HEX value of the lower blue line ?
Thank’s a lot for the good work !
Hello everyone. If anyone wants to try my version of Dark Mode, it’s fully open source and available here: GitHub - gordanog/Dark-Mode-SKP-Public: Public release of Dark Mode SKP. · GitHub
I only ran it on 2026 but in theory it should work on 2024 and 2025 as well.
It’s recommended to build it locally by following the instructions from README.md inside the repo but you can download the ready to install package from releases tab as well and give it a go.
Micky, did you do this from scratch or convert Jacobix’s to C++ code?
I am wondering if you have much experience with Qt programming.
Hi! It was all done from scratch.
Did you get a chance to try it out yet? I’m curious to hear how it works for you.
So far it seems to work.
Unfortunately the live toggle on/off is out of question because some UI elements must be manipulated at startup.
The contrast issue between the dark background and default icons is being worked on and is like 95% done. It will probably drop in a couple of weeks when my schedule frees up a bit..
![]()