This module provides core's most fundamental types along with the
configuration machinery that lets us offer the best user experience on
any device. The hardcore module more or less defines what
the current core version is.
This documentation is incomplete. Some parts have
big chunks completely missing and some parts are not documented at
all. If you find anything missing in the parts which are documented,
please inform the module owner.
The Opera class, used through the global
variable g_opera, contains some functions for controlling
Opera. This object is used to initialize, run and destroy Opera. It
also carries all global data used by core modules, eliminating the
need for such data to be held in global variables (which some
platforms lack), including staticlocal variables.
The operasetup.py a script is the driver for all of
hardcore's systems, including features,
system, keys,
API, actions
and messages.
It also drives the scripts in other modules that generate locale files
and convert selftest files into source code. This script must be run
before compilation.
The core code supports different configuration profiles which are
supposed to match different target products. The
feature and the tweaks
system provide default configurations for the available profiles. The
following profiles are defined:
Lets the product decide about each supported feature (listed in
modules/hardcore/features/features.version.txt),
whether the product shall include support for that feature.
Obliges each product to actively specify, for each supported third
party feature (listed in
modules/hardcore/features/features-thirdparty.version.txt),
whether the product shall include support for that feature.
Features may depend one one another: we detect at compile time if a
product has chosen an invalid feature set. Every feature turns on one
or more defines which can be used throughout the core code to enable
and disable funcionality.
Specifies (in modules/hardcore/base/system.txt) basic types
(e.g. BOOL, INT32, …), defines what
functions like op_strlen and op_memset do.
Also sets some important system specific properties like big or little
endian and floating-point layout. Obliges each product to actively
make necessary decisions.
Allows products to tweak each module's implementation details. Each
module specifies what can be tweaked (in a file called
module.tweaks) and products must, for each tweak, either
use the module's default setting or tweak it.
The API system allows modules to import and export APIs (in files
called module.import and module.export,
respectively). When an API is not needed, we avoid compiling the code
to implement it.
Lets each module declare (in a file called module.keys)
which user input actions – keys – it understands.
Each product must answer, for each defined key, whether it supports
(and needs) that key.
A system where each module can define (in a file
called module.actions) any actions it implements; and each
product must decide which of them it wants to support.
(Actually implemented by the
data/strings/
module, but driven by hardcore's scripts.) Any text that a
module may cause to be generated, for the user to read, must be
presented in the user's chosen language; this is mediated via
the locale
module's Str::LocaleString type – essentially
a giant enum, each member of which is associated with a
localized string (provided by the
data/translations/
module). Each module indicates which members of this enum
it needs by mentioning it in its module.strings file,
within #if-ery matching that of the code which actually
uses it. This enables the STRING system to collect together exactly
all the localized strings needed by each product, avoiding clutter
from strings the product does not need.
A system which allows modules to define message identifiers. All
module.messages files are read at compile time and used to
define the enum OpMessage. A message dispatcher is
provided, which mediates passing messages via MessageHandler
objects (principally one global message handler) to instances of
classes based on MessageObject.
This class provides a standard mechanism for ensuring that an action
happens after a definite time has elapsed. It is implemented via the
message system.