Fix some suggested changes

network/sample-applications/canary.txt

@@ -2,49 +2,48 @@ 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).
+Cramer (<cramermarceline@gmail.com>).
 
-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.
+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 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.
+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 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
+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 increase when the player levels up. With Canary, the game
+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 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.
+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 what the contents of your user interface may
-be. It doesn't come with preset structures like "views," "containers," or even
+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,
+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
@@ -53,29 +52,28 @@ 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.
+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 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
+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: 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.
+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
@@ -88,15 +86,17 @@ 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.
+low priority.
 
-Virtual reality is also a primary target for Canary; the current VR ecosystem
+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
+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.
 
@@ -112,11 +112,10 @@ 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].
+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 for canary-rs to be used alongside
+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
@@ -126,8 +125,8 @@ 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.
+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