heavy owl
Zerotty is a terminal emulator project. It focuses on cross-compilation, native execution, and low-level design to achieve high speed and performance across various operating systems.
The project isn't finished yet (it doesn't even have a completed testing app), but I'd like to hear some feedback about how I've structured the code and implemented the cross-compiled OS features, and how they can be improved.
NOTE:
repo moved to codeberg
heavy owl
heavy owl
neon thicket
Nice! I was wondering what inspired your application architecture/structure? What's the idea behind it's internal compoments?
I find that's the part I struggle with most. Currently trying to restructure my project in a more data oriented architecture. But i still have to see if it will work out
heavy owl
The architecture is mostly OOP (not a big fan of OOP but inspired by game-dev) with some common design patterns. Since most of the project is platform-dependent, I solved that by splitting implementations into separate objects (e.g. Win32Window, XcbWindow) behind a unified interface (Window.create, Window.open). This way, I can swap out the backend without changing the higher-level code.
The bigger challenge, though, is making the system components compatible with each other. For example, XCB doesn’t support GLX directly, and the Xlib + OpenGL window implementation overlaps with the Vulkan path. So a lot of my effort has gone into resolving those kinds of intersections.
So i think i need to change this architecture soon 😆
neon thicket
Yeah, that's the thing. Ideally I'd want to design application that doesn't care which systems/components are currently enabled - the internal data model has to remain the same and abstract enough for all other components to be able to cooperate. But that's why i'm wondering since I don't have enough experience with these kinds of abstractions - what scales and performs well.
My project also has custom TUI as part of it hence why i'm wondering about how this works. My project is here btw: https://smash.tase.lv
Currently working on uncommited refactor to create shared abstract state between multiple systems/components.
It's currently bit chaotic since I'm currently in phase where I'm actively avoiding OOP patterns but at same time not sure what to settle on instead.
heavy owl
As I said, the project is "mostly OOP," but it’s not strictly OOP. It started with an OOP idea, but it didn’t scale well as I continued working on it.
Then, I naturally found myself following another style called "Module-Oriented Programming." I didn’t know the name at the time, but as I said, I don’t like OOP.
The big difference between OOP and MOP is that OOP is about how objects behave, while MOP is about splitting code into logical units.
For example, my Window object is represented as a directory
src/window
├── root.zig
├── Win32.zig
├── Xcb.zig
└── Xlib.zig
root.zig:
pub const Api = @import("build_options").@"window-system";
pub const Window = switch (Api) {
.Win32 => @import("Win32.zig"),
.Xlib => @import("Xlib.zig"),
.Xcb => @import("Xcb.zig"),
};
Each object is a completely separate logic unit, while still sharing some common interfaces.
here you can find more about MOP
https://stackoverflow.com/questions/18034683/what-is-the-big-difference-between-modular-and-object-oriented-programming
neon thicket
Yeah, I was also going for modules, but realised that I'm not sure how best to pull off communication between the modules. I started off with messaging system but even at small scale that started to get messy, so instead now I'll see if modules can cooperate using shared state which doesn't use any specific module's exposed types, so that the application core state structure doesn't change by unplugging and plugging modules. Trying to design the shared state following similar design practices that one would apply to relational databases, since those have been time proven to scale with complex applications.
