github.com/supercom32/dosktop (go): Dosktop is a package which allow users to easily create rich text-based terminal applications and games. Dosktop differs from other terminal packages by providing an extremely simple API that abstracts out all low-level terminal operations, while avoiding complicated event-driven TUI designs.  If your familiar with programming on classical computers and OS environments like the Commodore 64 or MS-DOS, you will find that Dosktop behaves similar to these systems. Dosktop is a procedural package that gives users control over the terminal with simple BASIC-like commands. It maintains this simplicity by managing much of it's functionality and resources internally. While users do not need to keep track of these resources themselves, there are still a few concepts they need to be familiar with.  Aliases are a way for a user to reference a resource in Dosktop without actually needing to manage and store it themselves. Things like creating a text layer, a button, or a timer, all use aliases to identify what the user creates and how they can reference that resource at a later time. For example:  Once created, the user no longer needs to manage the resource. If they wish to manipulate it, they simply need to reference the Alias they want to access. For example:  Furthermore, an alias is always unique and distinct for any given resource. That means, while it is not recommended, it is possible to give two different types of resources the same alias name. For example:  Now we have a layer that has an alias called "Foreground" and a timer that has an alias called "Foreground".  Often when working with software, flexibility comes at the expense of simplicity. Having methods with dozens of options and parameters makes functionality more flexible, but also much more difficult to manage and understand. That's why to keep things simple, Dosktop uses Attribute Entries for configuring most customizable features. Attribute Entries are simply structures that hold all kinds of information about how the user would like for something to operate. By simply generating an entry, configuring it, and passing it in as a parameter, functionality will automatically know how to behave if one should want to do something outside the default. In addition, if you want a feature to behave differently under specific cases, you can configure multiple attribute entries and simply provide which one you need at any given time. For example:  You will note that not all style attributes need to be set. Any attributes which are not modified will be left at their default settings. In addition, if you wish to quickly create multiple attribute entries based off a single one, you can simply do the following:  As you can see, cloning attribute entries is a speedy way to configure multiple items with similar base settings.  Almost all functionality in Dosktop is designed to perform consistently. That is, it will perform most tasks predictably without external runtime conditions changing its behaviour. As a result, when a problem occurs Dosktop will usually prefer to throw a Panic rather than choose an alternative solution or throw an error. This is because any problems encountered will generally be a developer issue and it should be addressed rather than covered up or hidden by default behaviour. For example:  In this case, the user is attempting to create a terminal session with invalid dimensions. Rather than choose a sane default or return a recoverable error, Dosktop will panic since clearly the developer made an error and should correct it. For functionality that could vary depending on runtime conditions, errors will be returned as expected.  When updating the screen with with rapid changes or changes that may take a long time, it is desirable to wait until all drawing is completed before performing a refresh. This allows you to eliminate flickering, screen tearing, or other artifacts that may appear when display data is being updated at the same time as a screen refresh. In Dosktop, all changes to the terminal remain in memory until the user calls 'UpdateDisplay' to refresh the screen. This allows the user to make as many changes as they want before writing their changes to screen in a single pass.
Keywords: ansi|command-line|command-line-interface|hacktoberfest|menus|mouse-support|tui|tui-controls