[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

documentation/manual/source/index.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

documentation/manual/source/pages/core.rst

@@ -1,11 +1,9 @@
 Core
 **************
 
-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

documentation/manual/source/pages/data_binding/controller.rst

@@ -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:

documentation/manual/source/pages/desktop.rst

@@ -0,0 +1,53 @@
+Desktop
+***********
+
+.. _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>`
+
+Layouts
+=======
+
+.. toctree::
+   :maxdepth: 2
+
+   desktop/ui_layouting
+
+Themes
+======
+
+.. 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

documentation/manual/source/pages/gui_toolkit/ui_appearance.rst → documentation/manual/source/pages/desktop/ui_appearance.rst

@@ -1,16 +1,16 @@
-.. _pages/gui_toolkit/ui_appearance#appearance:
+.. _pages/desktop/ui_appearance#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:
 
 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:
 
 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:
 
 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:
 
 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:
 
 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:
 
 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:
 
 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
 --------------

documentation/manual/source/pages/gui_toolkit/ui_custom_themes.rst → documentation/manual/source/pages/desktop/ui_custom_themes.rst

@@ -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
 ====================

documentation/manual/source/pages/gui_toolkit/ui_decorators.rst → documentation/manual/source/pages/desktop/ui_decorators.rst

@@ -1,9 +1,9 @@
-.. _pages/gui_toolkit/ui_decorators#decorators:
+.. _pages/desktop/ui_decorators#decorators:
 
 Decorators
 **********
 
-.. _pages/gui_toolkit/ui_decorators#introduction:
+.. _pages/desktop/ui_decorators#introduction:
 
 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 <http://demo.qooxdoo.org/current/apiviewer/#qx.ui.decoration>`_.
 
-.. _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
 ========================

documentation/manual/source/pages/gui_toolkit/ui_develop.rst → documentation/manual/source/pages/desktop/ui_develop.rst

@@ -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 <http://demo.qooxdoo.org/%{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:
 
 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
 =================