# 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: