Home · All Classes · Main Classes · Deprecated |
External libraries can enable theming support through the M_LIBRARY macro. This macro creates a static MLibrary object, which is initialised when the library is loaded. During the construction phase, the MLibrary object registers itself to the MTheme, making the theme aware of the need for theming support for this particular library. Later on, when the library is unloaded, the MLibrary object is destroyed automatically and it unregisters the library from the MTheme.
Theming support allows a library to:
The registration name of the library is the build target name defined in the library .pro file. It is necessary to use CONFIG += meegotouch to enable the functionality described above. The following example illustrates a simple library .pro file:
MGEN_OUTDIR = ./.gen
MOC_DIR = ./.moc
OBJECTS_DIR = ./.obj
CONFIG += meegotouch
TARGET = mywidgets
TEMPLATE = lib
include(widgets/widgets.pri)
# mywidgets.cpp is a good place for the M_LIBRARY macro
SOURCES += mywidgets.cpp
HEADERS += \
$$PUBLIC_HEADERS \
$$PRIVATE_HEADERS \
target.path = /usr/lib
Widgets can be registered to the system using the M_REGISTER_WIDGET(classname) macro. It is necessary to register widgets to the system to be able to provide theming support for them. Widget registration allows the system to:
Views can be registered to the system using the M_REGISTER_VIEW(viewclass, controllerclass) macro. It is necessary to register views to the system to be able to provide theming support for them. View registration allows the system to:
Styles can be registered to the system using the M_REGISTER_STYLE(styleclass) macro. It is necessary to register styles to the system to be able to provide theming support for them. Note that if you use automatic style class generation through mgen/mmoc, the generated style class is automatically registered to the system.
Style registration allows the system to:
External libraries can provide style sheets and view configuration for their own widgets. Style sheets contain the actual values for the styling attributes, and the view configuration file allows the library to define the view class used for each widget. For example, it is possible to have a simple view for a widget in one theme and a more advanced version of the view in another theme. The view configuration file is a relatively simple .conf file, see the following example:
[MyCustomWidget] default = MyCustomWidgetView [MyOtherCustomWidget] default = MyOtherCustomWidgetView
ATTENTION: It is not possible to override styles that are not provided by the library, unless they are referenced as children of a widget that is provided by the library. Even object name selectors do not work unless the parent is specified, because the same name could be used at different places.
For example, if a library provides a custom widget called "MyCustomWidget" with a standard button children, and you want to change the style of this button by overriding MButtonStyle, you have to specify the parent widget in the CSS like this:
MyCustomWidget MButtonStyle#myObjectName { some-attribute: some-value; }
Just specifying the object name like this does NOT work:
MButtonStyle#myObjectName { /* DOES NOT WORK */ some-attribute: some-value; }
Theming support for application works in a similar way as for external libraries. The only difference is that libraries are only able to configure the widgets they declare, whereas applications can override nearly anything related to theming and styling. Applications can provide their own style sheet and view configuration files, and register their own widgets, views and styles to the system and provide theming for them. Applications have almost full control over their own look and feel.
Copyright © 2010 Nokia Corporation | MeeGo Touch |