OrbitLens Devlog #7: Implementing a 2D orbit map

To expand the functinality of the website, i wanted to add a 2D world map that has the 3d orbit projected on to it. Here is a breakdown of what i built, how i built it and the challenge i faced.

What I Built:

I made a 2D projection of the 3d globe using the HTML5 Canvas API that runs at the same time with the WebGL 3D engine.

The map automatically appears when a satellite is selected, and fetches live telemetry to draw exactly one full orbital period (half past, half future). The orbit line looks like how it does on the 3d globe with a yellow line representing the past trail and a dotted blue line representing the predicted future track. I also built an “EXPAND” toggle that expands the map to fill most of the screen if the user wants to take a close look.

Challenges:

• If a satellite flies east across the Pacific Ocean (where the International Date Line is), its longitude coordinates suddenly jump from +179deg to -179deg. I originally didnt take this into account and it had like this massive, horizontal glitch streak entirely across the screen cus of the sudden coordinate shift.

To fix this, I programmed a strict mathematical distance gate into the drawing loop. If the engine detects that the X-coordinate has jumped by more than half the width of the canvas, it forces the renderer to break the current stroke (mapCtx.stroke()), lift the ‘pen’, and begin a completely new path on the opposite edge of the map (mapCtx.beginPath()).

• When plotting a full 90-minute orbit, the beginning of the yellow line and the end of the cyan line do not connect perfectly, leaving a massive gap. I originally thought this was a problem and tried for quite a while to fix this and i double checked the math formulas again and again. But i realised this isnt a math error, it’s just physics. While the satellite flies in a continuous circle, the Earth is physically rotating underneath it. By the time the satellite completes one lap, the ground has shifted roughly 22.5 degrees to the east, pushing the satellite’s relative ground track to the west. So i just left it like that to accurately represent the Earth’s rotation.

• This was the biggest problem and took the most time to fix. Three.js orbital camera controls are incredibly aggressive about capturing mouse events. The 3D engine was always suppressing the HTML ‘click’ events, making the “EXPAND” button not work. Not only that, the standard inline CSS was pushing the 3D canvas down the page, which misaligned everything and didnt allow me to select the satellites at all.

To fix this, fisrt, i locked the 3D canvas to a fixed background layer (z-index: -1) to completely isolate it from the UI layout. Second, i bypassed the WebGL event interceptors entirely and connected the code that handles the expansion directly to a global window function (window.toggleMap) and just injected the button with the HTML onclick attribute. This fixed everything and now it works really great.

OrbitLens Devlog #6: Implemented Sun and the day night cycles + camera panning improvements

The core engine was working smoothly, so this session was focused on the ui and aesthetics and realism. Here are the changes i made, how i made them, and the challenges i faced:

Change 1: Implemented the Sun

The first major goal was replacing the static and boring lighting the 3D earth originally had with a Sun.

To do this, I wrote a custom Solar Ephemeris algorithm. Using the current Julian date, it calculates the sun’s exact Right Ascension, Declination, and Earth’s Greenwich Mean Sidereal Time (GMST) to pinpoint the real-time subsolar vector. Since this was some complicated math, i had to use some ai for this.

But in a WebGL engine, lights are purely mathematical vectors and there is no physical object in the sky. So when i first added a solid white sphere, it literally looked like a flat plastic toy and looked really ugly. To fix this, I abandoned the 3D ball and built a 2D Sprite using the HTML5 Canvas API to generate a radial gradient. By using Additive Blending to the material, I forced it to mathematically layer the light over the space, which created like this blinding, light that looked like the sun, which was good.

Change 2: The Day/Night City lights cycle:

To make the globe even more realistic, I wanted the night side of the Earth to have like the night time city lights rather than just a dark shadow.

To build this, I added an 8k night-map texture (from Solar System Scope) and implemented a WebGL fragment shader into the Three.js’s native MeshPhongMaterial using a compiler hook. But there was a problem, the free night map that i implemented had this blue tint to it, and when i tried to correct it, it literally turned to this muddy, polluted yellow.

To fix this, I programmed the shader to intercept the texture data, remove the color tint by calculating luminance, and pass it through a smoothstep noise gate. Anything below a 10% threshold was forced to pitch black, while populated areas were recolored with a warm golden orange hue. And it worked great!

Change 3: More camera improvements

Despite the previous session having to do with correcting the camera engine, there were still some stuff that i fixed here. The problem was since i removed OrbitControls in the last session (read previous devlog), once i had like hte earth upside, it was very hard to make it upright again. like at one point, i had the entire europe upside down and Africa was at the top of the globe but i couldnt get it back to normal.

To fix this I changed the code so that the panning controls thing swaps between OrbitControls (for the 3D globe) and TrackballControls (for the satellites/spacecrafts). But there were some more challenges:

• When a zoom-in animation (read previous devlogs) finished (after selecting e.g. a satellite), the camera would like glitch backward into a less zoomed in position which was kinds uncomfortable to look at.

• Because the satellites were moving a static transition speed couldn’t catch them before the animation finished, so the final frame was a bit glitchy and the screen like jumped a bit.

To fix all of these problems, I first made sure that disabled camera controls are completely turned off so they can’t fight the active zoom animations. I also made it that instead of moving at a steady speed, I added a speed-up effect as the camera gets closer to the target. This ensures that the camera glides smoothly into place right on time without any jerky jumps.

OrbitLens Devlog #5: Camera panning improvements and performance updates

After the changes from Devlog #4, all the math and the 3d models were all working but i faced some problems in other aspects of the website. Here are soe of the changes i made:

Change 1: Correct orientation

This was a small change, but i noticed that some satellites were a bit too big (like Aqua) and were positioned wrongly, so i just chaged teh scale and the rotation to make it a bit more realistic

Changes 2, 3, and 4: The camera improvements

I faced a lots of problems with the camera and how it worked. Before, i couldn’t rotated in all directions around the earth or the satellites because they were using OrbitControls so i swapped that out with TrackballControls, which allows for 360deg panninh

There was also like a rubber band effect where the camera, when the camera lock was selected as satellite, zoomed in towards a satellite, i couldn’t interact with the satellite at all. THis was because as the satellite’s moving, the camera is also actuvely trying to catch up so it never actually ‘ended’ its animation so i was blocked from interacting with the satellite. To fix this i implemented delta tracking. The engine now calculates the exact mathematical vector the satellite moves every frame and shifts the camera’s physical position by that exact same amount, which worked.

Previously, switching targets caused the camera to travel in a straight line, clipping through the Earth, which looked kinda unprofessional so I engineered a custom transition that separates the camera’s direction from its altitude. Now, when you select a new satellite, the camera zooms out, tracels in a an arc over the globe, and zooms in to the destination satellite.

The animation still needs a lot of improvement cus some parts are still a bit glitchy, but i’m happy for now.

Change 5:

I implemented it that the TLEs are now stored in the actual localStorage for like 6 hours and then fetch new TLEs. So the user will always have the latest TLEs cus they update evey 12hrs.

OrbitLens Devlog #4: Adding multiple satellites

In my last update, I finally got a 3D model of the ISS rendering on the globe with a basic UI dashboard. It looked cool, but I wanted to scale it up. I wanted to add multiple famous satellites on top of the ISS:

• The Hubble Space Telescope (HST)
• NASA’s Aqua
• NASA’s Terra
• Tiangong
• ISS (which already exists)
  At least for now. Maybe in later stages, I can add Starlink satellites or sth. Here is waht I built, how I built it, and the challenges I faced.

Change/Challenge 1: the orbit that looked like a slinky

I hardcoded a 90-minute orbit line (the ISS orbit time). But other satellites have different orbital periods, so 90 mins fell short. Increasing it to a 12-hour calculation made the ISS orbit look like a massive slinky wrapping around the Earth cus its orbit is only 90mins. I fixed this by dynamically calculating the exact total orbit time using the satellite’s math:

const periodMinutes = Math.ceil((2 * Math.PI) / satrec.no); const halfPeriod = Math.floor(periodMinutes / 2);

Change/Challenge 2: IP ban (again)

The JS fetch() doesn’t consider a ‘429 too many requests’ (i got this cus vite reloaded the page every time i saved something) response as a network error, so it tried calculating the HTML error page as orbital math and crashed. I fixed this by manually checking the response.ok HTTP status. If the API blocks me, the code redirects to an “Offline Fallback Mode”—loading a hardcoded string of ISS TLE math so the app survives.

Change/Challenge 3: improper API request

After like 4 hours, I realized I still wasn’t getting a proper API response even though the IP ban would have worn off. I looked at the code and realized I was pulling data for all five satellites in one go by just comma-separating the values in the URL like this:

.../gp.php?CATNR=25544,20580,48274&FORMAT=tle
(each number references to a satellite)

But after CelesTrak’s documentation, it strictly dictated that the CATNR parameter only accepts a single catalog number. The server rejected the request, my code assumed 0 satellites, and the engine crashed.

The fix:

Writing five separate fetch() blocks is messy, and implementing an await fetch() in a for-loop creates a slow “waterfall” effect (waiting for one to finish before starting the next).

I fixed this with JavaScript’s Promise.all. I created an array of the exact NORAD IDs, mapped over it to generate separate, perfectly formatted fetch requests, and Promise.all fires them all at the exact same time.

Change/Challenge 4:

I wanted 3D models for all of these. I found Aqua and HST easily from NASA. I found Terra, but it was fetching some other incompatible file I didn’t have, so I just scratched the Terra model. Tiangong was the biggest pain—everywhere I looked was either paid or on Sketchfab, and I cant create a Sketchfab account cus of some stupid Epic Games restriction.

Implementing the files I did have was the next issue. Hardcoding multiple GLTFLoader blocks would turn the code into spaghetti. Plus, 3D models from the internet aren’t scaled equally—my Hubble was massive, and my Aqua model was tiny.

The fix:

I built a central Model Registry object. It maps a satellite’s NORAD ID to its file path and a specific scale multiplier. Even better, I implemented a fallback for satellites I done have a model for. If I track a satellite (like Tiangong) but leave the file path as null, the code detects this and dynamically generates a glowing cyan sphere using Three.js math to take its place.

Changes 5 and 6:

I updated the dashboard to include a dropdown to select the satellite and the telemetry updates accordingly. I also added a camera toggle feature where the user can lock the camera to follow the satellite or stay locked on the Earth. Lastly, I implemented a custom loading screen while the models load.
P.S.Lots of info is compressed cus i crossed the 4000 char limit

OrbitLens Devlog #3: Adding a dashboard + ISS 3d model implementation

I had two goals in my mind in this session. One was to add a dashboard which displays some stats of the ISS and the other is to replace the red dot with a 3d model of the ISS. Here is what and how I implemented these stuff and the challenges i faced:

Change/Problem 1:

Before I even got started on the new stuff i wanted to add, i faced a big problem. While testing the physics code and other stuff, my build tool (Vite) was auto-refreshing the browser every time I hit save. This I spammed CelesTrak’s public API with dozens of requests per minute. This lead to me kinda getting IP blocked temporarily, at least that’s what i think happend because it always returned an HTML error page instead of a TLE string. My engine tried to calculate stuff with that empty TLE and just crashed the engine

The fix:

It is important to know that a TLE is not like a live GPS broadcast that gets transmitted every second. It’s literally like a mathematical snapshot of a ton of stuff of the ISS like its position and its orbit and NORAD only updates these TLEs like twice a day or sth. So I fixed this api problem by making it such that the localStorage caches the TLE once and uses it for the calculation for the next 12 hours and then updates the TLE after that.

Change 2: Dashboard implementation

I implemented a dashboard that shows up on the top left of the screen and shows the following stuff abotu the ISS:

• Longitude: the method i used to calculate this is in one of my previous devlogs (i think my last one). But here is a quick summary:

To find coordinates I first calculated the Greenwich Mean Sidereal Time (gmst), which gives me the exact rotational angle of the Earth at that specific millisecond. I passed the ECI position (one of the previosu devlogs) and gmst into satellite.eciToGeodetic(), which projects the point onto the spinning globe in radians. I then multiplied those values by 180/pi to convert the radians into standard degrees

• latitude: same as longitude

-altitude: The eciToGeodetic() function also calculates the distance from the satellite’s coordinates down to the mathematical surface of the Earth (the WGS84 or the ‘World Geodetic System 1984’ ellipsoid which is like a mathematical reference representation of the earth that is used in calculatoin and stuff). It outputs this directly as height in kilometers, which I then simply rounded to two dp.

-velocity: The propagate() function outputs the satellite’s speed broken into X, Y, and Z axes (measured in km/s). To get a single speed, I calculated the magnitude of that 3D vector using the 3D Pythagorean theorem:
v = squareroot(x^2 + y^2 + z^2)

Change 3:

To implement a 3d model, i first needed that 3d image. I wanted the highest quality NASA model available (Model D - IGOAL). I downloaded the official .fbx, converted it to a .glb, and ended up with a 255mb file. Which is really bad because shoving a 255mb file into a web browser would just crash the entire thing. So i just ran that through a draco compression and a texture compression (WebP 1024x1024) which brought the size to about 18mb which was much better.

To render this, I used Three.js’s GLTFLoader with a dedicated Google WebAssembly DRACOLoader to decode the compressed math.

The next couple of changes were just to make it more realistic:

• i changed the scale from 0.02 (where it was the size of a continent) to 0.001 (which made it a good size)

• the direction the ISS faced was not accurate at all so I wanted to rotate until its in the correct position. But because the animate() loop was actively using math to point the model forward 60 times a second, it kept overriding my manual rotation. So I wrapped the ISS in a THREE.Group, rotated the mesh 90 degrees inside that container, and then applied the math.

WebOS 2 Devlog #21: Final Submission

Just did some final changes to the welcome text and am about to ship it

WebOS 2 Devlog #20: Updated README.md and ARCHITECTURE.md + changed properties window

I just realised I had a properties window in the OS and that was quite outdated so I changed to include some new info like the Last Modified date which updates everytime the user saves something because i added a localStorage.setItem that saves the timestamp.

I also updated the README and ARCHITECTURE files to make them sound better and to add some additional info.

Anyway, this devlog is probably the last on for this project! Hope you enjoy :)

WebOS 2 Devlog #19: README.md + ARCHITECTURE.md + additional customisation features

I’m in the final stages of the project and in this long session, I did many things. Firstly, I wrote a README.md with all the necessary stuff and i also made an ARCHITECTURE.md file which explains the nitty gritty insides of the WebOS so anyone can understand how the website works.

Other than that I added a couple of other stuff. Firstly, i realised that even though I have accents to customize the desktop, I don’t have a wallpaper gallery (except the nasa apod) which I found was quite necessary. At first, i coded my own wallpapers like a synthwave grid wallpaper, pinstripe wallpaper for the legace theme, a tranforming aurora wallpaper and like 3 more but after i coded them, they just looked so damn ugly. So i scratched the idea of me coding my own wallpapers and added three categories of wallpapers in the wallpaper dropdown with each category having three 4k wallpapers in them so every time you pick that category, you get a random wallpaper from the three.

I also added an about section in the settings which has a buttton that leads to the github page.

WebOS 2 Devlog #18: Debugging session

I swear random bugs keep popping up no matter how much debugging I do. There’s always something that’s wrong or doesn’t work but that’s just how it is. In this session which was longer than expected, i fixed a lot of different bugs. Here is a summary of the changes i did:

• I spent lots of time rewriting the mathematics for the desktop icon layout, and also changed the strict grid-snapping to free-form placement cus it felt it was quite annoying not to be able to place stuff on the desktop wherever you want. Unfortunately, it took too long and i abandoned the idea and just moved on without making any changes.

• I also spent some time cleaning up the code and tried to optimizing the code.

Some other bugs I fixed include:

• Desktop icons were randomly rearranging themselves every time a file was saved. I found out that the reason was that since the localStorage returns keys randomly, everytime i wrote sth to localStorage, the items were randomized so the ordier they appeared on the desktop changed. So i rewrote the logic to sort the stuff alphabetically before displaying.

• The Notepad app was also blindly overwriting existing files with the same name. I fixed it by adding a localStorage query to intercept matching keys and to display an osConfirm dialog, forcing the user to explicitly authorize the overwrite.

• The internal browser was throwing captchas all the time and failed to load error screens for blocked domains. Since Google aggressively blocks embeds and flags them as bot traffic, i changed the default browser to Bing, which was much better and i didn’t get captchas everytime i search somehting up

• I also modified the system daemon engine so that it introduces itself when a user first view the OS.

• The weather widget was pulling the location not from where the user was but rather where my ISP was routing my traffic through. So if i lived in a village and ISP routes my traffic through like New York, the weather that showed up was that of New York. To fix this, i swapped the logic to request exact hardware GPS coordinates via navigator.geolocation, while falling back to the IP routing API if the user denies the browser prompt. If the location is inaccurate the user can enable the location permission in the browser and the weather widget then shows the correct location.

• The visualizer widget was working perfectly but i had the idea to add a text container above the bars which shows what the user is playing.

I made way way more changes but many of them conform to the easter eggs and mainly about the theme that gets unlocked (small spoiler there ;)) so i won’t really get too much into it.

WebOS 2 Devlog #17: Media player + Audio spectrum widget implementation

It has been a massive coding session. And I barely managed to keep the time below 10 hours and I still went over it. But, on the bright side, the OS now has a fully functional, media player and an audio spectrum widget! In the media player, anyone can listen to radios, and lots of music. But the reason it took 10 hours is because implementing these stuff required facing some serious bugs-some of them for genuinely stupid mistakes-and rebuilding the audio engine the right way (you’ll see what I mean). Here is a breakdown of how these new features work, what went wrong, and some other stuff:

Overview of features

The Media Player:

The new Media Player is a audio application that routes requests to three distinct APIs to fetch music that the user can listen two:

• Audius: This is a “decentralized music streaming platform for artists, labels, and fans.” And it’s free! I fetches some of the music from this API.

• Radio-Browser: This is a platform that is, in a nutshell, Wikipedia for radios. I fetched thousands of live, global radio broadcasts using this API

• Apple iTunes (Preview): This was a golden find because I didn’t know this existed (not for free anyway). This API pulls top hits and previews of music. Granted, it’s not full music tracks but the songs are much more famous and popular.

The Audio Spectrum Widget

To complement the player, I also added an Audio Spectrum visualizer. It uses the Web Audio API, or more specifically, its AudioContext and an AnalyserNode to get the frequency data from the audio element. That data is then mapped to an HTML5 element. Using requestAnimationFrame, I made it such that the spectrum repaints 40 individual frequency bars roughly 60 times a second, which creates the audio visualiser waveform thing.

Challenges

• The Geolocation failure:

The OS was originally hardcoded to fetch radio stations from my address because I hardcoded that for testing purposes. But I stupidly forgot to remove that so when attempting to make this dynamic by using vpns I spent like 40 minutes trying to figure out why ut kept showing stations from my local area and not japan (where my VPN was connected to). And the reason for that is the hardcoded address I mentioned earlier. Moreover, some of the API queries were too specific, causing the media player to return empty for smaller regions like the Bahamas. To fix it i used the BigDataCloud API to quietly ping the user’s IP address, cache their true country code, and inject it into the API queries.

• the broken audio spectrum:

Initially, the audio visualizer was completely blank. Even when fixed, the baseline would just disappear the second music started playing. The canvas drawing logic was also aggressively using clearRect to wipe the entire widget, which erased the idle state baseline. To fix it, I changed the baseline math so that the baseline sits firmly at the bottom of the widget. I also remade the drawing loop to explicitly redraw the baseline before checking the isPlaying state, so the frequency bars can work smoothly.

• retro theme problems:

I completely forgot about the retro theme as i was just focused on building the player and the widget. So, in the end i had to make the stuff retro theme aswell. I encountered some problems there like some white on white text and some styles not applying which turned out to be because my dumbass brain mispelled the ids and classes

• Oh, and I found some other big bugs. The dragging engine was hella laggy. Like the response time was like 3 seconds before it registered. I would go deeped but im abt to cross the 4000 character devlog word limit but in a nutshell I realised it was because the mousemove event listener was directly updating the inline CSS (style.left and style.top) on every single microscopic mouse movement so it was really laggy.

OrbitLens Devlog #2: Adding ISS + Orbit

This session was mainly focused on implementing the ISS first to the satellite tracker. Here are the changes I made:

Satellite Data Extraction and ISS Positioning

To understand what I did in this session, it is important to know how I can get the ‘live’ location of the ISS works:

• firstly, satellites don’t broadcast live GPS coordinates to the internet. Instead, radars track them and publish Two-Line Element (TLE) sets. A TLE is like a raw string that “acts as a mathematical variable of an orbit’s shape at a specific moment.” I got these TLE from a non-profit API called CelesTrak.

• these TLEs are kinda useless so I used the satellite.js library to parse te TLEs. This js engine also allows you to run what is known as SGP4 models (Simplified General Perturbations 4) which is a mathematical model used to predict an orbit. Using this, TLEs are then converted to what’s known as Earth-Centered Inertial (ECI) vectors which is a

“non-rotating 3D coordinate system anchored to the center of the Earth with its axes fixed relative to the stars, allowing you to calculate a satellite’s absolute mathematical position in space independent of the Earth spinning beneath it.”

The ECI is still not useful so I passed it through satellite.eciToGeodetic which converted the eci to geodetic coordinates (longitude, latitude and altitude)

But there’s one more step before the data is useful. The thing is Three.js only understands Cartesian coordinates (x, y, z) so the geodetic coordinates need to be converted to catesian. I did that using these mathematical formulas:

x = r * cos(lat) * cos(lon) y = r * sin(lat) z = -r * cos(lat) * sin(lon)

Orbit Implementation

Satellites do not orbit in perfect circles; they follow complex trajectories that shift as the Earth rotates underneath them. The ISS takes roughly 92 minutes to complete one full orbit around the Earth. I captured this entire window by running two separate for loops. For these loops, i created 92 differed Date objects spaced exactly 1 second apart. here are the loops and how they work in a small nutshell:

• The Past: I looped backward from -46 minutes up to 0 (the current moment) and inputted the X, Y, and Z coordinates in each loop into THREE.BufferGeometry to draw a solid yellow LineBasicMaterial.

• The Future: I looped forward from 0 to +46 minutes. In every single iteration of those loops, and did the same thing.

Challenges:

• the hemisphere and orbit were originally flipped or were completely false so i had to wrack my brain and dind the cause. I spent more than an hour debugging this. Turns out the formula was wrong and i used sin instaed of cos.

In te end, I also double checked my orbit and position with official ISS trackers, and they matched!

OrbitLens Devlog #1: Rendering the Earth 3D

I just kick started this project, Orbit Lens, and my aim is to build a fully free, real-time 3D satellite tracker from scratch using Three.js and maybe some other libraries. Today was all about creating the core 3D arch. You can’t track a satellite without a planet to orbit, so Phase 1 was focused on rendering the Earth and setting up the Three.js environment.

What I accomplished in Phase 1:

• Set up my environment with Vite
• Built the Three.js scene, camera, and render loop.
• Rendered a 3D Earth utilizing maps from solar system scope.
• Enabled OrbitControls to enable camera panning

This is just the basic foundations of the project so there’ll be much more development in the future.

WebOS 2 Devlog #16: Widget implementation + debugging

In this session, i made multiple changes to the OS to improve the overall UX. I had to pull another all nighter again 🥲. Here is what i changed:

Change 1: Debugging

• Everytime i enabled the system daemon in the settngs, the entire os reloaded which was quite annoying so I ripped out the location.reload() in the Settings app. I also moved him to the body so he didn’t get trapped behind windows, because most of the time the daemon was floating behind windows and i couldnt really see him.

• I also gave the Welcome screen a massive 9999999 z-index so the daemon would float behind it because my previous step was too effective and he was infront of every single screen including like the bootloading screen.

Challenges: I ran into z-index hell because I didn’t plan the stacking initially. He was either in the very front or at the very back and it was all a bit weird.

Change 2: Widget implementation

• I initially wanted to implement sticky notes as a widget which was inspired my the mac sticky notes so i coded all of that in first but I realised i can take it a step further and code in multiple widgets.

Challenge: But the thing was i hardcoded the sticky notes widget so i had to recode everything and integrate all of the widgets at once

• I added a simple analog clock widget
• I added a calendar widget
• I initially added a system monitor with like the ram and cpu data but the thing was due to the security restrictions, I can’t get the actualy live hardware data so it would have to be a simulation, which i didnt want so I replace the system monitor with a live weather widget which uses the BigDataCloud and Open-Meteo APIs to provide weather data.

Change 3:

Originally I had all hte widgets in the context menu on after the other but they looked like a list and a bit redundant. So i removed all then in the html file and added one ‘Add a widget…’ option which connects to a screen with all the widget options

WebOS 2 Devlog #15: System Daemon implementation

To keep the users more engaged so even when they saw everythign, they would still spend more time doing stuff, I wanted to build something alive for the desktop environment that would interact with the user. So, instead of a standard app, I built a system daemon! If you dont know what that is, it is a digital pet that hangs out on your desktop and does random stuff. I dont hav ea name for him yet so ill just call him daemon for now. When he’s healthy, he flies around the screen and shouts random stuff at you.

But I didn’t want him to just be a visual gimmick. He interacts with the actual operating system itself and has states:

• He is hungry: Because I previously built a drag-and-drop system for the File Explorer, I hooked him into it. You can drag actual text files or folders out of your explorer and drop them on his face. He will chew them up and literally delete them from the virtual hard drive (localStorage).

• He has a digestive tract: I built a array for his stomach that records what he has last eaten. If he ate a file you actually needed, you can rapid-click his face 5 times. He will regurgitate the raw file data perfectly back onto your desktop.

• He has boundaries: I ‘taught’ him to recognize core OS files. If you try to feed him Notepad.app or the System Settings, he will violently reject them and yell at you.

• He has one more state but that relates to the easter egg so i wont provide any additional details in order to not spoil it

Oh, and i changed his appearance for the retro theme.

anywhat that’s all for this change. I didn’t get into the nitty gritty of how I built him because I am so excited to finish this project. Just a few more features and then I’m done.

WebOS 2 Devlog #14: Easter Eggs Pt. 2

I am now done with making the easter eggs and in total i made 5 of them, which may seem less but some of them are really really complex and developed. I stayed up till 2am making these 😭. Out of these 5, three of them are simple easter eggs, one is more complex but still quite simple and the final one is essentialyl the absolut highlight. It is the reason why the easter egg section took me so long. I am not going to go into detail to avoid spoilers. Anyway i hope you have fun with the easter eggs :)
p.s the attached pic is a screen shot again cus i dont want to give spoilers

WebOS 2 Devlog #13: Easter Eggs Pt. 1

I was looking forward to this a looooot. I’m not giving any spoilers whatsoever but I was so locked in tday and yesterday coding easter eggs into the OS. I added like 2 easter eggs (might seem less but trust me they’re very developed), one’s a very simple one but the other one is my favourite and is the reason this devlog took so long. It’s still not finished and im only lik halfway done w/ it but I’m not going to go into any details because it will spoil the fun but im sure you’ll enjoy it. Also, im not done with making easter eggs and i just made this devlog cus the time is almost 10hrs. I still have to finish the second easter egg and do more on top of that. The next one will hopefully be the final easter egg session (unless i get another absolute brainwave).

p.s to prevent spoilers, the attached pic is just a screenshot once again

WebOS 2 Devlog #12: Debugging Session + retro theme redesign

In this session I started debugging the os and wow i found a lot of bugs. Im not going to get into them because it would take too long but some of them include how the bootloading sequence absolutely breaks if the user presses escape before the setup is finished because the cache isnt cleared properly so when the user gets the setup agian, he wont we able to configure some stuff like the password because the cache wasnt cleared properly.

I also redesigned the retro theme because it looked ugly because the accents i implemented in the modern theme appeared in the retro theme which didnt fit together. Moreover, some of the aspects of the retro theme, such as the top part of the web browser or the settings screen were just uncomfortable to look at. Changing the retro theme was such a pain because everytime i thought i fixed it, a new discrepancy appears and at one point after i fixed it, my retro-theme.css was so messy i couldnt be bothered to fix it so i just inputted the messy working version into gemini and it cleaned it up. Anyway that was all i changed this time. And I did more and more changes but many of them are small and it would take too long to explain in a devlog.
p.s. didnt know which pic to attach so its just a simple screenshot of the desktop.

WebOS 2 Devlog #11: Reset btn + Notepad IDE + other changes

This was a long long coding session. Had to stay awake till like 2am. Here are the changes i made. Ill try to keep everythign concise because theres a 4000 char limit and i have lot more to say than that.

Change 1:

I added a factory reset button in settings that directs the user to the webos setup screen like the one they get when they first enter the website. When testing this feature, i realised that random variables from completely different web projects started appearing in the File Manager. Because browsers share localStorage databases across the same local port (e.g., 127.0.0.1:5500), the OS was inheriting the ghosts of old projects.

The solution:

I had to upgrade the Initial Setup Utility. When formatting the Virtual Hard Drive, the system now temporarily caches the user’s OS credentials in memory that they entered, executes a total localStorage.clear() wipe to delete all the localStorage varialbles, and then safely restores the username and stuff before continuing normally.

Change 2: Notepad IDE

This was the part that took the longest (and its still not done). I wanted to create something absolutely unique that i havent seen in any other webos projects that i saw. And i realised, why dont i make an IDE in me webos? Not an actual IDE ofc but the goal was to allow users to write raw HTML/JS in the Notepad, save it as a .app file, and double-click it on the desktop to launch it as a fully functioning, program.

Attempt 1 (Failure):

I initially tried parsing the saved text and running it directly in the OS context using eval(). It was an absolute security and stability nightmare. The custom app had root access to the OS memory and instantly overwrote the osState object, completely crashing the Window Manager within seconds.

Attempt 2 (Failure):

I tried fixing attempt 1 but messed up the entire code in the process so i had to revert to that commit and this time, i tried putting the apps in Web Components and the Shadow DOM. While this successfully isolated the CSS so custom apps didn’t break the OS styling, the JavaScript still executed in the global window scope. Running two different custom apps simultaneously caused variable collisions that bricked the taskbar. It was too complex and fundamentally flawed.

I wiped the slate clean again.

Attempt 3 (Success):

I realised that the answer was looking straignt at me. I was so stupid. I can just take the code and slap it on to an , and it runs it, just like how i made the web browser. The solution was that When a user double-clicks a custom .app, the OS takes the raw code and converts it into a text/html Blob. It then passes that Blob through URL.createObjectURL(), creating a localized URL. By feeding that URL into an , the custom app boots perfectly. I am really proud of this feature. It’s still not fully done but i had to make a devlog since the tracked time almost reached 10hrs.