network/sample-applications/canary.txt

@@ -0,0 +1,135 @@
+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>, <mars@tebibyte.media>, GitHub:
+@marceline-cramer, Discord: @CrazyWazy#5915).
+
+Modern GUI frameworks (such as Qt) typically work with the backend application
+working on top of the GUI code. 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, and as more applications become reliant on these
+frameworks, 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 of messages, and the scripts provide the
+layout and rendering. Custom scripts implementing the same protocols can then be
+provided by the user, which style, personalize, and enhance Canary GUIs without
+the need to recompile the target application or integrate with an upstream
+framework.
+
+To see why this model of GUI design is so innovative, imagine a stereotypical
+video game. 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 increase 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 and 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
+provide their own script implementing the "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 the new script for their health meter too.
+
+Canary makes no assumptions about what the contents of your user interface may
+be. 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, would have a lot of appeal
+to these kinds of people. A big advantage that hackable GUI has to other kinds
+of hackable software is that changes to it are immediately apparent to anyone
+looking at it. Canary's plan for adoption is to post some initial demonstrations
+and functional Canary programs on image-oriented social media like 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 would make a good project to be accepted to Tebibyte Media 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: to
+network users together towards similar ends. Other Network members could use
+Canary for their GUI 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 replace customizable desktop
+widget apps with Canary-enabled 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 primary target 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 useable with their applications. For more info, see Microsoft's
+strategy to "Embrace, Extend, and Extinguish" other companies' software
+projects [3].
+
+The selection of a copyleft license allows for 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 Canary offers. The LGPL's slightly more liberal requirements will be
+essential to Canary's 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