diff --git a/about.xhtml b/about.xhtml
index 086641a..068c513 100644
--- a/about.xhtml
+++ b/about.xhtml
@@ -1,7 +1,7 @@
-
+
@@ -350,54 +350,46 @@
There are 4 phases of development. Each phase typically has
its own branch in each source code repository. The phases are as
- follows:
-
- - Alpha: Pre-alpha development and alpha
- testing occurs in this phase. Features are
- added, modified, and/or removed. Fixes and
- optimisations may also occur if they are caught
- during this phase. This is where the majority of
- changes occur and where the fine-grained commits
- can be found. Breakage is highly likely within
- this phase as it makes no attempt to be stable
- or usable due to being where the most rapid
- development occurs. Code is tested internally in
- a fine-grained manner and is moved to the next
- phase only when it is deemed feature-complete
- and reasonably stable for broader public
- testing. If you would like to assist in testing
- code in this phase, you must use the code and/or
- tags from the source code repositories due to it
- not being available publicly outside of
- them.
- - Beta: Feature-complete testing occurs in
- this phase. Only bug fixes and optimisations
- occur in this phase, such as stability and
- security fixes. This phase is classified as
- stable enough for broad public testing and is
- made available publicly in many cases without
- having to use the source code repositories.
- Since this phase contains only feature-complete
- code, no features will be added, modified, or
- removed in this phase.
- - Release candidate (RC): Feature-complete
- testing occurs in this phase. Code in the RC
- phase is often stable enough for production
- usage, but is not yet completely acceptable to
- be classified as stable by my standards. This
- phase is often skipped due to most bugs being
- caught in the beta phase, but will be used
- should the need arise for finer-grained testing
- beyond what the beta phase can provide. Like the
- beta phase, code in this phase is available
- publicly without requiring usage of the source
- code repositories.
- - Stable: Feature-complete and well-tested
- code is moved to this phase. Code in this phase
- is deemed to be stable enough for production
- usage and full support is provided.
-
-
+ follows:
+
+ - Alpha: Pre-alpha development and alpha testing
+ occurs in this phase. Features are added, modified,
+ and/or removed. Fixes and optimisations may also occur
+ if they are caught during this phase. This is where the
+ majority of changes occur and where the fine-grained
+ commits can be found. Breakage is highly likely within
+ this phase as it makes no attempt to be stable or usable
+ due to being where the most rapid development occurs.
+ Code is tested internally in a fine-grained manner and
+ is moved to the next phase only when it is deemed
+ feature-complete and reasonably stable for broader
+ public testing. If you would like to assist in testing
+ code in this phase, you must use the code and/or tags
+ from the source code repositories due to it not being
+ available publicly outside of them.
+ - Beta: Feature-complete testing occurs in this phase.
+ Only bug fixes and optimisations occur in this phase,
+ such as stability and security fixes. This phase is
+ classified as stable enough for broad public testing and
+ is made available publicly in many cases without having
+ to use the source code repositories. Since this phase
+ contains only feature-complete code, no features will be
+ added, modified, or removed in this phase.
+ - Release candidate (RC): Feature-complete testing
+ occurs in this phase. Code in the RC phase is often
+ stable enough for production usage, but is not yet
+ completely acceptable to be classified as stable by my
+ standards. This phase is often skipped due to most bugs
+ being caught in the beta phase, but will be used should
+ the need arise for finer-grained testing beyond what the
+ beta phase can provide. Like the beta phase, code in
+ this phase is available publicly without requiring usage
+ of the source code repositories.
+ - Stable: Feature-complete and well-tested code is
+ moved to this phase. Code in this phase is deemed to be
+ stable enough for production usage and full support is
+ provided.
+
When development of a new version has begun, the code within
the alpha phase is rebased onto the most recent code from the
stable phase before work commences. This cycle continues for the
@@ -687,9 +679,10 @@
secure-by-default, Android-based operating
system which implements extensive, systemic
security and privacy hardening to the Android
- Open Source Project used as its base codebase.
- Its hardening includes closing gaps for apps to
- access sensitive system information, a secure
+ Open Source Project used as its base
+ codebase.
+ Its hardening includes closing gaps for apps
+ to access sensitive system information, a secure
app spawning feature which avoids sharing
address space layout and other secrets AOSP's
default Zygote app spawning model would share,
@@ -705,11 +698,11 @@
to ensure the OS has not been corrupted or
tampered with.
GrapheneOS only supports
- high security and well-supported devices
+ high-security and well-supported devices
which receive full support from their
manufacturers, including firmware updates, long
support lifecycles, secure hardware, and overall
- high security practices.
+ high-security practices.
For an extensive list of features GrapheneOS
provides, visit its
official features list
@@ -728,12 +721,12 @@
Vanadium is a security-hardened,
- privacy-hardened Chromium-based web browser
+ privacy-hardened, Chromium-based web browser
which utilises GrapheneOS' operating system
hardening to implement stronger defenses to the
- already very secure Chromium web browser. Its
- hardening alongside Chromium's base security
- features includes
+ already very secure Chromium web browser.
+ Its hardening alongside Chromium's base
+ security features includes
disabling JavaScript just-in-time (JIT) compilation by default,
stubbing out the battery status API to prevent abuse of it,
and
@@ -767,18 +760,15 @@
to protect user keys using the device's hardware
security module.
Molly is available in
- 2 flavours:
-
- - Molly, which includes the
- same proprietary Google code as
- Signal to support more
- features.
- - Molly-FOSS, which removes
- the proprietary Google code to
- provide an entirely open-source
- client.
-
-
+ 2 flavours:
+
+ - Molly, which includes the same
+ proprietary Google code as Signal to
+ support more features
+ - Molly-FOSS, which removes the
+ proprietary Google code to provide an
+ entirely open-source client
+
|
Open-source
@@ -802,6 +792,26 @@
(GPL-3.0-only)
|
+
+ | Viewer |
+
+ 
+ Gallery
+ |
+
+ Gallery
+ is a lightweight image and video viewer with
+ image editing capabilities.
+ It has a clean and modern design without
+ including unnecessary features, and runs
+ smoothly. It provides both individual image and
+ video file view, and folder view.
+ |
+
+ Open-source
+ (Apache-2.0)
+ |
+
diff --git a/asset/img/logo-gallery.png b/asset/img/logo-gallery.png
new file mode 100644
index 0000000..c804b96
Binary files /dev/null and b/asset/img/logo-gallery.png differ