AbstractSince 2.42Gets the category of the feature.
Applications which include user interface to toggle features may want to use the category to group related features together.
Feature category.
Gets whether the feature is enabled by default.
The default value may be used by applications which include user interface to toggle features to restore its settings to their defaults. Note that whether a feature is actually enabled must be checked with Settings.get_feature_enabled.
Whether the feature is enabled by default.
Gets a description for the feature.
The detailed description should be considered an additional clarification on the purpose of the feature, to be used as complementary aid to be displayed along the feature name returned by Feature.get_name. The returned string is suitable to be displayed to end users, but it should not be relied upon being localized.
Note that some features may not have a detailed description, and NULL
is returned in this case.
Feature description.
Gets a string that uniquely identifies the feature.
The identifier string for the feature.
Gets a short name for the feature.
The returned string is suitable to be displayed to end users, but it should not be relied upon being localized.
Note that some features may not have a short name, and NULL
is returned in this case.
Short feature name.
Atomically acquires a reference on the given feature.
This function is MT-safe and may be called from any thread.
The same feature with an additional reference.
Atomically releases a reference on the given feature.
If the reference was the last, the resources associated to the
feature are freed. This function is MT-safe and may be called from
any thread.
Describes a web engine feature that may be toggled at runtime.
The WebKit web engine includes a set of features which may be toggled programmatically, each one represented by a WebKit.Feature that provides information about it:
The lists of available features can be obtained with Settings.get_all_features, Settings.get_experimental_features, and Settings.get_development_features). As a rule of thumb, applications which may want to allow users (i.e. web developers) to test WebKit features should use the list of experimental features. Additionally, applications might want to expose development features when targeting technically inclined users for early testing of in-development features (i.e. in “technology preview” or “canary” builds).
Applications must not expose the list of all features to end users because they often lack descriptions and control parts of the web engine which are either intended to be used during development of WebKit itself, or in specific scenarios to tweak how WebKit integrates with the application.
Since
2.42