Norb's Space

Simply Nord

Thu, 19 Feb 2026 00:00:00 GMT

Two weeks ago I decided to make the switch from Windows to Arch Linux. When selecting a desktop environment, I found myself choosing between KDE Plasma and GNOME. Having used GNOME before, I decided to give KDE Plasma a try, since I have heard that it is highly customizable.

I like KDE Plasma for its clean interface and powerful customization options, but the default theme seems less modern compared to the polished and unified look of GNOME. Therefore I decided to remix my own theme for KDE Plasma, based on the popular Nord color palette.

Technically, Simply Nord is not a theme, but rather a collection of themes, kwin scripts, widgets, panels and many more customizations, all combined to provide a beautiful, minimalistic desktop experience. I drew inspiration from GNOME, Dank Material Theme, and multiple desktop designs, recreating a keyboard-driven workflow that blends productivity and aesthetics.

In this blog post, I will share the process of creating Simply Nord, so that you can easily set it up on your KDE Plasma desktop.

Designing the Workflow

Looks are important, but what is more important is the workflow behind the design. It is always important to take a while to think about how you wish to access the myriad of applications and actions provided by the desktop environment. Think about how you want to launch applications, access opened windows, switch between workspaces, and so on. Be consistent in your design, and use your desired workflow to guide your design decisions.

For Simply Nord, the workflow I chose is aggressively keyboard-driven. I got rid of the task manager altogether, and chose to rely on KRunner to launch applications and the Window Switcher to switch between opened windows. I work on a laptop, and frequently do not use a mouse, so I extended the touchpad gestures. I use three-finger swipes to open the Overview Effect, and four-finger swipes to switch between workspaces. The strong emphasis on keyboard and touchpad navigation allowed me to create a clean and minimalistic desktop.

If you are interested in adopting the theme, but are uncomfortable with a keyboard-driven workflow, you should consider adding a task manager and modifying the shortkeys to your liking. This is the primary reason why I chose to produce a blog tutorial instead of a ready-to-use, drop-and-go konsave archive.

First Things First: Backup Your Theme

Before you start modifying your desktop, it is always a good idea to make a backup of your current configuration. The latest edition of KDE Plasma already provides built-in support for exporting and importing desktop configurations, but for complex setups like this I prefer to use Konsave since it is more flexible.

konsave --save kde-standard

After this, you should be ready to start modifying your desktop. You can always restore the backup using the following command:

konsave --apply kde-standard

Playing with Panels

In KDE Plasma, the default panel closely resembles the Windows taskbar. It spans the entire width of the screen and contains primarily a task manager as well as the system tray. Classic design as it is, it does not fit the modern and minimalistic look I was going for. Therefore, I moved the panel to the top of the screen, and turned it into a top bar. You can do so by right-clicking on the panel, selecting Show Panel Configuration and modifying the settings to:

Position: Top
Visibility: Always Visible
Floating: Disabled

The last two configuration options disable the "hiding" behavior of the panel, making it always visible. The default panel is a bit too thick, so I reduced the height to 25 pixels.

As for widgets, I removed the task manager and displayed the time in the center, using ddd d MMM, to display the date besides the time within the same line. The leftside Toggle Overview button is from the KDE Store with a custom icon.

Addressing the Animation Issue

One issue I encountered is that, after removing all task managers from the screen, the Squash animation for minimizing windows stops working. I have reported this as a bug, and hopefully in a future update this will be fixed.

In the meantime, you can use my fork of Squash Plus which provides a "Minimize To" configuration option. You can set this to any of the fixed positions on the screen, which fixes this issue.

In my case, I set it to the top left corner, which is where the Toggle Overview button is located, and where the magic corner is set to toggle the overview too. This way it seems that windows are minimized to the Overview screen, which makes for consistency in the design.

Hotkeys and Touchpad Gestures

KDE Desktop provides a powerful system for configuring hotkeys under the "Keyboard > Shortcuts" settings. The configuration I am using:

Alt + Space: Open KRunner
Alt + F4: Close Window or Log Out
Meta + E: Open Dolphin
Meta + C: Open Chrome
Meta + K: Open Konsole
Additional KWin Script: Geometry Change

However, the almighty KDE Plasma seems to be in surprising lack of touchpad customization options. To solve this issue I resorted to using Input Actions, a community-developed tool that provides cross-desktop support for input device triggers. Here is the script I am using to configure the touchpad gestures:

touchpad:
  gestures:
    # Three-finger swipe to cycle between tabs
    - type: swipe
      fingers: 3
      direction: left_right
      actions:
        # 1. Start: Hold Alt and tap Tab once to open the menu
        - on: begin
          input:
            - keyboard: [ +leftalt, tab ]

        # 2. Moving Left: Cycle backwards (Shift+Tab)
        - on: update
          interval: -75
          input:
            - keyboard: [ leftshift+tab ]

        # 3. Moving Right: Cycle forwards (Tab)
        - on: update
          interval: 75
          input:
            - keyboard: [ tab ]

        # 4. End: Release Alt to select the window
        - on: end
          input:
            - keyboard: [ -leftalt ]

        # 5. Cancel: Release Alt if gesture is interrupted
        - on: cancel
          input:
            - keyboard: [ -leftalt ]

    # 3 Fingers Up -> Spreadsheet View (Desktop Grid)
    - type: swipe
      fingers: 3
      direction: up
      actions:
        - on: begin
          input:
            - keyboard: [ leftmeta+w ]

    # Wait for 3 finger down to exit spreadsheet view
    - type: swipe
      fingers: 3
      direction: down
      actions:
        - on: begin
          input:
            - keyboard: [ leftmeta+w ]

    # 4 Fingers Up -> Task View (Desktop Grid)
    - type: swipe
      fingers: 4
      direction: up
      actions:
        - on: begin
          input:
            - keyboard: [ leftmeta+g ]

This configuration modifies the three-finger swipe to open the Overview Effect, and the four-finger swipe to switch between workspaces. You can modify the configuration to your liking, and add more gestures if you wish.

Color Theme Support

Light attracts bugs. Dark attracts developers.

I set out by browsing the KDE Store for Nord color schemes. Several options are available, but I ended up choosing Nordic Bluish KDE theme for most setups:

Colors: Nordic Bluish
Application Style: Kvantum (I will cover this later)
Plasma Style: Nordic Bluish
Window Decorations: Nordic
Icons: Breeze Dark (See more in Icons)
Cursors: Nordic-Cursors

Compared with builtin color theme support, I prefer to use Kvantum to provide better support for qt applications, since it comes with enhanced flexibility and capability. Utterly Nord Plasma is a qt theme with great support for acrylic and blur effects, and is the one I am using for Simply Nord. I especially like its dropdown menu design, which is brings out the subtle use of colors in the Nord palette.

Ensure that you have "Blur" enabled in "Desktop Effects" settings. It should be pointed out that that the default Utterly Nord Plasma theme is rather aggressively transparent, which makes some windows such as Kate and Dolphin look weird on light backgrounds. The workaround I found is to use the "Kvantum Solid" variation of the theme and, under Application Themes, apply it to windows that are frequently moved above light backgrounds with the "Application Themes" section in Kvantum.

Another tip: I found that the Nordic Bluish color scheme in Dolphin is a bit unclear. The solution is to "Settings > Configure > Window Color Scheme" and use another. I strongly recommend Nordic Darker, which looks crisp and clear with the default white Breeze Icons.

Wallpaper and Screens

The wallpaper that I am using comes from a Reddit post. It should be noted that for some reason the image you download from the post is of 4717×2984 resolution despite it being said to be 1920×1080. For best quality you can downscale it to 1080p and then upscale it back to 4K using a tool like Upscayl. This will significantly reduce blur. Or, simply click the link below to download the wallpaper that I upscaled:

Upscaled Wallpaper

Remember to set the wallpaper in two places: the "Login Screen (SDDM)" and the "Screen Locking" settings. Set both to "Breeze" and use the configuration button to set the wallpaper to the one you downloaded.

Icons

Icons are arguably the hardest part to configure in a typical KDE Plasma desktop. Many of the icon sets that I found seem to be incomplete, and using them leads to visual inconsistencies. Therefore, I settled on using the default Breeze Dark icons as the base, and building icon overrides across applications.

It turns out that KRunner has a dedicated ~/.config/krunnerrc configuration file, where you can specify icon sets to use for KRunner specifically. For the nord theme, both Zafiro Icons and its fork Zafiro Nord Dark works perfectly. You can use them by cloning them (or cloning and copying the Dark folder) into ~/.local/share/icons/ and setting:

[Icons]
Theme=Zafiro-Nord-Dark

However, I noticed that both icon sets modify the top search bar of KRunner, which I dislike. To resolve this issue, we will build a custom icon set that inherits the zafiro icons but overrides the search bar icons.

To this end, we would first need to figure out the names of these icons used. This is surprisingly difficult, since I have not found any builtin tool in KDE Plasma to inspect icons. After much research, I found Breeze Icons Debug by etherfield, an icon set that replaces all icons with an image consisting of the icon id. This allowed me to easily identify the icons used in the KRunner search bar, and I built this custom icon set:

~/.local/share/icons/KRunner-Icons-Override
├── actions
│   ├── 24
│   │   ├── edit-clear-locationbar-rtl.svg
│   │   └── search.svg
│   └── 48
│       ├── configure.svg
│       ├── expand.svg
│       ├── question.svg
│       └── window-pin.svg
├── append
└── index.theme

The index.theme file is as follows:

[Icon Theme]
Name=Simply Nord: KRunner Icons Override
Comment=KRunner override icons for theme Simply Nord
Inherits=Zafiro-Nord-Dark,breeze-dark

Directories=actions/24,actions/48

[actions/24]
Size=24
Context=Actions
Type=Fixed

[actions/48]
Size=48
Context=Actions
Type=Fixed

In the directories, I copied icons sampled from the Breeze Dark icon set. I will provide the python I used to extract these icons and follow symbolic links:

Python Script for Icon Extraction & Append

As you have seen in Image 3, the search bar icons are now overridden to match the Breeze Dark icons, while the rest of the KRunner icons are inherited from the Zafiro Nord Dark icon set. The result is a vastly more consistent and polished look for KRunner.

Similarly, you can override the folder icons in Dolphin to adjust the colored folders to match the Nord palette.

Final Touch: Fonts

Fonts matter. People often complain about the default fonts in Linux look ... well, a bit outdated, but this problem is absolutely solvable. First, install fonts of your choice. I am using Noto Sans for user interface, and JetBrains Mono for monospace usage like in terminals. When it comes to Asian typography, Source Hans Serif is my primary choice for documents.

Change the font in the digital clock in the top bar to 8pt Noto Sans. See how much that affects the overall feel of the desktop? We consider fonts as the final touch to the desktop configuration, since they make up much of the micro-details that make the desktop brilliant.

Font management in linux can be tricky, since what you ask for is not always what you get. For example, the famous "Arial" font is actually replaced by "Liberation Sans" in most Linux distributions.

For me, I noticed that the default font system used "FreeSans" for symbol glyphs, which led to issues where the arrow symbol is not vertically centered and so on. Whenever you encounter such issues, you can use the fontconfig system to set up font fallbacks and overrides.

fc-match -s "sans-serif:charset=2192" | head

This will show you the font fallback chain for the arrow symbol (modify 2192 to the codepoint of the symbol you are looking up). To resolve such issues, create your own configuration files in ~/.config/fontconfig/conf.d/ and specify font fallback rules. One trick that I found was that in most circusmstances, Noto Sans Symbols seemed to have better glyph design.

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'urn:fontconfig:fonts.dtd'>
<fontconfig>
 <!-- Strip Noto Sans Symbols of Latin characters -->
 <match target="scan">
  <test name="family">
   <string>Noto Sans Symbols</string>
  </test>
  <edit mode="assign" name="charset">
   <minus>
    <name>charset</name>
    <charset>
     <range>
      <int>0x0030</int>
      <int>0x0039</int>
     </range>
     <!-- 0-9 -->
     <range>
      <int>0x0041</int>
      <int>0x005A</int>
     </range>
     <!-- A-Z -->
     <range>
      <int>0x0061</int>
      <int>0x007A</int>
     </range>
     <!-- a-z -->
    </charset>
   </minus>
  </edit>
 </match>
 <!-- When querying sans-serif fonts, resort to Noto Sans Symbols for symbols -->
 <match target="pattern">
  <test name="family" qual="any">
   <string>Arial</string>
  </test>
  <edit binding="strong" mode="prepend" name="family">
   <string>Noto Sans Symbols</string>
  </edit>
 </match>
 <match target="pattern">
  <test name="family" qual="any">
   <string>Roboto</string>
  </test>
  <edit binding="strong" mode="prepend" name="family">
   <string>Noto Sans Symbols</string>
  </edit>
 </match>
 <match target="pattern">
  <test name="family" qual="any">
   <string>sans-serif</string>
  </test>
  <edit binding="strong" mode="prepend" name="family">
   <string>Noto Sans Symbols</string>
  </edit>
 </match>
 <dir>~/.local/share/fonts</dir>
</fontconfig>

This script effectively applys Noto Sans Symbols as the fallback font for all sans-serif symbol fonts. We need to strip Noto Sans Symbols of Latin characters since it contains such a sample sequence, which will otherwise take precedence over fonts the browser queries for letters.

Each time you modify the font configuration, make sure to clear the font cache:

fc-cache -f

Take some time to experiment with fonts in all your applications, and make sure that each modification you make does not introduce new issues in font rendering. This will help you achieve a consistent and polished look across your desktop.

That's all! When you are done, you should have a beautiful, minimalistic KDE Plasma desktop ready to go. Happy theming!

Getting Modular

Thu, 30 Oct 2025 00:00:00 GMT

https://github.com/Mango-CLI/Mango

TL;DR

Mango has got submodule support at last. Update, and enjoy.

What This Blog is About

If you are seeking information about the recent submodule update, or wish to learn how to use it, you can utilize the new builtin mango @help command to look up detailed information about all commands.

If you wish to develop your own templates and submodules, you will find documentation in the README.md file, and a multitude of demo templates in the builtins repo should serve as a great starting point. A detailed online documentation entailing all mango features is planned, as will be released soon.

So why am I writing this blog?

The simple answer is, I wish to document the process I went through designing submodules and templates for Mango. Each step of design, each choice taken or reverted bear careful analysis and reasoning.

So this blog is not going to be a detailed tour on how to use submodules. Instead, it will guide you through a journey behind and beyond the mango submodule system you see now. If you want to dive deeper, and truly understand modularity in mango, you have come to the right place. If it so happens that you want to introduce modularity or reusability to one of your brilliant projects, you may also find some inspiration here.

So sit back, and let's begin.

Craving Modularity

For me, one common use case of Mango is managing my schoolwork. Most of the time we rely on the famous Canvas Infrastructure, and I found myself repeatedly downloading assignments, doing them locally, and uploading them back. Mango helps me automate this process.

The problem is, different courses have different requirements, and I had to write the same canvas-handling code over and over again, which is tedious and annoying. I wished for a method to reuse the code across different mango repos.

Another point that I came across is that, in the old mango system, there is no good way to update the mango builtin commands. Users are free to roam the home repo and modify any file. In fact, they are encouraged to tailor their home mango to fit their own needs. Yet, this freedom comes at a cost: there is no way to systematically update the home repo, as rebooting the home repo will remove all user-defined scripts within.

Mango prides itself on being an extremely lightweight yet flexible script manager, yet the simplicity of the old mango system has placed a limit on its extensibility. A simple, tiled script layout is easy to understand, but hard to extend. There was in truth no good way to manage dependencies between scripts, or to publish reusable code.

A Vague Idea

So I started by asking myself:

What does modularity mean to Mango? What should it look like?

The first question is easy to answer: I want to incorporate a selection of "reusable code" from other repos, or other creators, into my own mango repo. This reusable code is either a dependency for my own code, or a set of commands that I want to use directly in this context. Unlike my own commands, such a segment should instead be externally maintained, and easily updatable.

The second question is trickier. There were lots of possible designs. What should submodules be? Should they be a a script that enacts a side effect on the mango repo? Or a archive that follows some given convention designed to provide functionality to the repo? How can the user access this reusable codebase? How should submodules be managed and updated?

There is no end to the questions to be answered, so I started out by investigating existing modularity systems.

Git Submodules: Git allows users to include other git repos as subdirectories of their own repo. They can "clone" others' repos directly into their own, facilitating code reuse. There is no "central hub" for git submodules, and users manage submodules per project. Git keeps track of submodules and their versions in a special .gitmodules file.
Linux Package Managers: Most linux systems ship with package managers, which provide a unified method to extend the os with third party software. Packages are served from central repositories, and are locally bookmarked strictly by name and version. They are installed in autonomous directories, and exposed to the user via binaries in the system PATH.
Vim Extensions: Vim has a rich ecosystem of extensions, and numerous famous extension managers. Extensions are usually placed in a special directory. Their functionality comes from following directory structures.
Python packages: Python also uses naming conventions and directory structures to define packages. They can be installed from central repositories, or can be user-defined.

So the problem boils down to several key design choices:

Is there a central repository for submodules, or is it decentralized?

What format should a submodule take?

Where should submodules be installed? In a central directory, or scattered project-wise? If the latter is true, how can we keep track of them?

The first question is simple. The topmost merit of having a central repository is security. However, it places a great limit on the freedom of publishers. Mango, as a user-driven script management tool, should make it easy for users to create and share content. Users should decide what they trust and what to use in their own mango repos. Therefore, I decided to go with a decentralized design. (Besides, I do not have the resources to maintain a central repository.)

The second question I found inspiration from git. Any git repo can be a submodule, which creates an isomorphism between git submodules and git repos. This is great design, as it allows for greater flexibility, as well as minimal workload for the developer to translate existing repos into submodules.

The last problem is indeed the trickiest. After much deliberation, I decided to go with a project-wise submodule system, since versioning may vary from project to project. Yet I found it pretty hard to decide on a single design. Here are some ideas put forward during the design process:

Regarding the construct of submodules:

The git repo itself is the .mango folder renamed. It contains .instructions and all other files.
The git repo wraps around the .mango folder, so .git and .mango are parallel directories. This enables users to place other files outside the mango implementation, like a README.md and a license file.

Regarding where to place submodules and how to track them:

Submodules are scattered across the repo like that in git. A special file (e.g. .submodules) that lists the relative directory of each submodule, relative to the .mango folder.
The submodule directories placed at top level, and keep a *.submodule format.
The submodule directories placed inside a special .submodules folder.
Submodules are not statically documented. Users use paths to invoke them, like using mango path/to/submodule:command. There is no way short of using brute force to list them though.

Primarily, I chose option 1 for construct, and option 3 for placement and tracking.

The Price of a Flat Design

A chance of isomorphism should never be missed in architecture design.

I chose these two because they yield a relatively flat file system, without unnecessary time overhead. Thus I reasoned to myself: Mango is designed to be simple, and by far all mango repos adhere to being a flat structure, making it simpler for users to understand, navigate and edit. Unlike git, where outside commands handle the .mango folder, users should be encouraged, if not required, to directly interact with the mango folder. It is for this reason that I placed great emphasis on keeping directory hierarchies flat and understandable.

However, just when I was about to finish implementing the submodule system, I realized some issues with this design.

First and foremost, this design makes it hard to build submodules. When working inside a directory that would be cloned into as a submodule, the original mango method of searching up the directory tree for .mango folders would fail to capture the repo, thus disabling users from utilizing mango to test their work. This can be mitigated by checking not only .mango directories but also .instructions files in the mango cli tool, but it seems rather unintuitive and dirty.

Worse still, there is no reliable and programmatic way to call submodules from submodules, due to the unavailability of the mango command inside submodule directories. This is a serious limitation, as it prevents users from building more complex submodule systems.

The problems, in essence, arises from an asymmetry between .mango folders and submodule ones. The former is recognized by the name, the latter by a position. The lack of isomorphism here created unintended complexities when it comes to development and deployment.

When designing systems, one should seek consistency and isomorphism wherever possible. This is a lesson learned the hard way. A chance of isomorphism should never be missed in architecture design.

A Better Design

After much deliberation, I chose to adopt a better, more consistent design, at the price of more deeply nested directories. We will come to this design choice later.

~/.mango
├── .instructions
├── .submodules
│   └── builtins
|       ├── .mango
|       |   ├── .templates.registry
|       |   |   └── (template folders)
│       |   ├── .instructions
│       |   ├── .on-add
│       |   ├── .on-add.literal
|       |   ├── .on-install
│       |   └── (builtin mango commands)
|       └── (license and readme files)
├── .templates.registry
|   └── (user defined template folders)
├── .submodules.registry
|   └── (user defined submodules)
└── (user defined mango scripts)

In this design, each submodule is a repo, and the .mango directory resides inside the submodule folder, alongside other files like README.md and LICENSE. This generates a powerful isomorphism that any mango repo is a valid submodule, and any submodule is a valid mango repo. This greatly simplifies development and testing for submodules, and developers can now use mango commands directly inside submodule directories to access their submodules.

When submodules are installed, they are git cloned into the special .submodules folder, and a .on-install hook is called to perform any additional setup. This design keeps submodules organized and lightweight. Henceforth, submodules are updated using git pull, and removed by simply deleting their folders, no side effects.

Besides flexibility, another reason I deemed the design a fair tradeoff is that creators should be discouraged from directly editing and referencing submodule files. Come to think of it, submodules are supposed to expose API endpoints for users to call, not files to edit. By nesting them deeper in the directory tree, we can place a deliberate syntax barrier between users and submodule files, encouraging them to use mango commands as an intermediate layer to access submodules' functionality. This effect, while not intended at first, is indeed beneficial to the overall user experience.

What About Templates?

So far we have all been talking about submodules, but what about templates?

The answer is simple: In mango, templates are simply just submodules. They follow the same rule, and the only difference is that, typically, the .on-add hook is defined to replace the host repo's .mango directory with the one inside the template. That's it!

In order for developers to build submodules and templates more easily, I included two builtin templates: the submodule template and the template template. Users can use them with mango @init to quickly scaffold their own submodule or template repos.

After they have finished developing their submodules or templates, they can either choose to publish them on git hosting services like github, or store them locally. Two registries are maintained in the host mango repo: .submodules.registry and .templates.registry. They act as local git remotes for users, including bare clones of the submodule/template repos, and will be searched when users invoke submodules and templates.

Conclusion

We're done! After a month of design and development, mango submodules are finally here. We can now use templates and submodules both online and locally, and reuse code across different mango repos. We have setup a consistent and powerful modularity system that adheres to mango's core philosophy of simplicity and flexibility.

Since its first release, mango has come a long way. This submodule system is yet another milestone in mango's journey towards being a creatively-designed script management tool. I hope you would enjoy using it. Best regards, Norb, head of Mango-CLI.

Introducing MkData

Wed, 08 Oct 2025 00:00:00 GMT

A Simple Goal

It all started a year ago, when, as a freshman majoring computer science, I found myself in constant need of generating large sets of structured data to test algorithms implemented in C++. Most contented themselves with writing small scripts in Python or native C++ to generate random data, but I wanted something more efficient and scalable. I talked with RogerFlowey, and after some heated discussions, MkData was born.

The idea is simple enough: Programming languages are powerful, yet this power means that for specialized tasks like data generation, boilerplate code is often needed (for instance, to format output). All we need is a flexible domain-specific language that can express the structure of the data we want to generate, and a command-line tool (an interpreter) that will generate the data for accordingly.

A Journey of Iterations

From GUI to CLI

Previously, I had made some attempts at building batch generation tools. The first generation of MkData looks like this:

I was learning frontend at that time, so I used Vue for the UI. It was a fun project, and (more or less) a good-looking one, but being web app limited its practical functionality. I soon realized that a GUI is not ideal for a generator. It makes much more sense to focus on core language features, and expose a command-line interface for users to interact with.

I decided to rewrite MkData from scratch, this time as a Python package. After installation, it functions as a command-line tool.

pip install mkdata

Or, with other package managers:

pipx install mkdata
uv tool add mkdata

Nailing the Syntax

Deciding on the syntax of MkData took time. I wanted it to be as concise as possible, without sacrificing extensibility. After several iterations (as a ton of discussions with RogerFlowey), I settled with a half-Pythonic, half-Cpp-ish syntax.

It might not be perfect, but is as close as we could get to our goal. The beautiful thing is that, since MkData is based on Python, it evaluates all expressions and blocks using Python's own interpreter. This means that all Python expressions are valid in MkData, making it extremely powerful and extensible. There is even a @python directive that allows you to write arbitrary Python code blocks in MkData files.

In accordance to C++ redirection, MkData provides a @redirect directive to redirect output to files, stdout or stderr. In combination with loops, it can be used to generate multiple files in one go.

One of the most annoying things about writing data generation scripts is formatting output. The formatting syntax in MkData is done solely through appending format specifiers to the end of each enactive statement, like \n for newline. This makes it easy to read and write.

The builtins of MkData (like rint for random int, rstr for random string), are, in fact. defined in a python script, which is run at launch-time to capture its environment. If future versions, MkData will support user-defined starting scripts, allowing users to define their own builtins. A reform of the standard library is currently underway at the time of writing, which aims to provide extensive utility as well as a uniform interface for builtins.

Speeding Up

MkData is implemented in Python, which is not the fastest language out there, but we have done our best to optimize it. Before execution, the script is stepped through and blocks are compiled into Python Code Objects, and after the tree is fully constructed, it is executed in a single pass. This makes MkData fast enough for most use cases.

What's Next?

MkData is still a young project, and there are many features requested so far. Some ideas we have in mind include:

Full support for user-defined startup scripts;
Support for global seeding (implemented in this branch);
Extend the builtin library (see this branch).

We have also created a VSCode extension for MkData, providing syntax highlighting and snippets. Feel free to check it out on the VSCode Marketplace.

Here is the source code for all projects mentioned in this post:

If you have any questions or suggestions, feel free to open an issue on the MkData repository, or reach out to me via email. Thank you for reading!

Attribution: Thumbnail image by Eren Namlı on Unsplash

Introducing Mango

Sat, 30 Aug 2025 00:00:00 GMT

https://github.com/Mango-CLI/Mango

Script management has always been vital to productivity in software development. Almost every aspiring developer has in his or her toolkit an arsenal of scripts to automate repetitive tasks, streamline workflows, and boost their everyday work efficiency.

Yet a global /usr/local/bin directory is not the solution for scope-specific or project-specific scripts. Most builders (pnpm, gradle, uv, etc.) have their own way for allowing users to define and manage scripts within the context of their projects, leading to a kaleidoscope of approaches towards the same problem. Furthermore, global vs. project-specific is about as fine-grained as you can get for customizing user scripts.

What Mango is About

And yes, here is where mango comes in: To fill in the gap of unified script management, and to provide a file-system based approach to organizing and running scripts.

Mango allows you to manage your scripts across projects, using folders as scopes to fine-tune your script organization. This offers flexibility beyond traditional hook-based ways adopted by package managers.

Designing Mango

The core idea of Mango is incredibly simple. Every folder that contains a .mango folder is a mango repo. Whenever the user invokes:

mango command-name args

The mango executable searches up the directory tree for a .mango folder. If such a folder is found, it maps the command name to a script file registered in that mango repo registry. Appending an @ symbol to the command name enables recursive search (mango will search up dir if no match is found in the first mango repo).

When the user installs mango, a .mango folder is created in the user's home directory, making that directory the user's home mango. Common utilities will be installed in the home mango, making them globally available via mango @command-name. So yes: Mango is managed by mango!

mango @init --template bash

This will make the current repo a mango repo because init is a command registered in the home mango, linking to a python script that sets up the folder and initializes the mango environment.

The same is true for all mango commands. They are nothing magic, just files in the home mango that you can play around or modify. This makes mango extremely extensible and customizable.

Why Mango Matters

Mango is yet another script management system. It is nothing fancy, but it does address the need for a unified and extensible scripting solution, in a simple yet elegant way. It is designed to be easy to use, easy to extend, and easy to integrate into existing workflows. This is why personally, I deem Mango a welcoming addition to my workflow, and I have been using it ever since I finished the project.

If you are interested in the Mango project, feel free to check out the GitHub repository. We welcome contributions, suggestions, and feedback from the community!

Happy scripting!