everything else works fine, you can still click the cookies but there is no cookie

When tabbing through the icons on the desktop, it does not show an outline on the focused element. This way the user does not know which program would be opened. This has to be fixed.

MainOS has to become more optimized for multithreading. Currently it's seemingly running EVERYTHING on the same CPU core. This includes programs (iframes) and pretty much all JavaScript.

Good points to start might be:

• async some JavaScript, maybe also in the helper.js
• make programs (iframes) use different threads than the MainOS core

While the first starting point might be easily possible, it's not as easy for iframes, for some reason.

Make icons accessible not only by the absolute path on IOfs bit also with an alias like "iofs:icon:ICONNAME".
In future (or now) there's supposed to be a icon generator thingy that returns the icons. This will also be able to combine multiple icons, for example.

Using the absolute path to load icons is depreciated

It's confusing to have Paint, Paint32 and Paint HD. You should merge Paint and Paint32 into Pixel Art Maker.

Also consider adding a function to save the pixelarts. The saved file should include the version of the program used to save the file and in the future it should be possible to define / save a custom color pallete.

Put the cursor focus inside the program when a new program is opened

The notifications app has to be redone entirely.

In future it's not supposed to overlay the notifications anymore but become more like the notifications centre on Windows 10.

Currently the notifications don't look nice at all.

The minimize and close buttons aren't displayed correctly on Android, for example. They should be replaced with something that works.

The file explorer is missing some important features:

• Working context menu for each individual file
• Renaming files
• Deleting files
• Creating new files
• Creating new folders
• Renaming folders
• Deleting folders
• Duplicating files
• Uploading / Downloading files to / from iofs
• See file size / properties
• See disk usage
• Temporary folder in sessionStorage() - it flushes itself on shutdown and it doesn't use localStorage()-storage
• Maybe an entire disk volume within sessionStorage() (sessionStorage is independent of localStorage())

iOS likes to override input fields and buttons with its own style. Add CSS to helper.css to prevent that.

There should be a engine or variable that contains most common phrases like "Okay", "Yes", "No", "Abort", "Error", "Warning" in multiple languages. Maybe such phrases in programs could also be automatically replaced and translated onload.

Add random(min, max, decimals, runs = 3) to helper.js.

This is supposed to keep compatibility with MATH.random() but extend it. So you can do random(0,256), for example.
This also can randomize multiple times by using the result in the previous randomisation run as "seed".
This random()-function also will provide the ability to manipulate / predefine the outcome by the developer or even the user in specific cases. Enabling or disabling random-manipulation should become a global system setting. If disabled (default), random() will straight up ignore manipulation requests.

About how it should work or where to start coding:
random() {
MATH.random(); ... -> 82819
randomizeagain(82819)
}

There should be a setting that allows the user to scale the interface. To be more precise, I think there should be 2 settings.

• one for scaling text and images like on Windows XP, for example (I think it was called DPI scaling). This could be done through something like body { font-size: initial * scaling }
• one to scale the entire interface like you would do on Windows 10 for 4k screens - You'd probably set it to 200%. This should be done through transform: scale(0.1 - 8)

This will allow MainOS to work on very small screens. Also it's just more customisation for bigger screens.
Maybe change the defaults depending on the screen size when starting up or maybe even add a setting to scale some things automatically relative to the desired scaling.

The repository of the MainOS core, which includes helper.js, IOfs.js and more, should be seperated from all the programs.

One big reason for this is updating programs. Currently bugs in programs can't be fixed without updating the entire system so bugs need am eternity to get fixed and released.

Currently MainOS uses 120 -> 125 -> 130 -> 135 -> 140 -> ... where versions ending with a 5 are development versions.

This is supposed to change to a more Semantic versioning approach, starting at v. 0.1.
Also development versions will be stated to be development version by appending -dev, for example. (Would result in 0.2-dev, or 0.2-dev2 for example)

When dealing with this, make sure to maintain compatibility with all programs for a while and also make sure to update included- and core programs to use the new scheme.

Keep in mind: Currently (Version 170 / 180) we're kinda still in Beta.

The context menu isn’t available in Safari on iOS 14. Instead when holding down it just selects random stuff.

Add functionality for Touchscreens in Paint HD. Currently you can't interact with the canvas.

Don't use *.innerHTML = OR even += "something" . Instead spawn new HTML elements like described here: https://github.com/Maingron/MainOS/security/code-scanning/1997?query=ref%3Arefs%2Fheads%2Fmaster

This will improve scores, flexibility and accessibility. Might improve some other things too 🤷‍♂️

Assignments to innerHTML/outerHTML properties or calls to insertAdjacentHTML method manipulate DOM directly without any sanitization and should be avoided. Use document.createElement() or similar methods instead.

When updating from a lower version (Tested with 150) to 175, you'll be stuck. You'll see the update screen, it will refresh and then it loops.

What I found out so far is that it will seemingly either just write the old version number into the file again or it won't update the file.

I think MainOS should be reconsidered. Since MainOS is developing towards a more serious direction now and might potentially be used by some Users eventually, there's a important question that should be answered:

Base the GUI off a MainOS CLI or do GUI only and add CLI optionally, later?

While it's possible either way, it should be decided NOW. A CLI is probably hard to write but MainOS is mostly Javascript.
Currently the "Desktop" which is located in index.html has basically Level 0 access. It launches programs and programs can directly talk to it.

If it was based off CLI stuff, it would look more like this:

• Level 0: CLI
• • Level 1: Desktop
• • Level 1: Helper.js
• • • Level 2: Other programs

The CLI is the Root.
The Desktop and Helper.js should then be considered to be some kind of very low level programs.
Other programs would probably still talk to the CLI, like everything would, but the CLI would keep the Programs kind of sandboxed so they can't do everything they want.

This change would provbably require about 90% of MainOS Core and MainOS API to be re-written, but it would grant way more access for developers or through the CLI and it would be more like an actual OS, probably.

Add another variable / setting for the theme color (themecolor 2). By default it would be a darker brown and present a contrast for the maximize button or the info section thingy in the bottom right. User should be able to change that independently.

When saving files, they should be saved in alphabetical order.

Example:

• C:/
• • a/
• • • test.txt
• • b/
• D:/

This will significantly improve read performance in future because we know when to stop reading our file array earlier.
One thing we'll definitely know is that we can stop listing the "C:/"-directory, for example, when hitting "D:/" for the first time and can put that result in our working array.
We then know the same for folders - if "C:/test/test/" is requested, for example, we know that we can begin at "C:/test/test/" and can stop at whatever comes next. And now we actually already have our result.

Will also result in pre-ordered output of directories from listdir().
Might result in slower write speed, though files might be written to a cache and sorted in asynchronously in the background in future.

This probably should be done before releasing a new update.

Maybe MainOS should get some kind of Cookie Banner because it stores all kinds of data on the user's PC.
This will prevent MainOS from running into problems with Cookie Law.

Add a program that checks code of all programs to check for evil code (like direct access to localstorage, which could potentially delete all files with just one very short line).

This should then be cached and hashed. If a hash changes, scan again.

Make sure to also scan externally included files, else someone could just say <script src="https://maingron.com/iamevil.js"></script> and bypass the check. Also the hash for such has to be verified every time.
Maybe hashes for libraries like bootstrap or jquery should be kept for longer so if one program uses bootstrap 1.2 and the other 1.2.1 they don't have to get scanned every time but only the hash and version has to be verified.

In the beginning it might be possible to only check hashes, not Versions or anything else. This would look something like this:

// hashCache = Array with all hashes
// path = path of program. Don't forget files included within that program!
var progHash = hash(path);
if(hashCache.toString().includes(progHash) {
// It's ok
} else {
scanProgram();
}

Folders and files should be able to have color tags and stuff like in Apple, but probably more extensive.

Since .DS_Store seems to be a completely proprietary format, desktop.ini or some custom format would probably implement well.

In explorer the user should be able to enable/disable the color meta and choose how the color should be shown [background, colored dot, colored icon].

Reconsider:

Attach to IOfs file meta or use a file like desktop.ini in every folder? Attaching such information to IOfs file meta would make things easy but it would lock things down to IOfs filesystem and it would probably get lost whenever a zip or similar file is created.
On the other hand: More files mean more clustering and ugh. I do not really want that.

Add a proper theming engine so people can create and install custom .theme.zip-files.
The standard theme should be reworked, too.

Make the escape button close the start menu.
While at it: Also make the Windows key on the keyboard open the start menu, even though it might not work within most browsers.

The master branch should and will soon be changed to main.

Checklist

• Change branch in OSSAR.yml
• Change branch in CodeQL.yml
• Verify everything is still working
• Verify external links

Add a setting that allows to shift images and UI automatically to prevent (OLED) Burn-in.
This is in the same scope as darkmode.
Developers can then ask if pixelshift is true and potentially optimize their code accordingly.

Maybe instead of a boolean, this could be an integer, where 0 and 1 would still be the "normal" 3-4 pixel values but any higher would consider shifting around UI Elements entirely. Maybe a tachometer in a racing game would then switch positions between bottom left, bottom center and bottom right between races.
And a very high value would just mean entire pixel scramble, though this would be increasingly hard to realize within HTML/CSS/JS. Maybe a CSS filter() could then help with that.

Alternatively, there could be an additional temp value for the setting indicating the "step" of pixelshift. For example, if we have a cycle with 4 steps, if the entire UI shifts every step (MainOS Desktop / Program frames PLUS Program contents), this would prevent that a program shifts towards top left while the entire MainOS shifts bottom right. (Because that would mean that UI within the program would be at exactly the same position again and only everything else shifted somewhere)

The diskinfo stuff is broken on iOS (14) in every browser. Says nullKB remaining.
Only saw that bug on iOS so far.

MainOS needs a proper license. I think MIT is too open. Not sure which license to use yet.

A proper license should be chosen pretty soon.

If using MainOS on a touchscreen, you are likely to experience some issues.
One example being the headbar of programs. If you click close, you are likely to interact with the element below.

Todo: Rework the entire headbar code

While at it: Change the icons for close / maximize to actual icons and not characters

Store icons from Desktop and the Start menu in folders within IOfs so they can be modified by the user or the system.

Change the iframe Sandbox attribute so Programms can't create new tabs or Windows in the users browser. This will make sure that everything stays withing MainOS.
This includes JavaScript and s.

You can use the CSS property backdrop-filter: blur(4px) to achieve MacOS / Windows 10 style. You can use this for the context menu or other things. Would also be nice to see this in the Optisocubes start screen. Maybe it'd also be possible to use the user's background iamge in more programs. I think that'd be fluid stylish (Windows 10)

Add a setting that allows for changing the transition times, like in Android Developer settings.

It's only possible to controll the orb in Don't Tag Me - The game using the arrow keys. Maybe consider implementing support for WASD-Keys.

Add features to the helper.js and helper.css. Also don't make program developers use CSS media queries like @media(prefers-color-scheme:dark) but instead add a class to the body with helper.js. This will allow overrides by 1. the user and 2. by the developer, while using the system default by default.

• prefers-color-scheme -> body .dark, .light (Query well supported)
• prefers-reduced-motion -> body .less-motion; Maybe add checkboxes to disable distinct settings (Blurry background; animations; flashing animations(!) (They could get disabled by adding a class, e.g. .flashing)), maybe also consider #6. (Query well supported)
• prefers-reduced-transparency -> body .reduced-transparency (Query not supported by any browser)
• prefers-reduced-data -> I actually don't know. I don't really think this is necessary for MainOS
• prefers-contrast -> body .high-contrast (Query not supported by any browser, there might be another query for this)

After donations from Derry Shribman, adding to a total of 550€, there is a request for an Android-styled approach.

This will be added via a theme (See also #31) and other programs. More information will follow, but here a list received by mail:

I think the Android experience can be broken up into the following apps:

• Home screen app: equivalent to the WinXP "desktop" app: its the shortcuts to apps (favourites) and widgets layed out, and you swipe left-right to move between the screens.
• App draw app: Opened by sliding down the home screen. Its like Opening Start->Program Files, and seeing the full list of applications installed. (The homescreen/desktop only has partial). You slide left-right to move between them.
• Top status bar app: The bar with the time, battery, active services and features indication (today in your WinXP its bottom task bar with the clock and the language). Swiping it downwards opens it to more settings, and a settings icon that clicking it gets you into the detailed settings app.
• Detailed settings app: settings app. Like your WinXP settings app, but in an Android/iphone style.
• 3 button emulation: FUTURE. Will be needed to work nicely also on iphone and desktop browsers.
• Soft keyboard: FUTURE. Will allow creating keyboards in JS, and giving the user his same "OS" feeling, no matter on which mobile or desktop he opens the OS.
• App store: FUTURE here you can search for the the app and "install" it into your app draw and homescreen.

I think it would be a good idea to put a white Github link with icon next to the Email link (1). Maybe that's a good opportunity to put more stuff to that place or even build some kind of link field or even a widgetish field. I think (2) should also move to there, so it's not at a disturbing place.

You can pull a GitHub Wiki with git. This should mean that you can add it as git submodule to MainOS, so you have a documentation inside MainOS itself. This could also allow for help pages for programs.

https://github.com/Maingron/MainOS/security/code-scanning/2011?query=ref%3Arefs%2Fheads%2Fmaster

Consider suspending Program versions for now to bring forward development. I think this would eliminate quite some overhead and we could think of a better versioning system later.

Add a button to the titlebar of programs that allows developers reloading the program

In programs where you could set a custom background, for example, use the desktop background by default.

Add a system setting that defines the default background in programs (which itself is the desktop background, by default) and that allows to adjust the transparency / brightness. Brightness would maybe be around .5 so the background image is in effect much darker and won't distract from using the actual programs. Maybe also add 1-2px blur / backdrop blur.

Probably definitely add the background image to

• Explorer
• Settings
• Optisocubes
• Simple cookie clicker
• helper.js

The Android app FX File Explorer does that: https://play.google.com/store/apps/details?id=nextapp.fx

Add a touch icon so that it looks nice if someone adds MainOS to their homescreen.
While at it, make it so that MainOS opens in fullscreen from this icon and also add a website theme color.

How it looks currently:

Add a button to restart MainOS to the start menu.

Chrome complains when using <img src="iofs:something">

Use a #: or something similar in future. This should also allow IOfs to serve the images instead of having to search through the document and replace the url.

Src #:something.png should result in */exec.html#something.png where helper.js could listen and return the png.

This would be such big improvement - no errors in the console, no constant checks and just cleaner.
Though we have to consider that the entire programs exec.html might be run every time.

Closing a program on touchscreens will trigger program icons below so it is impossible to get back to the desktop. Please fix

Add a program that lists all running processes and can close processes.

The list view should include:

• the program's icon
• the PID
• the program name