{
class ui_viewmgr;
+/**
+ * @class ui_key_listener
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief This class extends to ui_base_key_listener to support an additional HW Menu key for mobile profile. Basically, HW Menu key will be propagated to
+ * the top view and ui_view::on_menu() will be triggered.
+ */
class ui_key_listener : public ui_base_key_listener
{
public:
{
class ui_view;
+/**
+ * @class ui_menu
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief ui_menu is to support EFL menu UI which could be active on one ui_view. A menu is used for traditional contextual popup to give an option in its
+ * view context. Elm_Ctxpopup widget could be set as this ui_menu content for mobile profile. ui_menu will set up all Elm_Ctxpopup decorating
+ * options instead of users for their convenient. A ui_menu is designed to be one subordinate of one ui_view in order to share events and contexts
+ * each other to work nicely. Only one menu could be active on a ui_view. That means the previous menu will be removed by ui_view when a new menu comes.
+ *
+ * @warning ui_menu and its content, Elm_Ctxpopup will be deleted by its owned ui_view on the proper time. So you can just leave its instance to it.
+ */
class ui_menu: public ui_base_overlay
{
public:
class ui_view;
+/**
+ * @class ui_popup
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief ui_popup is to support EFL popup UI which could be active on one ui_view. A popup is used for traditional popping context information to give
+ * an option or information in its view context. Elm_Popup widget could be set as this ui_popup content for mobile profile. ui_popup will set up all
+ * Elm_Popup decorating options instead of users for their convenient. A ui_popup is designed to be one subordinate of one ui_view in order to share
+ * events and contexts each other to work nicely. One of differ points of ui_popup with ui_menu is, multiple popup could be active at the same time.
+ * That means, a new ui_popup will be overlaid on the previous ui_popup on the demands. It's up to user's scenario.
+ *
+ * @warning ui_popup and its content, Elm_Popup will be deleted by its owned ui_view on the proper time. So you can just leave its instance to it.
+ */
class ui_popup : public ui_base_overlay
{
public:
namespace efl_viewmanager
{
+
+/**
+ * @class ui_view
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief This is a mobile standard view. This view extends ui_view and implements mobile specific behaviors for EFL view in mobile profile.
+ * Basically, ui_standard_view implements standard UI form for mobile application view. It internally constructs a layout which builds a basic form
+ * view that is consisted of title, tool and content parts. The title part locally has a left, right button parts as well as title and sub title text
+ * parts. The tool part is designed for an additional tools feature in a view. Elm_Toolbar widget could be used for this part and ui_standard_view will
+ * set up all Elm_Toolbar decorating options for users convenient. Lastly, the content part is used for main content for ui_standard_view. According
+ * to the system profile, when this view is pushed into a ui_viewmgr, it will internally create a software back key that triggers popping the view.
+ *
+ */
class ui_standard_view: public ui_view
{
public:
class ui_popup;
class ui_key_listener;
+/**
+ * @class ui_view
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief This is a mobile view. Typically, this view extends ui_base_view and implements mobile specific behaviors for EFL view in mobile profile.
+ * Basically, ui_view implements basics for running together with overlays such as ui_menu and ui_popup. You can use this ui_view as an empty ui form
+ * view.
+ */
class ui_view: public ui_base_view
{
public:
class ui_view;
class ui_app;
+/**
+ * @class ui_viewmgr
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief This is a mobile EFL view manager class. Typically, this view manager extends ui_base_viewmgr and implements mobile specific behaviors for
+ * EFL view manager in mobile profile. ui_viewmgr is nothing more than ui_base_viewmgr in behavior perspective. It just comes out with renaming class
+ * for adapting with other EFL mobile classes.
+ */
class ui_viewmgr: public ui_base_viewmgr
{
protected:
class ui_base_viewmgr;
+/**
+ * @class ui_base_key_listener
+ *
+ * @ingroup efl_viewmanager
+ *
+ * @brief This is a base class of EFL key listener. Typically, this class has a role for delegating event propagation from system to a view.
+ * ui_base_key_listener grabs HW back key event then pass it to the top view from the view manager. You could extend this class for more HW key
+ * events for your profile feature. By overriding ui_base_key_listener::extend_event_proc(), you could get the key event information when that event is
+ * triggered. This class must be requested by ui_base_viewmgr and controlled wholly by it.
+ */
class ui_base_key_listener
{
protected:
class ui_base_view;
+/**
+ * @class ui_base_overlay
+ *
+ * @internal
+ * @ingroup efl_viewmanager
+ *
+ * @brief This is a base class to support EFL overlay view which could be active on other ui_base_view. An overlay is designed to be one subordinate of one
+ * ui_base_view. ui_base_overlay is nothing more than ui_iface_overlay in behavior perspective. It just comes out with renaming class for adapting with
+ * other EFL base classes.
+ */
class ui_base_overlay: public ui_iface_overlay
{
protected:
*
* @ingroup efl_viewmanager
*
- * @brief UI View Class. This is the class of view. A view must have one content instance which represents a view for a current screen.
- * UI View may have it's own show/hide transition styles. That means, it's available that views have different show/hide effects on demands.
- * It's not mandatory but view should describe the transitions in this class.
- *
- * @warning When the transitions are finished, the view must to call ui_iface_viewmgr :: _push_finished(), ui_iface_viewmgr :: _pop_finished() in order that
- * The ui_iface_viewmgr keeps the view states exactly.
+ * @brief This is a base class of EFL view. Typically, this view extends ui_iface_view and implements basic behaviors for EFL view in all profiles.
+ * A view must have one Evas_Object content instance which represents a view for a current screen.
*/
class ui_base_view: public ui_iface_view
{
*
* @ingroup efl_viewmanager
*
- * @brief This is a base class of viewmgr. One viewmgr represents a class which contains multiple views.
- * A viewmgr manages not only views life-cycle but constructs basic infrastructures such as key events handling, transition effects, transient views,
- * etc. This interface guides you a basic policy and behaviors of a view manager. Basically, View manager must have a default window internally.
+ * @brief This is a base class of EFL view manager. Typically, this view manager extends ui_iface_viewmgr and implement basic behaviors for
+ * EFL view manager in all profiles. Basically, this view manager has one default window to display several logic views as well as this has
+ * a conformant and default application layout to display indicator, application layout and virtual keypad properly. This base view manager implements
+ * view transition effects. Of course, those could be customized for each profile. Also, it implements events blocking for views during views going
+ * back and forth. But the behavior will be turned on/off based on the system profile.
*
- * @warning viewmgr will remove all containing views when it's destroyed.
+ * @warning viewmgr will remove its window, conformant and default layout when it's destroyed.
*/
class ui_base_viewmgr: public ui_iface_viewmgr
{
/**
* @class ui_iface_overlay
*
- * @internal
* @ingroup ui_viewmanager
*
- * @brief This is a base class to support overlay view which could be active on other ui_iface_view. So an overlay should be a subordinates of a ui_iface_view.
- * The specific behaviors are totally depended on the derived class but it must be communicated with ui_iface_view to work cooperatively. Fundamentally,
- * overlay view provides simpler interfaces than ui_iface_view since most of the overlay views are active temporarily. This class is inherited to
- * ui_iface_rotatable class to handle view's rotation state.
+ * @brief This is a base class to support overlay view which could be active on other ui_iface_view. An overlay is designed to be one subordinate of one
+ * ui_iface_view. The specific behaviors of this class are totally depended on the derived class but it must be communicated with ui_iface_view to work
+ * successfully. Fundamentally, overlay view provides simpler interfaces than ui_iface_view since most of the overlay views will be active temporarily.
+ * This class is inherited to ui_iface_rotatable class to handle view's rotation state.
*/
class ui_iface_overlay: public ui_iface_rotatable
{
/**
* @class ui_iface_rotatable
*
- * @internal
* @ingroup ui_viewmanager
*
* @brief This is an interface class to support rotation behavior of views (or overlay). This class just defines status such as rotate, portrait, landscape
/**
* @class ui_iface_view
*
- * @internal
* @ingroup ui_viewmanager
*
- * @brief This is the base class of view. A view must have one actual view content instance which represents a view for a current screen.
+ * @brief This is a base class of view. A view must have one actual view content instance which represents a view for a current screen.
* The content type could be any types with regards to UI systems (ie, Eo*, Layer, Window...) A derived class must implement the view body based on the
* actual content in its UI system. This view will be belongs to a ui_iface_viewmgr instance and dominated its state by ui_iface_viewmgr. Basically,
* a view communicates with ui_iface_viewmgr to active cooperatively. This class is inherited to ui_iface_rotatable class to handle view's rotation
/**
* @class ui_iface_viewmgr
*
- * @internal
* @ingroup ui_viewmanager
*
* @brief This is a base class of viewmgr. One viewmgr represents a class which contains multiple views.
projects / platform / core / uifw / ui-viewmgr.git / commitdiff