Commit 70d24733 authored by Emanuele Aina's avatar Emanuele Aina

applications: Misc minor improvements to the text

Fixes, small formatting changes and minor rewording to make the text
sligthly easier to read.
Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>

Differential Revision: https://phabricator.apertis.org/D4019
parent 651c81dd
......@@ -338,7 +338,7 @@ We propose to align all of these, as follows:
`apertis.org`, `freedesktop.org`, `gnome.org`, `gtk.org`) should be
restricted to app bundles associated with the relevant projects.
Example projects provided in SDK documentation should use the names
that are reserved for examples (<http://www.rfc-editor.org/info/rfc2606>),
that are reserved for examples (see [RFC2606](<http://www.rfc-editor.org/info/rfc2606>)),
such as example.com, but app-store curators should not publish bundles that use such names.
- Programs in a bundle may use the D-Bus well-known name corresponding
......@@ -412,7 +412,7 @@ application has really been installed or subsequently uninstalled. The
store also can't reliably track what version of an application is
installed.
if an application is downloaded on a computer with a web browser
If an application is downloaded on a computer with a web browser
(presumably for installation via external media), the store shouldn't
assume it was actually installed anywhere. Only applications installed
directly to the device should be logged as installed. When the user logs
......@@ -952,14 +952,14 @@ could notify a user by e-mail when updates are available, or show a list
of updated application when the user logs in to the store.
Sometimes a system upgrade will break applications by changing API/ABI -
A problem that is the subject of the Supported API design. Using
A problem that is the subject of the *Supported API* design. Using
information from the manifest, the application manager can verify
whether an upgrade will render an installed application unusable before
the upgrade is carried out, and allow the user to decide to wait for
updated versions of the applications they care about.
Collabora envisions the update manager will provide a UI showing which
applications would stop working, which already have updated versions and
Collabora envisions that the update manager will provide a UI showing which
applications would stop working, which ones already have updated versions and
so on, similar to how Firefox handles its add-ons during upgrades, with
the important distinction that the information would be provided before
the upgrade is performed.
......@@ -1254,7 +1254,7 @@ automatically with a system rollback.
#### Installation
There will be no difference between an application bundle or a “system
extension bundle” - and it my even be desirable to deploy an application
extension bundle” - and it may even be desirable to deploy an application
with supporting system extensions from the same bundle.
Most of the process for installing a bundle with system extensions will
......@@ -1651,7 +1651,7 @@ collect these stale symbolic links.
Deploying non-Apertis applications from the app-store will be possible
if the applications bundle their own versions of libraries not in the
Supported API document. It may, however, be mandatory to recompile these
*Supported API* document. It may, however, be mandatory to recompile these
applications for Apertis in order for the run time linking to work
properly.
......@@ -1771,7 +1771,7 @@ version the user does not want.
As shown in the following snippet, the general storage subvolume will contain subvolumes
for all applications currently installed on the system – whether they're
store or built-in.
from the store or built-in.
The subvolumes for built-in applications will only contain user storage,
as the application itself is already stored in the read-only system
......@@ -1896,11 +1896,11 @@ varying levels of backwards-compatibility guarantees. In case the
application also needs to use any *External APIs* it needs to
bundle the libraries which provide them.
> See discussion on External APIs in the Supported APIs design
> See discussion on External APIs in the *Supported API* design
Since Apertis will ship in different market regions, applications must
be capable of supporting multiple languages. The internationalization
(i18n) process is more clearly explained in the Internationalization
(i18n) process is more clearly explained in the *Internationalization*
design. A simplistic explanation for the purposes of this design is that
all human-readable text in an application is provided in multiple
languages – each language in a separate `.mo` file. Application bundles
......@@ -2247,7 +2247,7 @@ developers. It may be worth considering allowing applications to use the
reliable download service.
If the download completion callback is handled by the application
manager, then an application need not be running while using the
manager, then an application doesn't need to be running while using the
service, and can be automatically started and brought to the foreground
to handle the completion event.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment