angelic-kernel 0.3

A fake OS kernel framework for Python

Angelic-Kernel

Have you ever, and I mean EVER wanted to create an OS but then tried to and then thought, "nah, I'll stick to python" but still want to create an OS?

Well, you can now, okay, not a real OS, however, with Angelic-Kernel you can make a python program that feels like one, now lets get right into it!

Sections:

1. Installation
2. Documentation
3. Versions

Installation

for installing angelic-kernel, use this command.

pip install angelic-kernel

Documentation

Okay, I really don't want to write a full documentation, but at the same time I don't want anyone to be in the dark and so it makes sense. So this is the entire documentation for all versions, to see specific data about specific versions go to the version section and find the version that you have and click the link. It will take you to the full documentation with everything about that version. Writing these documentations take 3-5 hours depending on how much is in the version, I write them anyway just so people actually understand what's in the version. And inside the documentation you can find; the change log, the tutorial on how to use angelic-kernel, code examples that work for the version and notes. Now, enough talking about what's in the documentations lets get right to them!

Documentation for 0.1

Sections:
Change log
Documentation
Examples
Notes

Change log

Created Kernel class
Created SD subclass for the Kernel class
Created screen subclass for the Kernel class
Created sound subclass for the Kernel class
Created file_system subclass for the Kernel class

Documentation

Alright, even though this is literally the first version of angelic-kernel, it's feature-rich, made with 500+ lines and five main classes, if you took a peek at the change log you should be able to identify which ones; the Kernel, SD, screen, sound, and file_system classes that each play important roles for our code, lets first start with the Kernel class:

First lets setup

from angelic_kernel import *
k=Kernel()

Now hopefully you know what's going on here, but if you don't I'll explain, from angelic_kernel import * imports all the classes that I stuffed into this thing, and k=Kernel() sets the k variable to a Kernel() instance, now let's expand it.

from angelic_kernel import *
k=Kernel()
sd=k.SD()
sc=k.screen(640,600,sd)
sound=k.sound(sd)
fs=k.file_system(sd)

Now, let's explain each line of new code; sd=k.SD() sets the sd variable to a Kernel.SD instance, sc=k.screen(640,600,sd) sets the sc variable to a Kernel.screen instance, the first and second input is the width and height of the screen, the last input is the sd instance we defined earlier, sound=k.sound(sd) sets the sound variable to a Kernel.sound instance with the only input being the sd instance we defined earlier see a pattern yet? fs=k.file_system(sd) sets the fs variable to a Kernel.file_system instance with the only input being the sd instance we defined earlier

Okay, now lets actually get into the classes, we'll skip SD because there's not much in it, and it doesn't really do anything useful other than provide basic SD saving for the other classes that's why they need it

sections:
screen
sound
file_system

Screen class

Basic info

The screen class manages a window with APIs for Graphics and GUI, the GUI engine used is pygame, so if you have even basic knowledge of pygame then this should be easy to use. If not, don't worry, I've spent several days making the screen class WAY easier than raw pygame so this shouldn't be too bad.

Core commands:

Core commands are commands that most likely will be used a LOT when using the screen class so, lets list them before we go over what they actually do.
clear()
clear_logs()
frame()
events()
shift()
Alright, now that we got them down, lets go through them one by one and explain what they do.
clear(): clears the screen; clear() has no inputs however originally clear() was going to have an input for clearing the text logs, but that idea was scrapped for clear_logs(), on that note, clear() does not clear the text logs we'll get into more detail about the text logs soon when we talk about print(),input(), and set_font().

clear_logs(): clears the text logs; clear_logs() clears the text logs, preventing text from showing up when input is called.

frame(): displays the next frame; frame() does one job, display the next frame, when clear() is called the current frame says "Nah, I'm out" and disappears, however in order to see the changes you have to call frame(), the only input is the tick input which pauses for a bit to keep the frame rate under control and defaults to 60 so the GUI doesn't run at CPU clock speeds which is around 2.5 GHz and 4.0 GHz by the time I wrote this

events(): returns the current event; events() does a lot of jobs at once, but all you need to know is what events it returns; when a key is pressed it returns ("keydown",key_name) with the second output being the key's name, the opposite of this is ("keyup",key_name) this is returned when a key is released, with the second output being the name of the key, ("mousedown",(mouse_pos_x,mouse_pos_y)) is returned when the mouse clicks inside the window, the second output is a tuple of two values, value 1 being the x position of the mouse and value 2 being the y position of the mouse, (None,None) this is returned when None of the events that I listed here happened.

shift(): returns the shifted equivalent of the inputted key; shift() literally just presses shift for you, when you input a shiftable letter, say, "a" for example, it returns "A", which if you've ever typed in all caps when sending a totally formal letter to someone you where mad at, you know that the shifted letter of "a" is "A", and if you're a coder, like me, your example is if you input "[" it will output "{", just like pressing shift on a keyboard.

Text commands:

text commands are stuff like print() and input() but also set_font()? yeah, to explain what's going on here, we're going to have to dive in so lets list then explain
set_font()
print()
input()
Now time to explain

set_font():sets the font; this one surprisingly is simple even though it's one of the commands that I spent over an hour working on, the first input is the mode, it accepts 1 or 2 as an input, if the mode is 1 it sets the font to an external font file like a .ttf file if it is set to 2 then it uses a system font like Arial. The second input is the font name or the font file name. if you set the mode to 1 previously then set the font input to the name of the font file, note that the font file has to be inside the same folder as your script. if you set the mode to 2 then set the input to the name of the font, note that the name of the font has to be installed on your computer. the last input is the size input, and luckily this one doesn't change depending on the mode, just enter the size that you want the text to be.

print(): prints onto the screen window; this one literally is pythons print() function for the window, the first input is the text, simple, the next two is the x and y position of the text, the next? the color, it's a tuple of three values up to 255, the last two actually are kinda important, the second-to-last one is add_to_text_log, which is a bool True or False. If it's true then it adds the text to the text logs, and it will appear when input() is called. if it's false then it won't touch the text logs, the last is really important and extremely useful, blit_surface sets the blit surface, that's it, we'll talk about surfaces later...

input(): creates a text prompt on the screen window; this one took me five hours to make, and I'm not joking this time, with how much I crammed into this thing it takes up 100+ lines of the file, just to create a basic input function. Anyway enough with the lore of this extremely overweight function, lets get into the inputs. The first input is the prompt input, it's just the prompt text, the next is the base_prompt input which sets the base text that appears when you call it. The third and fourth input is the x and y pos of the prompt the fifth input is the color, and the last is the blit surface

Sprite commands:

This was simple enough to create, and since there's like ten commands here I'm going to try and keep it short, but there's just a lot of important stuff here so... yeah...
add_sprite()
render_sprites()
move_sprite()
set_sprite_pos()
set_sprite_image()
kill_sprite()
sprite_touching_sprite()
sprite_touching_mouse()
sprite_click()
scale_sprite()
Alright time to explain what each of these do there's so many :( add_sprite(): Adds a sprite; the only input is the name of the sprite, remember the name it's important for most of the next commands

render_sprites(): renders ALL sprites; that's it.

move_sprite(): moves the inputted sprite; this is simple the first input is of course the name of the sprite with the second and third input being the x and y had to rewrite this, fell asleep halfway through writing this hah...

set_sprite_pos(): sets the inputted sprite's position; that's literally all this does, the first input is the name of the sprite and the second and third is the x and y of the sprite

set_sprite_image(): sets the inputted sprite's image; the first input is the name of the sprite and the second is the name of the image file, note that the image must be in the same folder as the script.

kill_sprite(): "kills" the inputted sprite; don't worry it only deletes the inputted sprite the only input is the name of the sprite

sprite_touching_sprite(): returns True if the first sprite inputted is touching the second input; in less confusing terms, if the sprite with the name of the first input is touching the sprite with the name of the second input it returns true, else, it returns false

sprite_touching_mouse():returns True if the inputted sprite is touching the mouse; that's it the first input is the name of the sprite

sprite_click(): returns True if the inputted sprite was clicked; that's it, the first input is the name of the sprite the second should be the output of events()

scale_sprite(): scales the inputted sprite; that's it, the first input is the name of the sprite and the second and third is the width and height

Surface commands:

Okay this one is much shorter than the sprite second, but uh... yeah, it's in the screen class, we have to go over them... GOD-
surface()
render_surfaces()
surface_click()
surface_touching_mouse()
kill_surface()
Alright now the explanation.../ surface(): creates a surface; this one is one of the functions that have too many inputs, so uh, prepare for me to talk for an hour. The first input is the name and the second and third is the x and y position, forth and fifth is width and height and the last is the color, Huh... that actually wasn't so bad...

render_surfaces(): renders ALL surfaces; that's it, no inputs

surface_click(): returns true if the inputted surface was clicked; the first input is the name of the surface while the second is the event, the event must be the output of the events() command

surface_touching_mouse(): returns true if the inputted surface was touching the mouse; that's it the only input is the name of the surface

kill_surface(): don't worry it only deletes the surface; the only input is the name of the surface

misc commands:

these are just some helper commands that don't really belong to a group of commands so they are just misc quit()
wait()
set_window_name()
set_window_icon()
mouse_down()
is_held()
mouse_pos()
now for the explanation

quit(): exits the program; that's literally it no inputs

wait(): waits the inputted time; that's it, the only input is the time

set_window_name(): sets the screen window's name with the input; that's it the only input is the name

set_window_icon(): sets the window icon to the inputted file; the file must be in the same folder as the script

mouse_down(): returns true if the mouse is held down; that's it no inputs

is_held(): returns true if the inputted key is held down; the only input is the name of the key

mouse_pos(): returns the mouse position; no inputs, but just as a warning, it returns the mouse's position as a tuple

wow... that was a lot... and we're not even done, we still have two classes to go...

Sound class

Basic info:

the sound class is overly simple, and currently only has three commands, so lets get into them

All commands:

Alright lets list the three commands and then explain what they do add_sound()
play_sound()
stop()
Alright now for the explanation

add_sound(): adds a sound to the sound cache; on its own it doesn't play anything, you need to call play_sound() for them to play, the only input is the sound input and the sound file has to be in the same folder as the script

play_sound(): plays the inputted sound; it only plays the sound if it was in the sound cache, if it's not then nothing will happen.

stop(): stops the inputted sound; the sound must be in the sound cache, if not then it won't do anything

Alright that's all for the Sound class. Now it's time for the last one, the file_system class, which with how BIG it is it's probably competing with the screen class in terms of how much does it take up the file!

File_system class

Basic info:

There's a lot in this one. And even though most of the commands are microscopic and easy to explain, there's a LOT of them and I mean 25+ commands and even though the screen class has more commands 30 commands by the way there's just a LOT but uh... yeah... I have to go through them...

Useful Tools:

These are some Useful tools and yeah, they help a LOT. Anyway, lets get into them
set_root()
goto()
back()
list_dir()
current_path()
Alright lets explain what these do

set_root(): sets the root for the file system; the input is a list, for example if the root is C/Users/User1/Home, then the input would be ["C","Users","User1","Home"], and here's a few notes about this though, the paths have to exist, or it will raise a PathError, when you set the root you Cannot go back farther than the root that's the entire reason the root exists!

goto(): goes to the inputted path; if the path doesn't exist, is protected, hidden, a file, or the TypeID identifier it will raise Errors, the only input is the path

back(): goes back to the last path; if the path is at the root then it says "Nah, can't go back farther", and raises a PathError

list_dir(): lists the current directory; it skips over Type Identifiers, protected dirs, and hidden dirs

current_path(): returns the current path; that's literally it.

"Make" Tools:

these basically are just functions that make paths, that's basically all they do, now lets list them and then explain them:
make_dir()
make_file()
make_protected()
make_hidden()
now let's explain them, this is taking WAY to long, it's been 4+ hours :( make_dir():makes a dir; the only input is the name, just as a disclaimer, the name shouldn't already exist, or it will throw Errors make_file(): makes a file; the three inputs are the name, the file_type, and the data, the path shouldn't already exist, or it will throw Errors make_protected(): make a protected path; the only input is the name, and the name shouldn't already exist make_hidden(): makes a hidden path; the only input is the name, and the name shouldn't already exist

"delete" Tools:

These tools delete stuff, couldn't be simpler well, maybe it could if there weren't so many of them AGH
delete_dir()
delete_file()
delete_protected()
delete_hidden()
Alright now time to explain them... delete_dir(): deletes the inputted dir; that's it the only input is the name and the dir has to already exist

delete_file(): deletes the inputted file; the only input is the file name and the file has to already exist

delete_protected(): deletes the inputted protected path; this one is different from the others, yes, it still has the name input as the first input, but there's also the force input and if you don't set it to True then it's going to raise a PermissionError

delete_hidden(): deletes the inputted hidden path, that's it the path has to exist and has to be hidden

"Check" Tools:

these functions check for stuff, good if you don't want your code to be littered with try and except functions path_exists()
path_is_dir()
path_is_file()
path_is_protected()
path_is_hidden()
file_is_type()
is_root()
Wow.... There's a lot here... path_exists(): returns true if the inputted path exists; that's it

path_is_dir(): returns true if the inputted path is a dir; that's it

path_is_file(): returns true if the inputted path is a file; that's it

path_is_protected(): returns true if the inputted path is protected; that's it

file_is_type(): returns true if the inputted file is the second input which is the file type; that's it

is_root(): returns true if the path is at the set root; that's it

"Open" Tools:

These tools open files, however I'm going to tell you here so I can save you time the files must exist or all of the functions will raise errors
open_file()
open_protected()
open_hidden()
Alright now to explain
open_file(): returns the data of the inputted file; the only input is the file name,

open_protected(): returns the data of the protected path; the only input is the path name

open_hidden(): returns the data of a hidden path, the only name is the name of the path

"modify" Tools:

Alright, I'm on the brink of falling asleep, but luckily for me, we only have two commands here modify_hidden()
modify_file()
Alright now to explain
modify_hidden(): modifies a hidden path, the first input is the name and the second is the key you want to modify, and the last is just the value, the hidden path must exist for it will raise an Error

modify_file(): modifies a file, the first input is the name the second is the key you want to modify and the last is the value you want to set it to, the file must exist, or it raises an Error

Examples

Experimenting, come back in a later update...

Notes

none lol

Documentation for 0.2

Sections:
Change log
Documentation
Examples
Notes

Change log

Fixed __init__ glitch

Documentation

Not much to say here other than, I FINALLY FIXED THE SCRIPT'S INIT GLICH!

Examples

Experimenting, come back in a later update...

Notes

none lol

Documentation for 0.3

Sections:
Change log
Documentation
Examples
Notes

Change log

Fixed __init__ glitch

Documentation

Not much to say here other than, I FINALLY FIXED THE SCRIPT'S INIT GLICH!

Examples

Experimenting, come back in a later update...

Notes

none lol

Versions

disclaimer; these dates are in the MM/DD/YYYY format

0.1: [3/7/2026] Release date. Version Documentation 0.2: [3/7/2026] __init__ bug fix wave one. Version Documentation 0.3: [3/8/2026] __init__ bug fix wave two Version Documantation