<div class="key-takeaways"><ul><li>Packet Sender เดิมต้องรีสตาร์ทแอปจึงจะเปลี่ยนธีมตาม OS ได้</li><li>การใช้ Background Thread (QThread) ตรวจจับธีมบน macOS ทำให้แอปพัง (Crash)</li><li>ทางออกที่เสถียรคือการใช้ QTimer บน Main Thread เพื่อเลี่ยงการแย่งทรัพยากร</li></ul></div><p>จุดเริ่มต้นของงานนี้มาจากการทดสอบโหมดสว่าง (Light Mode) ให้กับแอป Packet Sender ซึ่งสร้างและดูแลโดย Dan Nagle เนื่องจาก Dan ใช้โหมดมืด (Dark Mode) เป็นหลัก เขาจึงมองข้ามจุดที่ว่ายังมีบางส่วนของธีมมืดค้างอยู่เมื่อแอปสลับมาเป็นโหมดสว่าง งานแรกที่ผู้เขียนได้รับมอบหมายจึงเป็นการทดสอบส่วนติดต่อผู้ใช้ (UI) แบบแมนนวลอย่างละเอียด เพื่อให้มั่นใจว่าการเปลี่ยนจากโหมดมืดเป็นโหมดสว่างทำงานได้อย่างสมบูรณ์ 100%</p><p>ก่อนหน้านี้ผู้เขียนเข้าใจว่า Packet Sender ทำงานตามการตั้งค่าของระบบปฏิบัติการมาโดยตลอด (โดยใช้ macOS เป็นหลัก) แต่ความจริงคือการจะเปลี่ยนโหมดในตอนนั้น ผู้ใช้งานจะต้องรีสตาร์ทแอป Packet Sender เสียก่อน เมื่อเปิดขึ้นมาใหม่ แอปจึงจะอ่านค่าการตั้งค่าจาก OS และปรับธีมที่ถูกต้องให้ แต่สิ่งที่แอปยังทำไม่ได้คือการอัปเดตตัวเองแบบเรียลไทม์เมื่อ OS เปลี่ยนธีม เช่น กรณีที่ผู้ตั้งค่าเครื่องให้สลับโหมดสว่างและมืดอัตโนมัติตามช่วงเวลาของวัน</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/qt_mtm4wjwv_inline_1_4a307d7b1a.jpg" alt="macbook pro software development workspace" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div></p><p>ผู้เขียนเชื่อว่าโครงสร้างพื้นฐานของระบบมีพร้อมอยู่แล้ว ขาดเพียงแค่การทำให้แอปรับรู้ว่า OS ได้เปลี่ยนโหมดไปแล้วเท่านั้น ในการแก้ปัญหานี้ Dan ได้เล่าให้ฟังทางโทรศัพท์ว่าเขาเคยแก้ปัญหาลักษณะเดียวกันนี้ในแอป Qt ตัวอื่นสำหรับลูกค้า โดยใช้ Thread ในการช่วยจัดการ ผู้เขียนจึงนำแนวคิดนี้ไปปรึกษา AI อย่าง Grok เพื่อขอชุดคำสั่งในการใช้ QThread แต่ผลลัพธ์ที่ได้กลับทำให้แอปเกิดการพัง (Crash) อย่างหนัก</p><div class="ai-insight"><p>ในทางเทคนิคแล้ว การฟังค่าการเปลี่ยนโหมด Light/Dark ไม่ใช่ปัญหาเรื่องการประมวลผลเบื้องหลัง (Background-compute) แต่เป็นปัญหาเกี่ยวกับสถานะของ GUI (GUI-state problem) ธีมของระบบปฏิบัติการจะถูกแชร์ร่วมกับ AppKit และ Widget ทุกตัว การใช้ Thread เสริมมาอ่านค่ารูปลักษณ์แล้วสั่ง setPalette() จะเกิดการแย่งชิงทรัพยากรกับ Toolkit ซึ่งบน macOS ความขัดแย้งนี้ส่งผลให้เกิดการทำงานที่ไม่ได้กำหนดไว้และทำนายไม่ได้ จนนำไปสู่ Hard Crash ในที่สุด</p></div><p>ทางออกที่ผู้เขียนเลือกใช้ในท้ายที่สุดคือการเปลี่ยนมาใช้ QTimer แทน โดย QTimer ที่ผูกกับ qApp จะทำงานอยู่บน Main Event Loop ทำให้ทุกๆ ติ๊กของการทำงานรันอยู่บน Thread เดียวกันกับที่ควบคุม Widget การตรวจสอบว่าตอนนี้เป็นโหมดมืดหรือไม่ และการสั่ง applyTheme() จึงถูกจัดลำดับขั้นตอน (Serialized) ไปพร้อมกับการวาดภาพ (Paint) การปรับขนาด (Resize) และอีเวนต์เกี่ยวกับธีมอื่นๆ โดยไม่มี Thread ตัวที่สองเข้ามาแทรกแซงบน QPalette และยังคงอยู่ภายใต้ Thread ที่ AppKit อนุญาตบน macOS</p><p>แม้ว่าการทำ Polling ทุกๆ สองสามวินาทีอาจจะดูไม่ใช่แนวทางที่หรูหราที่สุด เพราะใน Qt 6.5 ขึ้นไปจะมีฟังก์ชันอย่าง QStyleHints::colorSchemeChanged() และ Widget ต่างๆ ก็รองรับ QEvent::ApplicationPaletteChange อยู่แล้ว แต่การทำ Polling ก็ยังคงเป็นวิธีที่ถูกต้องในแง่ของการไม่ข้ามขอบเขตของ Thread (Thread Boundary) ข้อเสนอเรื่อง Thread ของ Dan อาจจะช่วยให้รู้ว่า OS เปลี่ยน แต่ไม่ได้ช่วยให้สามารถนำการเปลี่ยนแปลงนั้นไปใช้ได้อย่างถูกต้องตามกฎของระบบ</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/professortom/how-to-change-themes-with-the-operating-system-in-a-qt-app-27nf" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Packet Sender previously required an app restart to match the OS theme.</li><li>Using a background thread (QThread) to track themes on macOS caused hard crashes.</li><li>The stable solution relies on using a QTimer on the main thread to avoid race conditions.</li></ul></div><p>The journey began while testing light mode for Packet Sender, created and maintained by Dan Nagle. Because Dan personally uses dark mode exclusively, some dark mode elements lingered when the app switched to light mode. My initial task was to manually test as much of the UI as possible to ensure a 100% successful conversion from dark to light mode.</p><p>I previously assumed Packet Sender automatically followed the operating system's settings—using macOS in my case. However, changing the mode required restarting Packet Sender entirely. Upon relaunch, the app would read the OS setting and apply the correct theme. What it could not do was update itself dynamically when the OS changed themes based on the time of day or ambient light.</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/qt_mtm4wjwv_inline_1_4a307d7b1a.jpg" alt="macbook pro software development workspace" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div></p><p>Believing we were close to achieving seamless theme switching since the core rendering code already existed, I consulted Grok for C++ syntax and Qt guidance after Dan mentioned during a phone call that he solved a similar client problem using a thread. However, the code provided by Grok utilizing QThread resulted in immediate application crashes.</p><div class="ai-insight"><p>Technically, listening for light and dark mode changes is not a background-compute problem; it is a GUI-state problem. The OS theme is shared with AppKit and every widget. A helper thread reading appearance and calling setPalette() races against the toolkit. On macOS, this race condition leads to undefined behavior and hard crashes.</p></div><p>The ultimate solution I implemented was utilizing a QTimer instead. A QTimer parented to qApp fires on the main event loop, ensuring each tick runs in the exact same thread that owns the widgets. Checking appearance states and invoking applyTheme() is properly serialized with paint, resize, and theme events, preventing any race conditions on QPalette.</p><p>While polling every few seconds may seem inelegant, and newer Qt versions like Qt 6.5+ offer QStyleHints::colorSchemeChanged(), polling remains correct because it avoids crossing thread boundaries. Dan's suggested thread solved detecting the OS change, but it failed to apply that change legally within framework constraints.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/professortom/how-to-change-themes-with-the-operating-system-in-a-qt-app-27nf" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_พัฒนาแอป-qt-ให้สลับธีมตามระบบปฏิบัติการได้อัตโนมัติ-mtm4wjwv.jpg

small_พัฒนาแอป-qt-ให้สลับธีมตามระบบปฏิบัติการได้อัตโนมัติ-mtm4wjwv.jpg

thumbnail_พัฒนาแอป-qt-ให้สลับธีมตามระบบปฏิบัติการได้อัตโนมัติ-mtm4wjwv.jpg

Inewgen

Inewgen

#Packet Sender

How to Change Themes with OS in a Qt App

Inewgen