A feature is functionality implemented in the Opera source code. A feature turns on some code which does something.
This is true for all features:
A platform or product dependant feature may not qualify as a real feature. A feature must be something other products may be interested in. It's not worth polluting the features system with non-portable features.
Functionality not ready for realease is also sometimes not qualified to be a feature. Depending on the phase of the current core code this may be more or less true. For example, if some functionality is developed in the early-phase of core-x, it can be a candidate for a feature, on the other hand if it is developed when some products already have shipped or are in release-phase, that is, when core-x is in late-phase, it may not be a candidate for a feature until the code is of good quality (matching the state of the rest of core-x).
In modules/hardcore/features/features.version.txt.
Where version is the version number if the current mainline
configuration. Each mainline configuration has its own feature
file. The version number is specified
in modules/hardcore/version.ini. E.g. the
feature file for the 2.4 version is
modules/hardcore/features/features.2.4.txt.
The script that processes features.version.txt and generates
the various related header files also generates an XML file containing
the information in features.version.txt. This generated XML
file is named
modules/hardcore/documentation/features.version.xml
and uses an XSLT stylesheet to render in a semi-useful format
(including a colorful feature/profile matrix).
See:
Each product must either define PRODUCT_FEATURE_FILE to the file to be used or change features.version.txt and add a PRODUCT_FEATURE_FILE-row at the top.
Then, the file is simply included like this:
#include PRODUCT_FEATURE_FILE
First, answer these questions:
#ifdef?If the answers are all positive, add your feature to features.version.txt and submit a patch bug.
Also consider if your code should instead go into the TWEAKS system.
FEATURE_NAME feature-owner
Description text.
Defines : preprocessor-defines
Undefines : preprocessor-defines
Group : group
Depends on : feature-list
Required by : feature-list
Conflicts with: feature-list
Enabled for : profile-list
Disabled for : profile-list
#define FEATURE_WHATEVER YES. The value
special value "none" means the feature is not enabled for
any profiles by default.
#define FEATURE_WHATEVER NO. The value
special value "none" means the feature is not disabled for
any profiles by default.
Example:
FEATURE_PREFS_WRITE peter Makes preferences support writing. Enables all APIs to save preferences, and also turns on support for writing generic INI files. Most normal platforms will want to enable this. Defines : PREFS_WRITE, PREFSFILE_WRITE Undefines : PREFS_NO_WRITE Group : prefs Depends on : nothing Required by : FEATURE_OPERACONFIG_URL, FEATURE_PREFS_DOWNLOAD Enabled for : desktop, smartphone, tv Disabled for: minimal, mini
Let's look at the autogenerated code which turns on defines for FEATURE_PREFS_WRITE:
#if FEATURE_PREFS_WRITE == YES # undef PREFSFILE_WRITE # define PREFSFILE_WRITE # undef PREFS_WRITE # define PREFS_WRITE #else # undef PREFS_NO_WRITE # define PREFS_NO_WRITE # endif // FEATURE_PREFS_WRITE
This means the "Defines" defines are turned on if set to YES and the "Undefines" are turned on if set to NO. This feature is required by FEATURE_OPERACONFIG_URL and FEATURE_PREFS_DOWNLOAD which means neither of them can be turned on if FEATURE_PREFS_WRITE is set to NO.
| current | next |
|---|---|