network/sample-applications/canary.txt

@@ -0,0 +1,134 @@
+Canary is a post-structuralist graphical user interface (GUI) framework using
+WebAssembly [1] (aka Wasm) scripting for its runtime logic.
+
+Canary's current maintainer and benevolent dictator for life [2] is Marceline
+Cramer (<cramermarceline@gmail.com>).
+
+Modern GUI frameworks, such as Qt, are typically included by applications as
+a lower layer of operation. The GUI framework provides the event loop, widgets,
+styling, rendering, and window system integration, while the application uses
+that GUI functionality like a traditional library. This frame of design
+philosophy creates large, heavily centralized GUI systems. Complex application
+interfaces are now only available through a limited number of existing GUI
+frameworks. As more applications become reliant on them, the frameworks are
+forced to accumulate even more features and complexity. This hurts competition,
+increases the resource usage of applications, creates a walled garden for GUI
+programming, and neuters variety and creativity.
+
+Canary inverts this hierarchy by cutting the GUI Gordian knot between
+application logic and frontend logic and relocating complex GUI code from a
+static native library to a modular scriptable runtime that can be customized
+by the user. Applications communicate with Canary scripts through
+informally-standardized protocols, and the scripts provide the layout, input
+handling, and rendering. Custom scripts implementing these protocols can then
+be provided by the user, which style, personalize, and enhance Canary GUIs.
+This lifts the burden for the user of recompiling the target application or
+integrating their changes into a larger upstream framework.
+
+To understand the innovation of this design, imagine a stereotypical video game.
+Let's say that this game has a health meter for the player that has a certain
+capacity and value. During the course of the game, that meter may be depleted
+when the player takes damage, filled when the player uses a healing item, or
+have its capacity increased when the player levels up. With Canary, the game
+would group these events and give them a name, like "simplehealthmeter". Then,
+the game would ship with a Canary script that implements the
+"simplehealthmeter" protocol; it renders a basic red bar on the screen for the
+player's health while updating the position of the bar based on those events.
+The player can then replace the provided script with their own
+"simplehealthmeter" that renders a red dial instead, or a Zelda-style hearts
+meter, or anything they want. Then, when they show off their new customization
+and upload their script online, other players can use it for their health meter,
+too.
+
+Canary makes no assumptions about the contents of your user interface. It
+doesn't come with preset structures like "views," "containers," or even
+"widgets." Canary operates on the principle that you, the user, are the only
+person capable of structuring your computer's GUI to your arbitrary,
+personalized whims. Canary's design model is a bazaar, not a cathedral;
+improving and refining its content through anarchic word-of-mouth development
+between communities of users rather than through a centralized library of preset
+widgets, objects, and styling.
+
+There is a very large pool of developers available who would be interested in a
+system like Canary. Online communities such as Reddit's r/unixporn are filled
+with thousands of users who stylize and personalize their software's GUIs for
+fun. Canary, as a maximally-hackable GUI framework, could have a lot of appeal
+to these kinds of people. Changes to hackable GUIs are immediately apparent to
+uninitiated observers, which gives them a huge advantage on social media when
+compared to other kinds of hackable software. To gain adoption during early
+development, demonstrations of functional Canary programs will be posted on
+image-oriented social media such as r/unixporn. Once attention has been
+garnered from these GUI-customizing users, Canary's developers will use the
+customizations and the scripts they write and share with others to establish a
+functioning ecosystem of Canary scripts and regular contributors.
+
+Canary is a promising candidate for Tebibyte Media Network membership because
+its post-structuralist nature of making no assumptions about the user's needs
+and its reliance on communal content creation matches Tebibyte Media's goals to
+network users together towards similar ends. Other free software projects on
+Tebibyte Media can use Canary for their GUI and convene with other network
+members to share Canary scripts.
+
+Canary would make a valuable member of the Tebibyte Media Network because its
+post-structuralist nature (making no assumptions about the user's needs) and its
+reliance on communal content creation match the goals of the Network. Other
+Network members could use Canary for their GUIs and have an active community of
+Canary developers with whom projects can share scripts with.
+
+Canary is designed to be easy to develop alternative runtimes for, because its
+core featureset is restricted to what can be provided by common system libraries
+such as fontconfig and Harfbuzz. WebAssembly runtimes are in abundance for many
+languages, including C and C++; however, the current implementation, canary-rs,
+is written in Rust.
+
+The platform that Canary is initially intended to operate on is the native
+desktop computer running any typical desktop operating system. Windows,
+Linux-based OSes, the MacOS, and the BSDs will be supported. Although the option
+shall be left open to develop a Canary runtime for web browsers, the web runtime
+must require a different design architecture from its native counterpart and is
+low priority.
+
+Canary's first target use case is to create alternatives to common desktop
+widget apps. These may be wallpapers apps like Wallpaper Engine or status bars
+such as Polybar or Waybar. Canary may even be used to implement mundane but
+near-universal GUIs like system clocks, calendars, music player controllers, or
+notification daemons.
+
+Virtual reality is also a high priority for Canary; the current VR ecosystem
+is in desperate need of better GUIs and more free software alternatives. Canary
+was originally conceived to fill both of these needs; thus, VR-capable 3D game
+engines such as Unity, StereoKit, and Bevy are considered first-class priority
+for Canary support.
+
+Canary-rs is licensed under the terms of the GNU Lesser General Public License
+version 3 (LGPLv3). The LGPLv3 is a copyleft license and is not permissive like
+MIT (aka Expat) or Apache-2.0. Both the LGPLv3 and permissive licenses allow
+works to be linked to proprietary software, such as Unreal Engine and the Unity
+game engine. The LGPLv3, however, requires that the work be linked to
+proprietary software as a shared library. This shared library must provide to
+the user both a method to access its source code and a method to swap in a
+custom library.
+
+If a third party distributes a shared library compiled from a modified copy of
+an LGPLv3-licensed work, they must supply the modified source code to their
+users. This prevents malicious parties from creating a custom canary-rs runtime
+that is only usable with their applications. For more information, see
+Microsoft's strategy to "Embrace, Extend, and Extinguish" software projects [3].
+
+The selection of a copyleft license allows canary-rs to be used alongside
+proprietary applications while guaranteeing that the core Canary implementation
+remains free and open. Although this does not prevent alternative proprietary
+runtimes from being written from scratch, it makes the creation of nonfree
+runtimes much more difficult.
+
+A stronger copyleft license such as the GPL or the AGPL is not used because it
+is important to Canary's adoption that it is used in as many applications as
+possible. Few game developers who are unfamiliar with free software will choose
+to take on the responsibilities that a non-Lesser GPL requires, no matter what
+features are offered. The LGPL's slightly more liberal requirements will be
+essential to adoption outside of the free software evangelist space.
+
+References:
+1. https://webassembly.org
+2. https://wikiless.org/wiki/Benevolent_dictator_for_life
+3. https://wikiless.org/wiki/Embrace,_extend,_and_extinguish