WIP: Canary example network application
This commit is contained in:
parent
b1a52999e5
commit
d815cd1fc9
|
|
@ -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
|
||||
Loading…
Reference in New Issue