These projects are for Linux unless otherwise stated, although they may or may not work on other platforms.
Shule (version 0.11.1, released on 6 November 2026)—sha256sum on it should yield 4a0687063193e6ad7687c0a4bd43e5a8c467637daedc3123c5ef06f2e65de994: Shule is a Linux text editor, authoring station, IDE, and plain text e-book reader. It can also be used to make and navigate (including with the mouse) indexes, which is to say, plaintext corpora (kind of like a dictionary where every entry is a txt file within a directory structure). I personally find Shule very useful. It's written entirely in Python 3.x (although I believe it was originally in Python 2.x), using Tkinter (most of Shule's code was written in itself; I'm using Shule to write this explanation of it, for that matter). Some remarkable features include the ability to save and load favorites (by typing in a favorite name, but not by selecting it in a menu; a favorite is a named set of one or more filepaths on your computer, and your location [line/character] in each file; one file may be in any number of favorites, even with different locations than it has in the other favorites); the ability to password-protect documents; sort ascending/descending, shuffle, reverse; change casing (uppercase, lowercase, title case); indent/unindent selection; ability to type special characters; open a terminal at the current file location; open a file manager at the current file location; customize fonts and colors; countdown timers and stopwatches; document statistics; fullscreen mode; bullet/number and unbullet/unnumber selection; timestamp; auto-indent; increase/decrease margins, Python-style regular expressions (including regular expression groups and functions), and so on. Shule works best when you're using a keyboard with a menu key, two windows keys, and insert key (used for compose keys), such as this one; however, you can reconfigure the compose keys if your keyboard isn't like that. Also, you'll probably have to unconfigure some of those keys (most commonly the Windows keys) on your operating system if you want them to work as compose keys (but menu and insert also work as compose keys). While I said that Shule is an IDE, and it is, it doesn't give priority to programming (but it's still useful for programming). It gives priority to reading, writing, and creating generally. See the changelog.
Ki (version 0.13.2): Ki is a command-line app that allows you to access and create organized index-like content conveniently without painfully navigating through directory structures. It allows for symmetric encryption, choosing what app to open files with, and so forth. You can also name paths so you can go to them by that name. You may want to use this short bash script to make that even easier. To name a directory, enter it on the command-line and then type `ki -B`; select `a` and choose a name. I would have made Ki's source code more organized, but it was an experiment in imperative programming (I'm more used to organizing things with classes)(I have begun anew the process of re-writing it, though, as of 21 August 2026 or so). I originally made Ki when I had to use an Android tablet for my creative projects; so, I learned how to use Termux, and I made Ki (for productivity), however, it works well on Linux, too (but you may prefer using Ki indexes in Shule on a Linux desktop computer, using Ctrl+k to create/open keys, after you set up a base directory; Ki has some features that Shule lacks, but Shule has a lot of features Ki lacks). See this page about Ki for more information on how to use it.
Wikiweb: Wikiweb is an object-based persistent-data management system (a library; not an implementation) that provides a certain kind of complex object graph per project by which the nodes in the project are connected. The project has most of the methods for managing the data, but some are in the nodes, too. Wikiweb is a misnomer; it's not wiki software (the reason for the name is that it provides a data structure the likes of which would be nice if used in a wiki context (but this is currently not ever used in a wiki context, as far as I'm aware), since it's a lot more flexible than a wiki-style category; but it's not for wikis particularly).
Wikiweb is not currently programmed to be efficient for large-scale purposes. Also, it's not super secure in it's current manifestation: It just uses Pickle currently. I did plan to add users, groups, and security features, however. Wikiweb is not currently in active development (but I'm definitely not finished with it).
The basic idea is a single person could make some such as a huge website with very complicated linking structure and lots of information in very little time with Wikiweb, with very little effort; it doesn't have to be a website, though. Changes on one node are automatically updated on potentially zillions of others and zillions of other relations (all sides). Wikiweb has nodes, two-way contexts, and two-way one-to-many relations.
Wikiweb can be compared to English grammar. Nodes are like the things that nouns represent. Nouns can be the subject of a sentence, the direct object, or whatever (I still need to program indirect objects, but I do hope to do it), while each side of a context is like a different verb. Relations are like the whole sentence with both perspectives of two nodes. So, in the sentence, 'Mary loves cabbages, carrots, and lettuces', then 'Mary', 'cabbages', 'carrots', and 'lettuces' would each be a node (with it's own set of unmentioned beings who love it) . `love` would be one side of a context pair (they have two sides, each with a creatively chosen [not programmatic] name, but both names must be instantiated at the same time as a pair). 'Mary loves carrots' would be one side of a relation. The other side of the relation might be 'Carrots are loved by Mary' (not to mention all the other nodes that carrots are loved by; you might see Jack, Elspeth, Edith and so on listed there, too; you might also see things that carrots love, like soil and fertilizer; you might see carrot pests; if you go to a pest, you'd see all the ways pests are related to everything). You can dynamically go to any of those nodes and see its perspective on everything directly from that node. There is no compartmentalization. There are no tables. In Wikiweb, there is only one record per node. You don't need to make a bunch of views to understand relations. You already have all of the views that are possible built-in to every single node. And there are no redundant records needed to simulate multiple perspectives (because every node has all perspectives already). You don't have to do costly reverse traversal methods where you're stuck with the initial perspective name to figure out another perspective. You can do all kinds of cool searches (among other things), including and excluding certain relations while you're at it, using regular expressions, too. Relation inheritance is a thing, too, but it needs work in the code to make it less prone to user-error. To explain inheritance, for instance, if you have 'Sam is boy' and then 'boy is human', you can have it automatically (on a case-by-case basis; not full automation) infer 'Sam is a human'`. Inheritance is not part of the data structure; it's just project methods using the data structures.
There is also a concept called pinning that is key to understand (see the documentation, in the download), and that is involved with inheritance (among other things). A pin is represented in the code as a tuple that contains a node and a context. For instance, `("tomato", "includes")` could be a pin. But, pin isn't primarily a noun. It's a verb. If you pin a node named "Cherokee Purple" with ("tomato", "includes"), this creates the relation "tomato", "includes", "Cherokee Purple". There are functions to search the project (such as with regular expressions) for matches to given criteria and pin every match. You can constrain it to matches that exist within certain pins, and exclude it from other specific pins. The node in the pin is considered the primary node. All the things that it pins/contains are considered secondary nodes.
It's pretty easy to create structures that resemble text adventure maps with Wikiweb (the structure could even include commands and such, too, in theory). For instance, "house" "north" "lawn" could be a relation that indicates that the lawn is north of the house (contexts don't strictly have to be worded as verbs; the other side of that context pair would be "south", with "lawn" "south" "house"). So, if you wanted to create a big text adventure-style map with Wikiweb, it wouldn't be that difficult (although it would be easier to implement it as hypertext fiction that resembles a text adventure than as an actual text adventure). You can create new context pairs on the fly. So, you aren't constrained to any particular directions. So, you get pairs like enter/exit, up/down, east/west, swim / leave the water, and so on. However, in this system, "north" doesn't particularly lead only to one node. It can lead to any number of nodes. Your implementation might programmatically create nodes based on what you do, instead of having them all static and manually created (this could make hypertext fiction much more game-like). For instance, you might automatically generate nodes for what it shows people when you look at something, or do a particular thing.
In a traditional category/tagging/label system, different contexts don't exist as a programmed-in feature. You only get one of what I'm calling a context, and you have to force all contexts into that one context (this is generally managed with conventions to isolate contexts within the context, and sacrifices have to be made to do this, much of the time).
Again, remember that Wikiweb isn't production-grade software. It's mostly out here to show you that this sort of thing is possible (and it can be a lot better than what I've presented). However, I'm not aware of any particular bugs in it (but that doesn't mean there aren't any).
No part of Wikiweb was created with artificial intelligence, nor by its assistance. I wrote it somewhere around the year 2015, probably.
Language Checker (LangCheck) This fairly simple Python script allows you to quickly evaluate the language and content of a text (it checks against things like profanity [including religious profanity], insults, drugs, gambling, violence, and sex) to see how family-friendly it is. It does require some education to use properly. It doesn't do all the work for you; it merely simplifies and considerably shortens the process. You run the text (or link) through the program and it generates a list of words that may or may not be concerning to you. You review the list with your eyes. Then, you can manually look up the words that might be concerning to you in the text to see if they're a problem (the program doesn't do any censoring). While it might seem a bit rough, it's remarkably effective at catching concerning language. It goes by the motto that it's better to catch things that aren't concerning than to miss things that are (that's why you have to evaluate the list yourself instead of letting it do all the work for you; another reason is that you're responsible for your own conscience; so, you decide which words make it). Trigger warning: the source code obviously needs to contain foul language in order to check for it (I don't recommend you peruse the language). I imagine this software would work on other platforms besides Linux, too.
Manual Chess: This is a manual Chess set in Python (using Tkinter for the GUI), made with the assistance of ChatGPT. It's designed to allow you to use the board and pieces however you want, so you can make up your own Chess variants and similar (it also allows you to play many current ones). There's no computer opponent, and it doesn't tell you how to move your pieces. See the source code for instructions on how to use it, including keyboard shortcuts. To load it, copy and paste the source code into a plain-text file and run it with Python 3.x. It's just one file (no images). I imagine this would work on other platforms besides Linux. FYI, I prefer to use the Python version over the JavaScript web edition, even though the web edition has some obvious advantages (I'm not really sure why, other than that it's easier to play my Chess variants when you can rely on casing instead of colors, in addition to how I prefer the way the pieces drag); plus, it's nice that I can make a keyboard shortcut to open it that doesn't have to open a whole web browser.
Manual Chess (web edition): This is version 0.2.3 of a JavaScript version of the above Python program with a few alterations (ChatGPT did the vast majority of the programming, translating from the Python app, with guidance from me). So, now you can play it in your web browser; just click that link. It has actual Chess pieces instead of letters. You can't put non-Chess pieces on the board. The keyboard shortcuts are a little different. You have to control+click to remove a piece instead of a double-click. It has some buttons. Other than that, it's about the same. Use s and w, and i and k to increment and decrement the score. Use h to shuffle and f to flip. You have to press the New Game button to restart the game. Like the Python version, it's just one file, with no images (the Chess pieces are Unicode characters). This app does not work with a touchscreen, yet. You can't change the board size, yet. This should work on other platforms besides Linux, but I haven't tested any. Bug: You can't drag a new piece from the panel to a spot you just vacated (but you can move it somewhere else and then move it there). Note that the Chess pieces aren't represented by images; they're the Unicode Chess pieces (it's all just one HTML file; feel free to redistribute it if you want; it has the MIT license).
Branch Chess: This is a derivative version of Manual Chess designed for a very different game; you can't play regular Chess on it. While I'm not including the very complicated rules on my website here, I can tell you that the game is point-based and involves right-clicking on tiles in some circumstances (each player can change the tiles to a different color; the different colored tiles are kind of like game pieces that you can stand on; they can be moved, but they do not move on their own). The pieces not found in traditional Chess each have unique abilities, but the game doesn't hinge on having those special pieces (they make it interesting, though); they're the reason the board is bigger. While you could play this against other people, I designed it to be fun when playing against yourself (which is a good trait considering it's complicated). Branch Chess is the name of the software (not the name of the game); you could play other games on the software. As with Manual Chess, it is manual (except the board setup). S still shuffles the pieces, but they start out shuffled already. F flips the board. R restarts. U increments the uppercase player's points. L increments the lowercase player's points. Shift+U decrements the uppercase player's points. Shift+L decrements the lowercase player's points.
Mark's E-book Reader (MER): This is an old plain-text e-book reader or (like a GUI-based file pager) that I made in Vala years ago before I started working on Shule (it could be seen as Shule's predecessor). The source code doesn't compile on modern computers due to software updates (this is one reason I stopped using Vala and pretty much focused on Python after that (by the time I was ready to update the code, the new code was beyond recognition and finding out what I actually needed to change was a challenge; AI chatbots weren't there to help, and by the time they were, they didn't know how to fix it, last I checked). Nevertheless, you might be able to get it to run if you install some old dependencies (read the instructions for which ones you might want, if you use such as Ubuntu, Linux). The download does include an .exe binary for Windows, but I don't know if it works. I don't usually use this app anymore, but I do like how it handles margins (that seemed more difficult to replicate in Tkinter last I checked, which was long before ChatGPT existed). I recommend installing Shule instead, but this does have the advantage of not having a tab bar in fullscreen mode, and if you like your bookmarks to be visual and show up in a menu (instead of logical triggered by typing in a name), it has that. It also has an advantage in something to do with margins (over what shule can do on 7 October 2026 and before, anyway).
Count: This is a python script that counts the files and directories in the current directory. I'll probably add a feature like this to Shule, if I haven't already by the time you read this.
Countdown timer: This is a python command-line countdown timer. Shule already has countdown timers, just so you know, but I still use this command-line countdown timer for when I'm listening to stuff on mpv for a period of time.
Linux Python 15-band Parametric Equalizer: This is a fast equalizer with minimal requirements. I have it so you have to edit the values from the source code because in my editing environment it's faster to edit it there and press F5 while editing it than to do it from the command-line over and over again. I was inspired by my purchase of these speakers to seek out a graphics equalizer for Linux, and ended up making this (after talking with ChatGPT for hours about my options), also with ChatGPT's help. Right now, it has an error where it likes to stick to a certain device for routing the virtual sink (so until I fix that, you might have to unplug that device if you want to use it on another one); for instance, on my computer, it keeps trying to use my headphones even when I specify something else—unless I unplug the USB device I plug my headphones in, but if I just use my headphones or unpug them it's fine.
NPK Calculator: This is a JavaScript calculator that shows you the NPK of two fertilizers if you mix them together. ChatGPT wrote most of it, based on the logic I gave it. I don't guarantee it to be error-free, but as far as I know, it works.
This idea began on 19 May 2025 (and was definitely there by 29 May 2025—although I've changed some details since then).
I plan to use RocksDB (which can handle extremely large datasets quickly in an offline context), using a special counting system for the keys (the counting system is designed to produce extreme short ordered keys, although the keys dont correspond to line numbers, and order isn't terribly important), with values that would probably be dictionaries compressed with MessagePack, with one of the values therein being a line of text in the document, another being the line number, others for revision history, others for next and previous lines, and so on. An object graph would connect the lines to each other (the RocksDB keys would not do that). Only a manageable portion of the document would be loaded at a time (unless the document is not so large as to be slow thereby). The structure I have planned also would make the software ideal for a forum (AKA a message board). Anyway, this could mean an end to slow e-books and slow word processor files. It could preserve essentially an author's entire writing process in the finished product, if desired (this is largely on account of a novel line-numering system that it uses). However, it doesn't entirely replace traditional word processors, as it's meant to allow the reader to decide how it renders and how it shows up (the author does not fine-tune the way it looks; the author might choose some basic things, but most of the customization is up to the reader, to allow for a consistent and reliable reading experience between documents). Anyway, line numbering is not standard nor trivial in this system. The idea is to make it open files with millions or even billions of lines just as quickly and easily as files with a hundred lines (sacrificing quick access to line numbers makes it feasible to keep track of edit histories). I first planned to make a text editor instead, but I figured this was even more important in a word processor (since word processors and e-book readers are notoriously slow with large or complex files). Under the hood (at least), line numbers are static in this system: they never change (even if new lines are inserted behind them; this makes data much easier to reference, even when lines are added behind it later). I plan to integrate Wikiweb in with this and add a lot of the features found in Shule (Wikiweb would be for file indexes [each item in the index is equivalent to its own file, bearing the name of its key in the index; it would be useful for a dictionary or encyclopedia meant to accompany a book], but the indexes could be part of the document, rather than separate files in their own directory). Anyway, this is designed primarily for offline use; so, you could in theory store a whole forum on it and just pass it around via emails. It wouldn't really do tables and super fancy formatting like a normal word processor. It would focus mostly on text styles, links, headings, differentiation in fonts and things (although the reader would pick the actual fonts, and so each font would be defined by a purpose), maybe image insertions, and stuff like that. It would just do plaintext bullets for its lists (but it might render them specially)—I've never been a fan of lists you can't copy and paste reliably into a text editor.
EDIT (13 January 2026): I've decided maybe I'll use the equivalent of an non-compressed archive that uses pages (like the kind of pages a pagefile uses) instead of RocksDB.