Browse files

[BUG #6230] renamed 'gui_toolkit' to 'desktop'

- these are massive mass changes, and i cannot check every occurrence of
  'gui_toolkit' that is touched by them
- so maybe i've broken some links, which need to be fixed afterwards
  • Loading branch information...
1 parent f9fb970 commit c14242fcc3ea5d76b07d2684e412122cf6dd3557 @thron7 thron7 committed Mar 26, 2012
Showing with 175 additions and 177 deletions.
  1. +2 −2 documentation/manual/source/index.rst
  2. +2 −4 documentation/manual/source/pages/core.rst
  3. +1 −1 documentation/manual/source/pages/data_binding/controller.rst
  4. +53 −0 documentation/manual/source/pages/desktop.rst
  5. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/new_selection_api.png
  6. +17 −17 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_appearance.rst
  7. +3 −3 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_custom_themes.rst
  8. +7 −7 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_decorators.rst
  9. +9 −9 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_develop.rst
  10. +7 −7 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_dragdrop.rst
  11. +45 −45 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling.rst
  12. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/codesampleform.png
  13. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/doublerenderer.png
  14. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/form.png
  15. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/iexecutable.png
  16. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/iform.png
  17. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/iformvalue.png
  18. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/imodel.png
  19. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/imodelselection.png
  20. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/irange.png
  21. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/placeholderrenderer.png
  22. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/resetter.png
  23. BIN ...ntation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/sd-asyncvalidate-540x308.png
  24. BIN ...mentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/sd-createmodel-473x400.png
  25. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/serialization.png
  26. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/singlerenderer.png
  27. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling/validationmanager.png
  28. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_form_handling2/namespace._skip_.rst
  29. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing.rst
  30. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/available_shortcuts.rst
  31. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/browser_bugs.rst
  32. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/copy_and_paste.rst
  33. 0 ...tation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/default_paragraph_handling.rst
  34. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/featurelist.rst
  35. 0 ...mentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/html_editing_in_general.rst
  36. BIN ...mentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/htmlarea_screenshot_1_0.png
  37. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/integration_guide.rst
  38. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/list_handling.rst
  39. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/paragraph_handling.rst
  40. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/recommendations.rst
  41. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/technicalfeaturelist.rst
  42. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/textalign.rst
  43. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/undo_redo.rst
  44. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_html_editing/webkit_bug.png
  45. +7 −7 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_inline.rst
  46. +8 −8 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_interaction.rst
  47. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_layouting.rst
  48. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_menu_handling.rst
  49. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_menu_handling/complex_menu.png
  50. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_menu_handling/context_menu.png
  51. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_menu_handling/file_menu.png
  52. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_overview.rst
  53. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_resources.rst
  54. +1 −1 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_selection.rst
  55. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling.rst
  56. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_default_styling.png
  57. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_editable_cells.png
  58. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_focus_indicator.png
  59. BIN ...anual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_header_cell_decorator_hover.png
  60. BIN ...entation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_header_cell_hover.png
  61. BIN ...tation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_header_cell_styling.png
  62. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_header_styling.png
  63. BIN ...tion/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_pane_cell_backgrounds.png
  64. BIN ...tation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_pane_cell_selection.png
  65. BIN ...ation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_pane_cell_selection2.png
  66. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_pane_styling.png
  67. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_resize_line.png
  68. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_scrollbars.png
  69. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_statusbar.png
  70. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_widget_styling.png
  71. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_table_styling/table_without_header.png
  72. +1 −1 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_theming.rst
  73. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_theming/window_classic_theme.png
  74. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_theming/window_modern_theme.png
  75. BIN documentation/manual/source/pages/{gui_toolkit → desktop}/ui_theming/window_simple_theme.png
  76. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_using_themes_of_contribs.rst
  77. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_webfonts.rst
  78. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/ui_widgets.rst
  79. 0 documentation/manual/source/pages/{gui_toolkit → desktop}/window_management.rst
  80. +1 −1 documentation/manual/source/pages/development/image_clipping_and_combining.rst
  81. +2 −2 documentation/manual/source/pages/getting_started/requirements.rst
  82. +0 −53 documentation/manual/source/pages/gui_toolkit.rst
  83. +1 −1 documentation/manual/source/pages/introduction/about.rst
  84. +1 −1 documentation/manual/source/pages/tool/code_structure.rst
  85. +1 −1 documentation/manual/source/pages/tutorials/tutorial-part-4-1.rst
  86. +4 −4 documentation/manual/source/pages/tutorials/tutorial-part-4-2-1.rst
  87. +1 −1 documentation/manual/source/pages/tutorials/tutorial-part-4-2.rst
  88. +1 −1 documentation/manual/source/toc.rst
@@ -67,9 +67,9 @@ Welcome to the manual of qooxdoo |version|. Here are some highlights of what you
||tutorial|| **Desktop** |
-| | * :doc:`Introduction <pages/gui_toolkit/ui_overview>` |
+| | * :doc:`Introduction <pages/desktop/ui_overview>` |
| | * :doc:`Tutorial <pages/tutorials/tutorial-part-1>` |
-| | * :doc:`Reference <pages/gui_toolkit/ui_widgets>` |
+| | * :doc:`Reference <pages/desktop/ui_widgets>` |
.. rst-class:: toc
@@ -1,11 +1,9 @@
-qooxdoo *Core* is not a component on its own, but encompasses central features of the qooxdoo class library. The elements described here are available in all qooxdoo components, be it *Desktop*, *Mobile*, *Website* or *Server*. Among these features are a dedicated *class system* with custom class *properties*, *data binding* and a runtime *environment*.
+qooxdoo Core is not a component on its own, but encompasses central features of the qooxdoo class library. The elements described here are available in all qooxdoo components, be it Desktop, Mobile, Website or Server. Among these features are a dedicated class system with custom class properties, data binding and a runtime environment.
-In this section we also cover qooxdoo's *tool chain*, as it is relevant for more than one of the other components.
-We recommend that you at least make your way through the chapters *Introduction to Object Orientation*, *Features of Object Orientation* and *Classes* from the Object Orientation section, which provide the foundation for working with qooxdoo's class system. The other chapters can be read when the need arises, and as reference material for the other components' documentation. Users of the SDK, which includes the tool chain, will greatly benefit from at least covering the *Introduction* chapter in the Tooling section.
+We recommend that you at least make your way through the chapters *Introduction to Object Orientation*, *Features of Object Orientation* and *Classes* from the *Object Orientation* section, which provide the foundation for working with qooxdoo's class system. The other chapters can be read when the need arises, and as reference material for the other components' documentation.
Object Orientation
@@ -148,7 +148,7 @@ The usage equals to the usage of all other controllers. The main properties of i
// create the model
var model = formController.createModel();
-If you nee additional information on forms, see :ref:`form handling documentation <pages/gui_toolkit/ui_form_handling#form_object>`.
+If you nee additional information on forms, see :ref:`form handling documentation <pages/desktop/ui_form_handling#form_object>`.
After executing this code, the controller and the model variable do have the model available and therefore, the controller can set up the bindings.
.. _pages/data_binding/controller#combining_controller:
@@ -0,0 +1,53 @@
+.. _index#documents:
+.. toctree::
+ desktop/ui_overview
+Widgets Introduction
+.. toctree::
+ :maxdepth: 1
+ widget
+ desktop/ui_widgets
+ desktop/ui_interaction
+ desktop/ui_resources
+ desktop/ui_selection
+ desktop/ui_dragdrop
+ desktop/ui_inline
+ desktop/ui_develop
+ desktop/ui_form_handling
+ desktop/ui_menu_handling
+ desktop/window_management
+ desktop/ui_html_editing
+ desktop/ui_table_styling
+Widget Reference
+* :doc:`Widget reference </pages/widget/widget_ref>`
+.. toctree::
+ :maxdepth: 2
+ desktop/ui_layouting
+.. toctree::
+ :maxdepth: 1
+ desktop/ui_theming
+ desktop/ui_appearance
+ desktop/ui_custom_themes
+ desktop/ui_decorators
+ desktop/ui_webfonts
+ desktop/ui_using_themes_of_contribs
@@ -1,16 +1,16 @@
-.. _pages/gui_toolkit/ui_appearance#appearance:
+.. _pages/desktop/ui_appearance#appearance:
-.. _pages/gui_toolkit/ui_appearance#what_is_it:
+.. _pages/desktop/ui_appearance#what_is_it:
What is it?
An appearance theme is the main part of the theme. It contains all appearance definitions which are responsible for holding all styling informations for the wigets. Usually the apperance theme is the biggest theme and uses all other theme classes like the Decorator- or Font-theme.
-.. _pages/gui_toolkit/ui_appearance#theme_structure:
+.. _pages/desktop/ui_appearance#theme_structure:
Theme Structure
@@ -28,7 +28,7 @@ A theme normally consists of a set of entries. Each entry has a key which is bas
-.. _pages/gui_toolkit/ui_appearance#selectors:
+.. _pages/desktop/ui_appearance#selectors:
@@ -58,7 +58,7 @@ A classic example for this is the ``Spinner`` widget. A ``Spinner`` is basically
Each of these selectors must be defined by the selected appearance. Otherwise a warning about missing selectors is displayed.
-.. _pages/gui_toolkit/ui_appearance#aliases:
+.. _pages/desktop/ui_appearance#aliases:
@@ -117,7 +117,7 @@ Internally the above results into the following remapping:
"spinner/upbutton/icon" => "myimage"
"spinner/upbutton/label" => "button/label"
-.. _pages/gui_toolkit/ui_appearance#entries:
+.. _pages/desktop/ui_appearance#entries:
@@ -151,7 +151,7 @@ The more complex full entry is a map with several sub entries where all are opti
-.. _pages/gui_toolkit/ui_appearance#style_method:
+.. _pages/desktop/ui_appearance#style_method:
Style Method
@@ -198,7 +198,7 @@ Instead, you should always define the else case:
One thing we have also seen in the example is that it is perfectly possible to create the return map using standard JavaScript and fill in keys during the runtime of the ``style`` method. This allows to use more complex statements to solve the requirements of today's themes were a lot of states or dependencies between states can have great impact on the result map.
-.. _pages/gui_toolkit/ui_appearance#includes:
+.. _pages/desktop/ui_appearance#includes:
@@ -209,7 +209,7 @@ The results of the include block are merged with lower priority than the local d
Includes do nothing to child controls. They just include exactly the given selector into the current selector.
-.. _pages/gui_toolkit/ui_appearance#child_control_aliases:
+.. _pages/desktop/ui_appearance#child_control_aliases:
Child Control Aliases
@@ -278,35 +278,35 @@ As you can see the ``spinner/upbutton`` is kept in its original state. This allo
When ``alias`` and ``include`` are identically pointing to the same selector the result is identical to the real alias
-.. _pages/gui_toolkit/ui_appearance#base_calls:
+.. _pages/desktop/ui_appearance#base_calls:
Base Calls
When extending themes the so-named ``base`` flag can be enabled to include the result of this selector of the derived theme into the local selector. This is quite comparable to the ``this.base(arguments, ...)`` call in member functions of typical qooxdoo classes. It does all the things the super class has done plus the local things. Please note that all local defintions have higher priority than the inheritance. See next paragraph for details.
-.. _pages/gui_toolkit/ui_appearance#priorities:
+.. _pages/desktop/ui_appearance#priorities:
Priority is quite an important topic when dealing with so many sources to fill a selector with styles. Logically the definitions of the ``style`` function are the ones with the highest priority followed by the ``include`` block. The least priority has the ``base`` flag for enabling the *base calls* in inherited themes.
-.. _pages/gui_toolkit/ui_appearance#states:
+.. _pages/desktop/ui_appearance#states:
A state is used for every visual state a widget may have. Every state has flag character. It could only be enabled or disabled via the API ``addState`` or ``removeState``.
-.. _pages/gui_toolkit/ui_appearance#performance:
+.. _pages/desktop/ui_appearance#performance:
qooxdoo has a lot of impressive caching ideas behind the whole appearance handling. As one could easily imagine all these features are quite expensive when they are made on every widget instance and more important, each time a state is modified.
-.. _pages/gui_toolkit/ui_appearance#appearance_queue:
+.. _pages/desktop/ui_appearance#appearance_queue:
Appearance Queue
@@ -315,14 +315,14 @@ First of all we have the appearance queue. Widgets which are visible and inserte
The queue also minimizes the effect of multiple state changes when they happen at once. All changes are combined into one lookup to the theme e.g. changing ``hovered`` and ``focused`` directly after each other would only result into one update instead of two. In a modern GUI typically each click influence a few widgets at once and in these widgets a few states at once so this optimization really pays of.
-.. _pages/gui_toolkit/ui_appearance#selector_caching:
+.. _pages/desktop/ui_appearance#selector_caching:
Selector Caching
Each widget comes with an appearance or was created as a child control of another widget. Because the detection of the selector is quite complex with iterations up to the parent chain, the resulting selector of each widget is cached. The system benefits from the idea that child controls are never moved outside the parent they belong to. So a child controls which is cached once keeps the selector for lifetime. The only thing which could invalidate the selectors of a widget and all of its child controls is the change of the property ``appearance`` in the parent of the child control.
-.. _pages/gui_toolkit/ui_appearance#alias_caching:
+.. _pages/desktop/ui_appearance#alias_caching:
Alias Caching
@@ -331,7 +331,7 @@ The support for aliases is resolved once per application load. So after a while
The list of resolved aliases can be seen when printing out the map under ``qx.theme.manager.Appearance.getInstance().__aliasMap`` to the log console. It just contains the fully resolved alias (aliases may redirect to each other as well).
-.. _pages/gui_toolkit/ui_appearance#result_caching:
+.. _pages/desktop/ui_appearance#result_caching:
Result Caching
@@ -1,4 +1,4 @@
-.. _pages/gui_toolkit/ui_custom_themes#custom_themes:
+.. _pages/desktop/ui_custom_themes#custom_themes:
Custom Themes
@@ -7,7 +7,7 @@ There are certain circumstances when the built-in themes are no more sufficient
Basically you have two choices to create a custom theme depending on your needs and the amount you want to change. The next two sections describe both briefly.
-.. _pages/gui_toolkit/ui_custom_themes#extending_themes:
+.. _pages/desktop/ui_custom_themes#extending_themes:
Extending Themes
@@ -76,7 +76,7 @@ After editing your ``config.json`` the very last step is to generate your applic
These steps are also applicable for the other themes.
-.. _pages/gui_toolkit/ui_custom_themes#define_custom_themes:
+.. _pages/desktop/ui_custom_themes#define_custom_themes:
Define Custom Themes
@@ -1,9 +1,9 @@
-.. _pages/gui_toolkit/ui_decorators#decorators:
+.. _pages/desktop/ui_decorators#decorators:
-.. _pages/gui_toolkit/ui_decorators#introduction:
+.. _pages/desktop/ui_decorators#introduction:
@@ -12,7 +12,7 @@ Decorations are used to style widgets. The idea is to have an independent layer
Decorations are used for both, the ``shadow`` and the ``decorator`` property. They could be applied separately or together. There is no dependency between them.
-.. _pages/gui_toolkit/ui_decorators#using_decorators:
+.. _pages/desktop/ui_decorators#using_decorators:
Using Decorators
@@ -22,7 +22,7 @@ Generally all decorators used should be part of the selected decorator theme. Th
It is also regarded as bad style to make use of so-named inline decorators which are created by hand as part of a function call. The reason for this is that generally decorators defined by the theme may be used in multiple places. This means that widgets and application code should not directly deal with decorator instances.
-.. _pages/gui_toolkit/ui_decorators#decoration_theme:
+.. _pages/desktop/ui_decorators#decoration_theme:
Decoration Theme
@@ -83,7 +83,7 @@ Sometimes it is very handy to change change only little details about the decora
As you can see here, we include the previously defined decorator and override the backgroundColor property. Thats all you need to do!
-.. _pages/gui_toolkit/ui_decorators#custom_decorators:
+.. _pages/desktop/ui_decorators#custom_decorators:
Custom Decorators
@@ -114,7 +114,7 @@ Additionall to these explicit decorators, qooxdoo supplies a set of Mixins which
As you may have guessed, the last three mixins do not work cross browser due to the fact that they rely on CSS propertes not available in all browsers. If you want more details, take a look at the `API documentations of the mixins <>`_.
-.. _pages/gui_toolkit/ui_decorators#writing_decorators:
+.. _pages/desktop/ui_decorators#writing_decorators:
Writing Decorators
@@ -132,7 +132,7 @@ One thing to additionally respect is that ``resize`` and ``tint`` should be as f
Each decorator configuration means exactly one decorator instance (created with the first usage). Even when dozens of widgets use the decorator only one instance is used. To cache the markup is a good way to improve the initial time to create new element instances. These configured elements are reused e.g. a hover effect which moves from "Button 1" to "Button 2" uses the same DOM element when reaching "Button 2" as it has used in "Button 1". This way the number of DOM elements needed is reduced dramatically. Generally each decorator instance may be used to create dozens of these elements, but after some time enough elements may have been created to fulfill all further needs for the same styling.
-.. _pages/gui_toolkit/ui_decorators#writing_decorator_mixins:
+.. _pages/desktop/ui_decorators#writing_decorator_mixins:
Writing Decorator Mixins
@@ -1,11 +1,11 @@
-.. _pages/gui_toolkit/ui_develop#custom_widgets:
+.. _pages/desktop/ui_develop#custom_widgets:
Custom Widgets
Most widgets are built using a combination of pre-existing, more basic widgets. This is also true for custom widgets made for a specific application or as an extension to the existing feature set of qooxdoo.
-.. _pages/gui_toolkit/ui_develop#inheritance_structure:
+.. _pages/desktop/ui_develop#inheritance_structure:
Inheritance Structure
@@ -16,7 +16,7 @@ A good example: Most rich text editors implemented in JavaScript make use of an
The qooxdoo ``Spinner`` for example extends the ``Widget`` as well and adds a ``TextField`` and two ``RepeatButton`` instances. The layout is done by a Grid layout. All the children and the chosen layout are hidden from the outside. There are no public accessors for the layout or the children. This makes sense as no one is interested in the children of a ``Spinner`` widget. These methods would also mean a lot of bloat added to the API of such an widget.
-.. _pages/gui_toolkit/ui_develop#setup_content:
+.. _pages/desktop/ui_develop#setup_content:
Setup Content
@@ -31,7 +31,7 @@ It is possible to use any layout available. To set up the layout just use ``_set
For details refer to the API documentation of `qx.ui.core.Widget <{version}/apiviewer/#qx.ui.core.Widget>`_.
-.. _pages/gui_toolkit/ui_develop#child_controls:
+.. _pages/desktop/ui_develop#child_controls:
Child Controls
@@ -65,7 +65,7 @@ Each child control should directly add itself to the parent. As mentioned before
* ``_isChildControlVisible(id)``: Returns ``true`` if the child control with the given ID is created and visible.
* ``hasChildControl(id)``: Returns ``true`` if the child control with the given ID has been created.
-.. _pages/gui_toolkit/ui_develop#styling:
+.. _pages/desktop/ui_develop#styling:
@@ -87,7 +87,7 @@ As mentioned, a key always starts with the appearance of the first widget which
For details about styling please refer to :doc:`the theming article <ui_theming>`.
-.. _pages/gui_toolkit/ui_develop#html_elements:
+.. _pages/desktop/ui_develop#html_elements:
HTML Elements
@@ -106,14 +106,14 @@ Both elements are instances of ``qx.html.Element`` so they come with a cross-bro
The elements are accessible through the functions ``getContentElement()`` and ``getContainerElement()``, respectively. The elements are stored privately in each widget instance and are only accessible through these methods in derived classes.
-.. _pages/gui_toolkit/ui_develop#custom_elements:
+.. _pages/desktop/ui_develop#custom_elements:
Custom Elements
qooxdoo normally generates a bunch of styled ``div`` elements. Some widgets like iframes or images need other elements, though. Normally the only element which is replaced is the content element. To achieve this, the method ``_createContentElement`` needs to be overwritten. The overwritten method should create an instance of ``qx.html.Element`` (or a derived class), configure it with some static attributes or styles, and finally return it. For most natively supported types there exists a class which can be used already. In special cases the widget author also needs to write a special low-level class which is derived from ``qx.html.Element``.
-.. _pages/gui_toolkit/ui_develop#working_with_events:
+.. _pages/desktop/ui_develop#working_with_events:
Working with Events
@@ -125,7 +125,7 @@ Events can be added to the HTML elements as well as to the child controls. The n
Where ``XXX`` stands for the name of the event or of the change that happens. This will result in names like ``_onIframeLoad`` or ``_onContentInput``.
-.. _pages/gui_toolkit/ui_develop#anonymous_widgets:
+.. _pages/desktop/ui_develop#anonymous_widgets:
Anonymous Widgets
Oops, something went wrong.

0 comments on commit c14242f

Please sign in to comment.