modOS
- 7 Devlogs
- 37 Total hours
The open-source modular web-OS
The open-source modular web-OS
After some long work, modOS is finally getting easier to get done. But
it’s not done just yet.
modOS now has some basic API’s, which will be used in the future by
developers to make applications that can be fully integrated into the
ecosystem.
Bootstrap is reaching completion, which will bring us to the next step:
display.
We also have one of the most important functions of an OS, file
management! modOS utilizes zenfs/core to store files and
folders(alongside their structure) in memory! This will allow the
creation of file explorers, document making, and more! This is also a
crucial piece to make a modular OS.
modOS still needs some more API’s, most which will come from packages.
Due to that, the next dev post should be of packer, the official package
manager for modOS. It will be the connectiong between users, database,
and developers.
User <--> Database <--> Developer
Meaning dev’s will be able to publish packages, and user’s will be able
to download them!
And finally, we need an account session thingy to keep track of each
user’s installed packages. This also will allow the usage of YOUR modOS
anywhere!
pretty cool
Here is what I got done ever since I announced modOS Sevda Çiçeği!
So we now have modOS-VT as a GitHub repository. It’s pretty cool. VT stands for Vite Type, indicating how the project utilizes Vite and TypeScript instead of just html and javascript.
I made:
Well, my friend, modOS is completely modular. So there is a bit of contradiction when I need to make a bootstrap that launches things, if there is no things. I worked on making a placeholder for almost everything.
modOS will be just like any other Linux distribution. You have the base system that gives you whatever you need. And you install user-generated content with a package manager! It will be so cool! But right now, I am still working on making the base system part.
PSST! Do you want to contribute to modOS by making an app for it? Well you absolutely can! Right now it’s a bit difficult as there is no modOS. However, you can develop applications using typescript any time! Later modOS versions will come with API’s that you can integrate your app into the modOS ecosystem.
The main challenge was getting started with modOS… again… but when I did start, it starts flowing like butter.
Because modOS-VT is built on Vite, I can use packages and make it easier to use with GitHub pages! I did not have to make 15 commits for a bug fix while setting up GitHub pages!
Thank you. :)
After completing the pretty underdeveloped modOS Cambaz, I think it is time we move on to a full, stable, environment.
Here is a checklist/roadmap for modOS that you can follow as I check off the tasks:
https://docs.google.com/document/d/1H7caegzGowVeYkntmm87eaJ8XJtSyU1Pbvb5vVNmgYI/edit?usp=sharing
Logged hours for this dev post come from earlier bug fixes and polishing to modOS Cambaz alongside the making of modOS Sevda Çiçeği
With the guide finally being done, I announce modOS v1.0.0 Cambaz.
Before I nerd out about everything added, here is more information about Mor ve Ötesi, the band behind Cambaz:
https://en.wikipedia.org/wiki/Mor_ve_%C3%B6tesi
Well, throughout the path of following the guide and making modOS, I completely rejected the idea of a hard-coded anything.
Sure, it might be open-source, but what is the point of open-source if changing the source is going to take many hours of coding?
modOS competes against a permanent webOS.
The following features highlight how modOS achieves that:
modOS does not have any hard-coded applications, bar, desktop, etc.
Every app is found in a JSON file (apps.json located in /base/system/) which can be modified to install any application you want, easily! Currently this step is manual, and there is no official repository of verified applications. However, that is subject to change.
Bartender (the bar system of modOS) is a JavaScript file (bartender.js found in /base/system/bartender.js) which can be modified to make the bar whatever you want!
WER (Window Manager for modOS) is a script that inserts window functions such as the minimize and close buttons alongside the name of the window, icon, and movement system. The whole script is launched with initwindow(win) where win is the main window element.
Got confused with the initwindow(win) command? Not to worry, modOS comes with the exec command, which follows the format exec(appname, icon), where you can determine the name of the application (REQUIRED) and its icon (NOT REQUIRED). Whenever the command is run, the script (exec.js found in /base/system/) looks through apps.json and pulls the necessary content and scripts, giving you a fully functional app.
Note: If you decide to use a custom icon with an existing app, exec.js will still use the icon used in the database to maintain the developers creativity!
So are you even more lazy? Cuz modOS desktop shows every app in apps.json for easier access. All you need is the ability to double click the app you want!
Note: Psst! There are hidden applications. You need to run showhidden() to show them, and hidehidden() if you would like to hide them back.
You can customize modOS off of the base CSS by editing config.css (config.css found in /system/user/)
A signup/login system is planned to be added for cross-platform sync ability (e.g. apps, settings, customizations, etc). This will be optional and you can still use modOS as a guest.
modOS developer mode: A way for you to build applications for you and others on modOS!
Window minimization: Currently, windows do get minimized. However, you really cannot un-minimize them without running the command document.querySelector(".win").style.display="block", which is unreliable and annoying.
More applications: You will use modOS developer mode to develop applications for the ecosystem. No more work for me.
Here is an update of what I’ve been working on over the weekend. And there is a lot!
I followed the guide to make windows movable. However, there was a challenge.
If I want to make modOS modular, how could I identify user-made windows? The guide showed a hard-coded movement system, but that would mean other people couldn’t make their own apps!
I used .querySelector to give every window of the same class movement functionality while keeping each instance separate. This means no matter how many windows of the same app you make, they’ll all be movable! So yes, you could have 30 copies of the same ping pong app (not on modOS… yet) and every window would work normally.
This is mainly what took most of the 7 hours I logged today.
I used Firebase to establish a backend where user info would be stored. The info consists of a username, password, and user data. The first two are self-explanatory, but the data will store user changes to their OS so they can jump back in where they left off.
The account creation script should theoretically work. However, I didn’t build the project around a package manager. Firebase works much better with one, meaning the project would need to be migrated to a framework like Vite.
There is a solution: create a new repository with Vite installed, then move everything over. I really didn’t want to deal with that right now, so the account feature will be implemented once the base build of modOS is complete.
You can now use a terminal interface to launch apps!
To keep apps modular while still being… apps, I couldn’t just say “open this app.” I needed users to be able to define a preferred name, icon, and content. The first two were easy, but I also needed a list of apps and their content. This way, future modOS developers can publish their applications to the modOS environment.
There is now an apps.json file with a full list of apps (1 app right now). Whenever you launch an app via exec(name, icon) from the Dev Console, it checks whether the app exists in the JSON file and, if it does, fetches its corresponding content.
modOS is officially MODULAR!
Many things!
exec(name, icon) in the Dev Console (often opened with F12) to render a new window with your preferred name and icon.Making things modular takes a lot of time. You don’t just write your program in HTML anymore—you have to generate it through JavaScript. To make it modular, individual variables need to go through their own processes before everything connects together. And of course… that usually comes with a bug or two.
Uh… yeah, that was the challenge. Doesn’t really need a solution.
From now on, every new release will be named after a song from a 2000s Turkish Alternative Rock band.
The next major release will be called:
modOS v0.x.x-alpha [Mor Ve Ötesi - Cambaz]
Make sure you give it a listen. It’s a banger!
I think the project is going very well. It’s taking a lot of time, but it’s worthwhile since I’m learning new things about a programming language I’ve been using for five years now.
I’m hoping to add more features, finish the base build, and finally move on to the backend side of things.
Today, I did not do much visual progress. However, there is way more that goes on in the background.
I’m glad you asked. Unlike a traditional clock, this clock actually is separated in multiple tags. That means you can move the tags around to change the order of the clock values.
This Dev Post is sponsored by wttr.in! With it’s simple, no sign-up, and no data limit, wttr.in is in my top 5 API’s. With a single fetch, we achieve great things like burnin’ hot weather.
This is a base release for an early preview of the main idea for modOS.
Notes:
Although the project is supposed to be modular, it is still in early development. So every line is hard-coded and is not modular.