Devlog #2: Debugging + Icon dragging features + localStorage implementation
The core window manager is working properly so this second session was all about polishing the UI and UX aspects. But there were some challenges:
- The faulty dragging
I transitioned the desktop icons from a static flexbox grid to absolute positioning so they could be freely dragged around the screen (like an actual operating system). However, this immediately triggered native browser collisions.
The Problem: When clicking and dragging an icon, the browser saw the action as trying to highlight text or drag an image to a new tab. This triggered a native HTML “ghost drag,” completely overriding my custom JavaScript drag engine and leaving the icon permanently stuck to the cursor.
The Solution: I just basically implemented multiple stuff to solve this:
-
Applied ‘-webkit-user-select: none’ and ‘user-select: none’ to prevent highlighting.
-
Injected ‘draggable=“false”’ natively into the HTML.
-
Applied ‘pointer-events: none’ on the inner emoji and label text. This forces the mouse click to pass through the text and hit the icon container directly, ensuring my custom
e.preventDefault()mousedown event works properly every time. -
State Persistence (The Local Storage API)
An OS is useless if it resets every time you turn it on. I wired up the browser’s nativelocalStorageAPI so it saves some of the stuff that the user did. So far it’s only the position of the icons, but I’m planning to add more stuff to the localStorage. Here are the changes:
Upgraded the mouseup event listener to capture the exact X and Y coordinates of an icon the moment it is let go after dragging.
Built a boot sequence that loops through .desktop-icon elements on page load, fetches their saved coordinates , and implementes them.
- Wallpaper changing bug
The NASA API integration was fetching data successfully, but massive high-res images were causing visual lag, leading to a blank blue screen while the image downloaded in the background.
Made a new thing where the newImage() is inserted into the virtual memory of the js.
The UI now triggers a document.body.style.cursor = ‘wait’ loading wheel and displays a “Downloading…” status.
JavaScript intentionally halts the DOM update until the virtual image’s ‘.onload’ event fires, ensuring the wallpaper only gets applied to the screen exactly when it is 100% ready.
Lastly, I also added a setting in the settings tab where the user can choose if the icon labels are hidded or shown.
What’s Next?
The desktop environment is now completely stable, personalized, and persistent. Next up: More UI and UX refinements before shipping for WebOS 1. Gonna implement File Management for WebOS 2 :)
Comments 0
No comments yet. Be the first!
Sign in to join the conversation.