hardcore module

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.

Short description of the important parts

Opera core object
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 static local variables.
Opera setup script
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.
Profiles
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:
desktop
tv
smartphone
phone
mini
FEATURE system
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.
SYSTEM system
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.
TWEAK system
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.
API system
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.
KEYS system
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.
ACTION system
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.
STRING system
(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.
MESSAGE system
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.
PREFS system
A system for declaring available preference options, details available in the prefs module.
VIEWERS system
A system for declaring known MIME types, details available in the viewers module.
OpTimer
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.

Module API

See the API documentation.

Search

Search: