标签：#ha

Working late nights on server migrations and code architectures often means typing in low-light environments. While USB lamps or backlit keyboards are the standard solutions, they consume extra power and add physical clutter. I realized the ultimate light source was already directly in front of me: the monitor. With a clear vision in mind, I partnered with Google's Gemini AI to rapidly prototype and refine what became LightBar For Keyboard , a lightweight Windows application that creates a reflective light bar at the bottom of the screen to illuminate the keys. Here is how we built it using C# and WPF, tackled the Windows API to manage screen space, and optimized it for modern OLED energy consumption. The Core Challenge: Desktop Toolbars (AppBar) The simplest approach to creating a light bar is a borderless, top-most window. However, the immediate UX flaw is that maximized applications (like Chrome or Visual Studio) will either cover the bar or be partially obscured by it. To solve this, the application needed to behave like the Windows Taskbar. I implemented the native Windows Application Desktop Toolbar (AppBar) API using SHAppBarMessage from shell32.dll . Docked Mode: By registering the application as an AppBar and setting the edge to ABE_BOTTOM , Windows automatically recalculates the working area of the desktop. Result: Maximized windows are pushed upward, ensuring the light bar remains entirely visible and never covers any underlying application UI. Floating Mode: For users who need temporary access to the bottom of their screen, I added a state toggle that unregisters the AppBar and enables standard drag-and-drop window movement via MouseLeftButtonDown . Enforcing a Single Instance Because the app directly manipulates the desktop working area, launching multiple overlapping instances would cause UI glitches. To prevent this, I implemented a Mutex in App.xaml.cs to guarantee a single instance constraint. protected override void OnStartup ( StartupEventArgs e )

A few weeks ago I spent twenty minutes hunting for a ChatGPT conversation I knew existed. It was a debugging session. The model and I had traced a race condition in a KV cache layer — and the final write-up was genuinely good: why the bug only fired under concurrent writes, the fix, and a checklist for avoiding that whole class of bug. Three weeks and a hundred chats later, ChatGPT's search couldn't surface it. I re-derived everything from scratch. That's when it hit me: AI chat is where a growing share of my real engineering work happens — and it's the worst archive I own. We're producing work in a place designed to lose it Think about what's sitting in your ChatGPT (or Claude) history right now: code you debugged line by line over ten turns architecture trade-offs you talked through before writing the design doc that regex / SQL / jq incantation you will absolutely need again migration plans, incident notes, dependency-upgrade research In any other tool, we'd call these documents . We'd file them, tag them, grep them. In ChatGPT, they're just... chat number 247. The obvious fixes don't really work I tried everything before building my own solution, so you don't have to: The official export. ChatGPT will happily email you a ZIP of your entire history — all of it, at once, as raw HTML and JSON. It's a backup, not a filing system. You can't export the one conversation that matters, and let's be honest: nobody ever greps the ZIP. Copy-paste. The copy button under each reply grabs Markdown, and Notion converts most of it. But it's one message at a time, your own prompts aren't included, and long tables and code blocks arrive mangled. For a 30-message thread, that's your afternoon. Share links. A share link is a bookmark, not a copy. The content never enters your workspace, your search can't index it, and the link dies the moment you delete the chat. Every one of these fails the same test: can I find this answer in 30 seconds, three months from now? What actually worked