CEGUI Wiki - Crazy Eddie's GUI System (Open Source) - User contributions [en]

BuildStatus

2014-10-23T18:51:30Z

Timotei: Created page with "[![Build status v0-8 Branch](https://ci.appveyor.com/api/projects/status/6sugcxlg65e6aogb/branch/v0-8?svg=true)](https://ci.appveyor.com/project/timootei/cegui/branch/v0-8) [!..."

[![Build status v0-8 Branch](https://ci.appveyor.com/api/projects/status/6sugcxlg65e6aogb/branch/v0-8?svg=true)](https://ci.appveyor.com/project/timootei/cegui/branch/v0-8)
[![Build status v0 Branch](https://ci.appveyor.com/api/projects/status/6sugcxlg65e6aogb/branch/v0?svg=true)](https://ci.appveyor.com/project/timootei/cegui/branch/v0)
[![Build status default Branch](https://ci.appveyor.com/api/projects/status/6sugcxlg65e6aogb/branch/default?svg=true)](https://ci.appveyor.com/project/timootei/cegui/branch/default)

Developer Team

2014-08-21T21:19:02Z

Timotei: Add myself to the team :)

Something about the team should go here

* [[User:Crazyeddie]] - project lead, project creator, programmer, wizard in his spare time
* [[User:Kulik]] - programmer (focus on all parts of CEGUI, especially the CEGUI Animation features, Unix support), CEED creator, GSoC mentor
* [[User:Ident]] - programmer (focus on the Renderers for OpenGL, OpenGL 3.2+ Core Profile, Direct3D11 and Ogre Renderer, as well as the CEED Look n' Feel Editor, Windows/Visual Studio support, the ColourPicker widget), also reviews mustard in his spare time
* [[User:Timotei]] - programmer (focus on the non-focus, new input system, new model-view widgets, SDK builder)

NewModelViewArchitecture

2014-08-15T18:44:14Z

Timotei: /* Process */

Homepage for the WIP Model-View architecture for CEGUI widgets!

=Introduction=
The new architecture aims to unify the underlying implementation of several widgets so that they will use a common base model provider. This will involve a lot of ABI and API breakage.

=Proposed architecture=

==ModelIndex==
Identifies uniquely items in the model.
This acts as a "dumb token" that it's entirely model's task to understand/process it.

Properties:
* modelData : void *

==ItemDataRole==
This is an enum, that contains the types of data the model is requested to provide.

Enum members:
* Text
* ImageDecoration
* Tooltip
* <etc>
* UserDefined (used as a base for user-defined custom roles)

==ItemModel==
The model for the view, that provides data like items count to the view.
This is implemented by the developers that want to use this new architecture.

Structure-related methods:
* childrenCount(modelIndex)
* makeIndex(child, parentModelIndex)
* getParentIndex(modelIndex)

Data-provider methods:
* getData(modelIndex, role)

Events:
* ChildrenAdded - startIndex, count
* ChildrenRemoved - startIndex, count
* ChildrenDataChanged - startIndex, count

TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?

==ModelIndex Invalidation==
Views might (read: will) store indices for a faster rendering or operations on the view. But these indices might become invalid if:
* the underlying model instance changes (i.e.: model is set to another instance)
** Solution: Just invalidate the memorized indices
* an index from the "middle" is removed
** Solution1: Create persistent model indices, like Qt does.
*** Con: too much management required, prone to errors.
** Solution2: Query the model for validity
*** ''isValid'' will be moved to the ViewModel
** Solution3: Other?

=Affected widgets=
===Changed (to the new architecture) widgets===
* ComboBox + ComboDropList -> ComboView
* Tree -> TreeView
* ListBox -> ListView

===New widgets===
* GridView
* ListBoxWidget (combines model & view together for simple usage cases)

===Removed/deprecated widgets===
* MultiColumnList (replaced by GridView)
* ItemListbox (duplicated by ListBox)

===To decide===
* ItemListBase
** It's used in other places like: MenuBase and ScrolledItemListBase
** Remove the other usages as well?

=Workflow examples=
==List rendering==

* Create root model index (parent=0)
* Query the number of children for root
* For each child (value=[0, childrenCount))
** Create child model index (parent=rootModelIndex)
** Query the image to be displayed for child index (Role=Imagedecoration)
** Draw image
** Query the text to be displayed for child index (Role=text)
** Draw text
* Render non-child elements

==Tree rendering==
===Full/first-time rendering===
Triggered first time, or when whole model changes.

Recursive rendering procedure starting with a model index
* > Given a parent model index
* Query the number of children for index
* For each child (value=[0, childrenCount))
** Create child model index (parent=parentModelIndex)
** Query the image to be displayed for child index (Role=imageDecoration)
** Draw image
** Query the text to be displayed for child index (Role=Text)
** Draw text
** Call procedure with child model index.

Actual rendering:
* Call procedure defined above with root model index (parent = 0)
* Render non-row elements

===Item(s) modified/isolated rendering===
Triggered when some parts of the model changed, but not all.

=Performance=
We want to measure how well the new views perform compared to the old ones.

==Tested views/widgets==
The following combinations of related views/widgets will be compared:
* ListWidget, ListView - Listbox, ItemListbox
* TreeView, TreeWidget - Tree

==Process==
Before running the performance tests be sure to be in RELEASE mode.
The process of measuring the performance consists of executing the following steps. After each one, the render step should be called, to simulate a real usage:

For list views/widgets
* Insert 5000 items
* Clear list
* Insert 10000 items
* Delete first 1500 items
* Repeat the following 17 times
** Delete 13 items
* Delete last 1230 items
* Clear list
* Insert 500 items
* Insert 100 items after the 100'th item
* Sort items ascending
* Sort items descending

For the tree views/widgets:
* Insert 100 root items, each with 100 items
* Expand all items
* Clear first 3 root item's children
* Sort

NewModelViewArchitecture

2014-08-15T15:54:29Z

Timotei: /* Process */

Homepage for the WIP Model-View architecture for CEGUI widgets!

=Introduction=
The new architecture aims to unify the underlying implementation of several widgets so that they will use a common base model provider. This will involve a lot of ABI and API breakage.

=Proposed architecture=

==ModelIndex==
Identifies uniquely items in the model.
This acts as a "dumb token" that it's entirely model's task to understand/process it.

Properties:
* modelData : void *

==ItemDataRole==
This is an enum, that contains the types of data the model is requested to provide.

Enum members:
* Text
* ImageDecoration
* Tooltip
* <etc>
* UserDefined (used as a base for user-defined custom roles)

==ItemModel==
The model for the view, that provides data like items count to the view.
This is implemented by the developers that want to use this new architecture.

Structure-related methods:
* childrenCount(modelIndex)
* makeIndex(child, parentModelIndex)
* getParentIndex(modelIndex)

Data-provider methods:
* getData(modelIndex, role)

Events:
* ChildrenAdded - startIndex, count
* ChildrenRemoved - startIndex, count
* ChildrenDataChanged - startIndex, count

TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?

==ModelIndex Invalidation==
Views might (read: will) store indices for a faster rendering or operations on the view. But these indices might become invalid if:
* the underlying model instance changes (i.e.: model is set to another instance)
** Solution: Just invalidate the memorized indices
* an index from the "middle" is removed
** Solution1: Create persistent model indices, like Qt does.
*** Con: too much management required, prone to errors.
** Solution2: Query the model for validity
*** ''isValid'' will be moved to the ViewModel
** Solution3: Other?

=Affected widgets=
===Changed (to the new architecture) widgets===
* ComboBox + ComboDropList -> ComboView
* Tree -> TreeView
* ListBox -> ListView

===New widgets===
* GridView
* ListBoxWidget (combines model & view together for simple usage cases)

===Removed/deprecated widgets===
* MultiColumnList (replaced by GridView)
* ItemListbox (duplicated by ListBox)

===To decide===
* ItemListBase
** It's used in other places like: MenuBase and ScrolledItemListBase
** Remove the other usages as well?

=Workflow examples=
==List rendering==

* Create root model index (parent=0)
* Query the number of children for root
* For each child (value=[0, childrenCount))
** Create child model index (parent=rootModelIndex)
** Query the image to be displayed for child index (Role=Imagedecoration)
** Draw image
** Query the text to be displayed for child index (Role=text)
** Draw text
* Render non-child elements

==Tree rendering==
===Full/first-time rendering===
Triggered first time, or when whole model changes.

Recursive rendering procedure starting with a model index
* > Given a parent model index
* Query the number of children for index
* For each child (value=[0, childrenCount))
** Create child model index (parent=parentModelIndex)
** Query the image to be displayed for child index (Role=imageDecoration)
** Draw image
** Query the text to be displayed for child index (Role=Text)
** Draw text
** Call procedure with child model index.

Actual rendering:
* Call procedure defined above with root model index (parent = 0)
* Render non-row elements

===Item(s) modified/isolated rendering===
Triggered when some parts of the model changed, but not all.

=Performance=
We want to measure how well the new views perform compared to the old ones.

==Tested views/widgets==
The following combinations of related views/widgets will be compared:
* ListWidget, ListView - Listbox, ItemListbox
* TreeView, TreeWidget - Tree

==Process==
Before running the performance tests be sure to be in RELEASE mode.
The process of measuring the performance will be the following:

For list views/widgets
* Insert 5000 items
* Render
* Clear list
* Render
* Insert 10000 items
* Render
* Delete first 1500 items
* Render
* Repeat the following 17 times
** Delete 13 items
** Render
* Delete last 1230 items
* Render
* Clear list
* Render
* Insert 500 items
* Render
* Insert 100 items after the 100'th item
* Render
* Sort items ascending
* Render
* Sort items descending
* Render

For the tree views/widgets:
* Insert 100 root items, each with 100 items
* Render
* Expand all items
* Render
* Clear first 3 root item's children
* Render
* Sort
* Render

NewModelViewArchitecture

2014-08-08T19:29:25Z

Timotei: Add performance process

Homepage for the WIP Model-View architecture for CEGUI widgets!

=Introduction=
The new architecture aims to unify the underlying implementation of several widgets so that they will use a common base model provider. This will involve a lot of ABI and API breakage.

=Proposed architecture=

==ModelIndex==
Identifies uniquely items in the model.
This acts as a "dumb token" that it's entirely model's task to understand/process it.

Properties:
* modelData : void *

==ItemDataRole==
This is an enum, that contains the types of data the model is requested to provide.

Enum members:
* Text
* ImageDecoration
* Tooltip
* <etc>
* UserDefined (used as a base for user-defined custom roles)

==ItemModel==
The model for the view, that provides data like items count to the view.
This is implemented by the developers that want to use this new architecture.

Structure-related methods:
* childrenCount(modelIndex)
* makeIndex(child, parentModelIndex)
* getParentIndex(modelIndex)

Data-provider methods:
* getData(modelIndex, role)

Events:
* ChildrenAdded - startIndex, count
* ChildrenRemoved - startIndex, count
* ChildrenDataChanged - startIndex, count

TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?

==ModelIndex Invalidation==
Views might (read: will) store indices for a faster rendering or operations on the view. But these indices might become invalid if:
* the underlying model instance changes (i.e.: model is set to another instance)
** Solution: Just invalidate the memorized indices
* an index from the "middle" is removed
** Solution1: Create persistent model indices, like Qt does.
*** Con: too much management required, prone to errors.
** Solution2: Query the model for validity
*** ''isValid'' will be moved to the ViewModel
** Solution3: Other?

=Affected widgets=
===Changed (to the new architecture) widgets===
* ComboBox + ComboDropList -> ComboView
* Tree -> TreeView
* ListBox -> ListView

===New widgets===
* GridView
* ListBoxWidget (combines model & view together for simple usage cases)

===Removed/deprecated widgets===
* MultiColumnList (replaced by GridView)
* ItemListbox (duplicated by ListBox)

===To decide===
* ItemListBase
** It's used in other places like: MenuBase and ScrolledItemListBase
** Remove the other usages as well?

=Workflow examples=
==List rendering==

* Create root model index (parent=0)
* Query the number of children for root
* For each child (value=[0, childrenCount))
** Create child model index (parent=rootModelIndex)
** Query the image to be displayed for child index (Role=Imagedecoration)
** Draw image
** Query the text to be displayed for child index (Role=text)
** Draw text
* Render non-child elements

==Tree rendering==
===Full/first-time rendering===
Triggered first time, or when whole model changes.

Recursive rendering procedure starting with a model index
* > Given a parent model index
* Query the number of children for index
* For each child (value=[0, childrenCount))
** Create child model index (parent=parentModelIndex)
** Query the image to be displayed for child index (Role=imageDecoration)
** Draw image
** Query the text to be displayed for child index (Role=Text)
** Draw text
** Call procedure with child model index.

Actual rendering:
* Call procedure defined above with root model index (parent = 0)
* Render non-row elements

===Item(s) modified/isolated rendering===
Triggered when some parts of the model changed, but not all.

=Performance=
We want to measure how well the new views perform compared to the old ones.

==Tested views/widgets==
The following combinations of related views/widgets will be compared:
* ListWidget, ListView - Listbox, ItemListbox
* TreeView, TreeWidget - Tree

==Process==
The process of measuring the performance will be the following:

For each view/widget
* Insert 1000 items
* Render
* Clear list
* Render
* Insert 1001 items
* Render
* Delete first 150 items
* Render
* Repeat the following 17 times
** Delete 13 items
** Render
* Delete last 123 items
* Render
* Clear list
* Render
* Insert 137 items
* Render
* Insert 10 items after the 100'th item
* Render
* Clear list
* Render
* Insert 1000 items
* Render
* Sort items
* Render

For the tree-based views/widgets only:
* Insert 100 root items, each with 100 items
* Render
* Expand all items
* Render
* Clear first 3 root item's children
* Render
* Sort
* Render

NewModelViewArchitecture

2014-05-23T21:27:38Z

Timotei: /* List rendering */

NewModelViewArchitecture

2014-05-23T21:26:53Z

Timotei: update: dumb model index, itemdata role and row/column -> children

Homepage for the WIP Model-View architecture for CEGUI widgets!

=Introduction=
The new architecture aims to unify the underlying implementation of several widgets so that they will use a common base model provider. This will involve a lot of ABI and API breakage.

=Proposed architecture=

==ModelIndex==
Identifies uniquely items in the model.
This acts as a "dumb token" that it's entirely model's task to understand/process it.

Properties:
* modelData : void *

==ItemDataRole==
This is an enum, that contains the types of data the model is requested to provide.

Enum members:
* Text
* ImageDecoration
* Tooltip
* <etc>
* UserDefined (used as a base for user-defined custom roles)

==ItemModel==
The model for the view, that provides data like items count to the view.
This is implemented by the developers that want to use this new architecture.

Structure-related methods:
* childrenCount(modelIndex)
* makeIndex(child, parentModelIndex)
* getParentIndex(modelIndex)

Data-provider methods:
* getData(modelIndex, role)

Events:
* ChildrenAdded - startIndex, count
* ChildrenRemoved - startIndex, count
* ChildrenDataChanged - startIndex, count

TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?

==ModelIndex Invalidation==
Views might (read: will) store indices for a faster rendering or operations on the view. But these indices might become invalid if:
* the underlying model instance changes (i.e.: model is set to another instance)
** Solution: Just invalidate the memorized indices
* an index from the "middle" is removed
** Solution1: Create persistent model indices, like Qt does.
*** Con: too much management required, prone to errors.
** Solution2: Query the model for validity
*** ''isValid'' will be moved to the ViewModel
** Solution3: Other?

=Affected widgets=
===Changed (to the new architecture) widgets===
* ComboBox + ComboDropList -> ComboView
* Tree -> TreeView
* ListBox -> ListView

===New widgets===
* GridView
* ListBoxWidget (combines model & view together for simple usage cases)

===Removed/deprecated widgets===
* MultiColumnList (replaced by GridView)
* ItemListbox (duplicated by ListBox)

===To decide===
* ItemListBase
** It's used in other places like: MenuBase and ScrolledItemListBase
** Remove the other usages as well?

=Workflow examples=
==List rendering==

* Create root model index (parent=0)
* Query the number of rows for root
* For each row (value=[0, rowCount))
** Create row model index (row=current row value, parent=rootModelIndex)
** Query the image to be displayed for row index
** Draw image
** Query the text to be displayed for row index
** Draw text
* Render non-row elements

==Tree rendering==
===Full/first-time rendering===
Triggered first time, or when whole model changes.

Recursive rendering procedure starting with a model index
* > Given a parent model index
* Query the number of children for index
* For each child (value=[0, childrenCount))
** Create child model index (parent=parentModelIndex)
** Query the image to be displayed for child index (Role=imageDecoration)
** Draw image
** Query the text to be displayed for child index (Role=Text)
** Draw text
** Call procedure with child model index.

Actual rendering:
* Call procedure defined above with root model index (parent = 0)
* Render non-row elements

===Item(s) modified/isolated rendering===
Triggered when some parts of the model changed, but not all.

NewModelViewArchitecture

2014-05-19T23:09:16Z

Timotei: add tree rendering workflow (part 1)

Homepage for the WIP Model-View architecture for CEGUI widgets!

=Introduction=
The new architecture aims to unify the underlying implementation of several widgets so that they will use a common base model provider. This will involve a lot of ABI and API breakage.

=Proposed architecture=
TODO
- decide on another concepts than row/column

==ModelIndex==
Identifies uniquely items in the model.

Properties:
* row : size_t
* column : size_t
* parent : ModelIndex *
* indexModelData : void *

Methods:
* isValid

==ItemModel==
The model for the view, that provides data like items count to the view. This is implemented by the developers that want to use this new architecture.

Structure-related methods:
* rowCount(modelIndex)
* columnCount(modelIndex)
* makeIndex(row, column, parentModelIndex)
* getParentIndex(modelIndex)

Data-provider methods:
* getString(modelIndex)
* getImage(modelIndex)

Events:
* Rows/ColumnsAdded - startIndex, count
* Rows/ColumnsRemoved - startIndex, count
* Rows/ColumnsDataChanged - startIndex, count

TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?

==ModelIndex Invalidation==
Views might (read: will) store indices for a faster rendering or operations on the view. But these indices might become invalid if:
* the underlying model instance changes (i.e.: model is set to another instance)
** Solution: Just invalidate the memorized indices
* an index from the "middle" is removed
** Solution1: Create persistent model indices, like Qt does.
*** Con: too much management required, prone to errors.
** Solution2: Query the model for validity
*** ''isValid'' will be moved to the ViewModel
** Solution3: Other?

=Affected widgets=
===Changed (to the new architecture) widgets===
* ComboBox + ComboDropList -> ComboView
* Tree -> TreeView
* ListBox -> ListView

===New widgets===
* GridView
* ListBoxWidget (combines model & view together for simple usage cases)

===Removed/deprecated widgets===
* MultiColumnList (replaced by GridView)
* ItemListbox (duplicated by ListBox)

===To decide===
* ItemListBase
** It's used in other places like: MenuBase and ScrolledItemListBase
** Remove the other usages as well?

=Workflow examples=
==List rendering==

* Create root model index (parent=0)
* Query the number of rows for root
* For each row (value=[0, rowCount))
** Create row model index (row=current row value, parent=rootModelIndex)
** Query the image to be displayed for row index
** Draw image
** Query the text to be displayed for row index
** Draw text
* Render non-row elements

==Tree rendering==
===Full/first-time rendering===
Triggered first time, or when whole model changes.

Recursive rendering procedure starting with a model index
* > Given a parent model index
* Query the number of rows for index
* For each row (value=[0, rowCount))
** Create row model index (row=current row value, parent=parent<odelIndex)
** Query the image to be displayed for row index
** Draw image
** Query the text to be displayed for row index
** Draw text
** Call procedure with row model index.

Actual rendering:
* Call procedure defined above with root model index (parent = 0)
* Render non-row elements

===Item(s) modified/isolated rendering===
Triggered when some parts of the model changed, but not all.

Talk:NewModelViewArchitecture

2014-05-19T17:18:39Z

Timotei: Created page with "Talk about NewModelViewArchitecture page."

Talk about NewModelViewArchitecture page.

NewModelViewArchitecture

2014-05-18T22:04:40Z

Timotei: /* ModelIndex */

NewModelViewArchitecture

2014-05-18T22:03:08Z

Timotei: /* List rendering */

NewModelViewArchitecture

2014-05-18T21:57:55Z

Timotei: add initial section for workflows

NewModelViewArchitecture

2014-05-18T21:30:29Z

Timotei: /* ViewModel */

NewModelViewArchitecture

2014-05-14T21:38:36Z

Timotei: ModelIndex invalidation problem statement + 2 solutions

NewModelViewArchitecture

2014-05-14T21:29:55Z

Timotei: ModelIndex and ViewModel details

NewModelViewArchitecture

2014-05-13T22:08:17Z

Timotei: rename to *View

NewModelViewArchitecture

2014-05-07T22:24:10Z

Timotei: first draft

NewModelViewArchitecture

2014-05-07T21:12:10Z

Timotei: initial commit.

Homepage for the WIP Model-View architecture for CEGUI widgets!

News Archive

2014-01-21T20:34:55Z

Timotei: Small date fix for mass import

=== CEGUI Version 0.8.2 released! by ''' [[User:Crazyeddie|Crazyeddie]] 12th June 2013 ===
See more details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6460 official announcement].

=== CEGUI Version 0.8.1 released! by ''' [[User:Crazyeddie|Crazyeddie]] 5th June 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6458 official announcement].

=== CEGUI Version 0.8.0 released! by ''' [[User:Crazyeddie|Crazyeddie]] 26th May 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6453 official announcement].

=== CEGUI Version 0.7.9 released! by ''' [[User:Crazyeddie|Crazyeddie]] 13th January 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6323 official announcement].

=== CEGUI Version 0.7.8 released! by ''' [[User:Crazyeddie|Crazyeddie]] 8th January 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6320 official announcement].

=== CEGUI Unified editor snapshot 11 release by ''' [[User:Kulik|Kulik]] 4th November 2012 ===
Unstable snapshot11 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6270 announcement thread]

=== CEGUI Unified editor snapshot 10 release by ''' [[User:Kulik|Kulik]] 28th July 2012 ===
Unstable snapshot10 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6175 announcement thread]

=== CEGUI Unified editor snapshot 9 release by ''' [[User:Kulik|Kulik]] 15th July 2012 ===
Unstable snapshot9 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6159 announcement thread]

=== CEGUI Version 0.7.7 released! by ''' [[User:Crazyeddie|Crazyeddie]] 23rd June 2012 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6141 official announcement].

=== CEGUI Unified editor snapshot 8 release by ''' [[User:Kulik|Kulik]] 10th June 2012 ===
Unstable snapshot8 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6128 announcement thread]

=== CEGUI Unified editor snapshot 7 release by ''' [[User:Kulik|Kulik]] 22nd April 2012 ===
Unstable snapshot7 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6089 announcement thread]

=== CEGUI is participating in Google Summer of Code 2012! by ''' [[User:Kulik|Kulik]] 19th March 2012 ===
Read more details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=10&t=6032 official announcement].

=== CEGUI Version 0.7.6 released! by ''' [[User:Crazyeddie|Crazyeddie]] 22nd January 2012 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5978 official announcement].

=== CEGUI Unified editor snapshot 6 release by ''' [[User:Kulik|Kulik]] 9th January 2012 ===
Unstable snapshot6 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5965 announcement thread]

=== CEGUI Unified editor snapshot 5 release by ''' [[User:Kulik|Kulik]] 29th November 2011 ===
Unstable snapshot5 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5905 announcement thread]

=== CEGUI Unified editor snapshot 4 release by ''' [[User:Kulik|Kulik]] 31th August 2011 ===
Unstable snapshot4 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5799 announcement thread]

=== CEGUI Unified editor snapshot 3 release by ''' [[User:Kulik|Kulik]] 31th July 2011 ===
Unstable snapshot3 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5750 announcement thread]

=== CEGUI Unified editor snapshot 2 release by ''' [[User:Kulik|Kulik]] 6th June 2011 ===
Unstable snapshot2 preview release, capable of imageset editing and some layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5640 announcement thread]

=== First public CEGUI Unified editor release by ''' [[User:Kulik|Kulik]] 1th May 2011 ===
Unstable snapshot preview release, capable of imageset editing and some layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5565 announcement thread]

=== Wiki has undertaken major changes! by ''' [[User:Kulik|Kulik]] 6th March 2011 ===
The amount of maintenance work has been lowered and the overall usefulness of the wiki has (hopefully) been much increased.
More details in this [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=1&t=5449 forum thread].

=== CEGUI Version 0.7.5 released! by ''' [[User:Crazyeddie|Crazyeddie]] 20th November 2010 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5280 official announcement].

=== CEGUI Version 0.7.4 released! by ''' [[User:Crazyeddie|Crazyeddie]] 11th October 2010 ===
Emergency fix for 0.7.3 release! [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5182 official announcement].

=== CEGUI Version 0.7.3 released! by ''' [[User:Crazyeddie|Crazyeddie]] 8th October 2010 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5182 official announcement].

=== CEGUI Version 0.7.2 released! by ''' [[User:Crazyeddie|Crazyeddie]] 29th August 2010 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5096 official announcement].

=== CELayoutEditor 0.7.1 released for Windows! by ''' [[User:scriptkid|scriptkid]] 1th January 2010 ===
See the [[CELayoutEditor Downloads 0.7.1]] page for the link.

=== "Pirate Princess" (game) released! by ''' [[User:scriptkid|scriptkid]] 25th November 2009 ===
Pirate Princess is a semi-casual word game based adventure, just finished and on sale. Of course it uses CEGUI (a lot!). Check out the website:
[http://www.moonpod.com/English/about_pirateprincess.php Pirate Princess - A word game based adventure!].

=== CEGUI 0.7.1 is Released! by ''' [[User:scriptkid|scriptkid]] 26th October 2009 ===
See the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=4443 details here]

=== "Cube Combat" (game) released! by ''' [[User:scriptkid|scriptkid]] 20th October 2009 ===
Cube Combat is a bomberman remake game, which uses CEGUI. It looks & feels nice and polished. Check out the website:
[http://www.cubecombat.net Cube Combat - A 3D bomberman remake!].

=== CEGUI 0.7.0 is Released! by ''' [[User:CrazyEddie|CrazyEddie]] 20th September 2009 ===
See the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=4340 details here]

=== CEGUI 0.6.3 release of the Layout Editor! by ''' [[User:scriptkid|scriptkid]] 9th June 2009 ===

=== "Snakeworlds" (game) released! by ''' [[User:scriptkid|scriptkid]] 3rd April 2009 ===
Snakeworlds is a snake remake game, which uses CEGUI. Check out the website:
[http://www.snakeworldsgame.com Snakeworlds - A spherical snake game!].

=== CEGUI 0.6.2 Released! by ''' [[User:CrazyEddie|CrazyEddie]] 3rd December 2008 ===

Read the [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=3712/ buzz]

=== New 0.6.x in-progress LayoutEditor! by ''' [[User:scriptkid|scriptkid]] 2th August 2008 ===

See the [[CELayoutEditor Downloads 0.6.x]] page for the link (bottom of the page!).

=== New 0.6.x in-progress LayoutEditor! by ''' [[User:scriptkid|scriptkid]] 7th May 2008 ===

See the [[CELayoutEditor Downloads 0.6.0]] page for the link (bottom of the page!).

=== New 0.6.0 Release of CEGUI and tools! by ''' [[User:The CEGUI Development Team|The CEGUI Development Team]] 27th March 2008 ===
The Crazy Eddie's GUI System project (crayzedsgui on sourceforge.net) is pleased to announce the release of version 0.6.0 of the Crazy Eddie's GUI System library and associated CELayoutEditor and CEImagesetEditor tools.

Founded in 2003, Crazy Eddie's GUI System has consistently been one of the favourite choices for the serious game or multimedia developer needing a mature, stable and flexible rendered GUI solution. The library is open source, highly configurable and offers virtually unrivalled skinning opportunities via its "Falagard" XML skinning system. Crazy Eddie's GUI System library is released under the MIT license, thus offering the ultimate flexibility for all usage scenarios.

The 0.6.0 release comes some 16 months after the previous release, and marks the official return of Paul D Turner (CrazyEddie) as project leader and as a permanent member on the development team.

For more information about Crazy Eddie's GUI System see the project website at http://www.cegui.org.uk. Support requests for the library and associated tools, in the first instance, should be directed at the Crazy Eddie's GUI System project forums at http://forums.cegui.org.uk.

You can get the files at the [[Downloads|CEGUI Downloads page]].

See also this forum thread: http://www.cegui.org.uk/phpBB2/viewtopic.php?p=13973

=== New MSVC++ 9 binary packages for CEGUI and [[SILLY]] by ''' [[User:CrazyEddie|CrazyEddie]] 3rd February 2008 ===
We have released binary dependency packages and pre-built SDK packages for both [[SILLY]] 0.1.0 and CEGUI 0.5.0b for use with Microsoft's Visual C++ 9 (2008 edition) compiler.

See the [[Downloads]] page and the announcement on the [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2965 forums] for additional information.

=== New CELayoutEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 18th December 2007 ===
A new update that adds new features to the property grid, improves exception handling, adds version information and more misc stuff has been committed to the CELayoutEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2825/ forum entry].

=== New CEImagesetEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 10th December 2007 ===
A new update that adds VS2003 & VS2005 solutions and modifies configuration settings has been
committed to the CEImagesetEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2822/ forum entry].

=== New CELayoutEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 06th December 2007 ===
A new update that adds Vectored Exception Handling (VEH) support, stack trace info to all thrown exceptions and
other misc stuff has been committed to the CELayoutEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2821/ forum entry].

=== New Widget: GroupBox ''' [[User:Scriptkid|Scriptkid]] 02th December 2007 ===
A new update adds Levia's GroupBox to the trunk. Thanks to Levia!

=== New CEGUI SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 30th November 2007 ===
A new update that adds RTTI info to debug builds and performs some logger modifications has been committed to the CEGUI SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2816/ forum entry].

=== New CELayoutEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 22th November 2007 ===
A new update that includes important bug fixes and internal changes that increase performance and code quality has been committed to the CELayoutEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2811/ forum entry].

=== New CEGUI SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 10th November 2007 ===
A new update that adds type, file name and line number to all thrown exceptions has been committed to the CEGUI SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2799/ forum entry].

=== New developments by ''' [[User:Scriptkid|Scriptkid]] 06th November 2007 ===
Starting a few weeks ago, new development is being done on CEGUI, mainly on its tools. User [[User:fjeronimo|fjeronimo]] has made some valuable modifications already. Besides that, we are moving through the Mantis list and verifying+fixing bugs. We will keep you up-to-date regarding these matters.

=== Release of 0.5.0b source packages by [[User:CrazyEddie|CrazyEddie]] 28th November 2006 ===
We have issued new versions of the 0.5.0 source packages - the previous ones were missing the files for the Microsoft Direct3D based renderer modules, the packages contain no other changes Thanks go to dmail for raising this issue.

=== Release of 0.5.0b binary packages for Win32 by [[User:CrazyEddie|CrazyEddie]] 14th November 2006 ===
The Win32 binary dependency and SDK packages released on the 6th contained an inconsistency related to the [[SILLY]] library. Today I have issued a new set of binary packages which have been fixed - the new version is known as 0.5.0b, and contains no other changes. Many thanks to forum member vasmann for alerting me to the issue.

=== Release of 0.5.0 stable by [[User:CrazyEddie|CrazyEddie]] 6th November 2006 ===
It has been almost a year in the making, but it is finally here! The CEGUI development team is immensely proud to announce the release of Crazy Eddie's GUI System 0.5.0 - the first stable release of code in the 0.5.x series.

There are pretty vast changes in this release from the previous stable (0.4.1) - many of these changes are breaking, so please agian review [[Changes and Porting Tips for 0.5.0|Release Notes 0.5.X]] to see details of most of these changes.

This release consists of various files that you may need, depending on your usage of the system. We are providing source packages, documentation packages, dependency packages, and binary SDK packages (for VC7.1 and VC8).

To coincide with this release, we are also happy to announce a stable 0.1.0 release of Simple Image Loading LibrarY (SILLY), and the 0.5.0 release of the CELayoutEditor. Please see the [[Downloads|downloads page]] for full details.

=== CEGUI 0.5.0 Release Candidate 2 by [[User:Dalfy|Dalfy]] 13rd august 2006 ===
We are pleased to announce the second release candidate of the 0.5 branches of CEGUI. There has been a lot of changes between 0.4.1 and 0.5.0. They are listed in [[Changes and Porting Tips for 0.5.0|Release Notes 0.5.X]]. Please have a try at it and help us get a final release soon. Check the download page.

=== CEGUI 0.5.0 Release Candidate 1 by [[User:Dalfy|Dalfy]] 20th June 2006 ===
We are pleased to announce the first release candidate of the 0.5 branches of CEGUI. There has been a lot of changes between 0.4.1 and 0.5.0. They are listed in [[Changes and Porting Tips for 0.5.0|Release Notes 0.5.X]]. Please have a try at it and help us get a final release soon by sending a lot of bug report in Mantis bug tracker. The download page for CEGUI-0.5.0-RC1 contains some typos but most link are already valid and mirrored on sourceforge. The link on the download page are going to be fixed during the day.

For any question regarding this release you can use either the forum either irc.

=== Migration to Subversion by [[User:CrazyEddie|CrazyEddie]] 3rd April 2006 ===
We have taken the decision to migrate the code for main CEGUI Mk-2 library and the CELayoutEditor tool from using the CVS revision control system, over to Subversion (SVN). If you're using the stable releases, this will not affect you at all. If you're using code out of some branch of CVS, then you will need to switch to SVN instead - we will not be maintaining both repositories. You will find that for general usage, CVS and SVN are similar, and have similar commands. For Windows users, we heartily recommend the use of [http://tortoisesvn.tigris.org/ TortoiseSVN].

For full details of how to obtain the source code from the subversion repository, please see the page [[Obtaining the library source from Subversion|HOWTO: Obtain the library source from subversion]]

All 'ceguiaddons' projects will continue to use CVS for revision control.

=== Site Moved (again) ===
We have now moved the site back to the sourceforge servers, and made a few changes as to the way the site is handled in general - as you have probably noticed!

Basically the main 'content' areas of the site are now entirely wiki based, and we also have a few other bits installed to handle certain requirements where the wiki is less suited to the task.

The features of the new site are:
* Wiki based system for all main site content
* phpBB2 being used for community forums
* Coppermine based gallery
* Mantis for all bug and feature tracking
* Single, unified, log-in for all site areas

News Archive

2014-01-19T13:40:38Z

Timotei: Small fix for mass import

=== CEGUI Version 0.8.2 released! by ''' [[User:Crazyeddie|Crazyeddie]] 12th June 2013 ===
See more details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6460 official announcement].

=== CEGUI Version 0.8.1 released! by ''' [[User:Crazyeddie|Crazyeddie]] 5th June 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6458 official announcement].

=== CEGUI Version 0.8.0 released! by ''' [[User:Crazyeddie|Crazyeddie]] 26th May 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6453 official announcement].

=== CEGUI Version 0.7.9 released! by ''' [[User:Crazyeddie|Crazyeddie]] 13th January 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6323 official announcement].

=== CEGUI Version 0.7.8 released! by ''' [[User:Crazyeddie|Crazyeddie]] 8th January 2013 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6320 official announcement].

=== CEGUI Unified editor snapshot 11 release by ''' [[User:Kulik|Kulik]] 4th November 2012 ===
Unstable snapshot11 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6270 announcement thread]

=== CEGUI Unified editor snapshot 10 release by ''' [[User:Kulik|Kulik]] 28th July 2012 ===
Unstable snapshot10 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6175 announcement thread]

=== CEGUI Unified editor snapshot 9 release by ''' [[User:Kulik|Kulik]] 15th July 2012 ===
Unstable snapshot9 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6159 announcement thread]

=== CEGUI Version 0.7.7 released! by ''' [[User:Crazyeddie|Crazyeddie]] 23rd June 2012 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=6141 official announcement].

=== CEGUI Unified editor snapshot 8 release by ''' [[User:Kulik|Kulik]] 10th June 2012 ===
Unstable snapshot8 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6128 announcement thread]

=== CEGUI Unified editor snapshot 7 release by ''' [[User:Kulik|Kulik]] 22nd April 2012 ===
Unstable snapshot7 preview release, capable of imageset editing, layout editing and some animation editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=6089 announcement thread]

=== CEGUI is participating in Google Summer of Code 2012! by ''' [[User:Kulik|Kulik]] 19th March 2012 ===
Read more details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=10&t=6032 official announcement].

=== CEGUI Version 0.7.6 released! by ''' [[User:Crazyeddie|Crazyeddie]] 22nd January 2012 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5978 official announcement].

=== CEGUI Unified editor snapshot 6 release by ''' [[User:Kulik|Kulik]] 9th January 2012 ===
Unstable snapshot6 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5965 announcement thread]

=== CEGUI Unified editor snapshot 5 release by ''' [[User:Kulik|Kulik]] 29th November 2011 ===
Unstable snapshot5 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5905 announcement thread]

=== CEGUI Unified editor snapshot 4 release by ''' [[User:Kulik|Kulik]] 31th August 2011 ===
Unstable snapshot4 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5799 announcement thread]

=== CEGUI Unified editor snapshot 3 release by ''' [[User:Kulik|Kulik]] 31th July 2011 ===
Unstable snapshot3 preview release, capable of imageset editing and layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5750 announcement thread]

=== CEGUI Unified editor snapshot 2 release by ''' [[User:Kulik|Kulik]] 6th June 2011 ===
Unstable snapshot2 preview release, capable of imageset editing and some layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5640 announcement thread]

=== First public CEGUI Unified editor release by ''' [[User:Kulik|Kulik]] 1th May 2011 ===
Unstable snapshot preview release, capable of imageset editing and some layout editing - read more in the [http://cegui.org.uk/phpBB2/viewtopic.php?f=15&t=5565 announcement thread]

=== Wiki has undertaken major changes! by ''' [[User:Kulik|Kulik]] 6th March 2011 ===
The amount of maintenance work has been lowered and the overall usefulness of the wiki has (hopefully) been much increased.
More details in this [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=1&t=5449 forum thread].

=== CEGUI Version 0.7.5 released! by ''' [[User:Crazyeddie|Crazyeddie]] 20th November 2010 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5280 official announcement].

=== CEGUI Version 0.7.4 released! by ''' [[User:Crazyeddie|Crazyeddie]] 11th October 2010 ===
Emergency fix for 0.7.3 release! [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5182 official announcement].

=== CEGUI Version 0.7.3 released! by ''' [[User:Crazyeddie|Crazyeddie]] 8th October 2010 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5182 official announcement].

=== CEGUI Version 0.7.2 released! by ''' [[User:Crazyeddie|Crazyeddie]] 29th August 2010 ===
Read all the details in the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=5096 official announcement].

=== CELayoutEditor 0.7.1 released for Windows! by ''' [[User:scriptkid|scriptkid]] 1th January 2010 ===
See the [[CELayoutEditor Downloads 0.7.1]] page for the link.

=== "Pirate Princess" (game) released! by ''' [[User:scriptkid|scriptkid]] 25th November 2009 ===
Pirate Princess is a semi-casual word game based adventure, just finished and on sale. Of course it uses CEGUI (a lot!). Check out the website:
[http://www.moonpod.com/English/about_pirateprincess.php Pirate Princess - A word game based adventure!].

=== CEGUI 0.7.1 is Released! by ''' [[User:scriptkid|scriptkid]] 26th October 2009 ===
See the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=4443 details here]

=== "Cube Combat" (game) released! by ''' [[User:scriptkid|scriptkid]] 20th October 2009 ===
Cube Combat is a bomberman remake game, which uses CEGUI. It looks & feels nice and polished. Check out the website:
[http://www.cubecombat.net Cube Combat - A 3D bomberman remake!].

=== CEGUI 0.7.0 is Released! by ''' [[User:CrazyEddie|CrazyEddie]] 20th September 2009 ===
See the [http://www.cegui.org.uk/phpBB2/viewtopic.php?f=6&t=4340 details here]

=== CEGUI 0.6.3 release of the Layout Editor! by ''' [[User:scriptkid|scriptkid]] 9th June 2009 ===

=== "Snakeworlds" (game) released! by ''' [[User:scriptkid|scriptkid]] 3rd April 2009 ===
Snakeworlds is a snake remake game, which uses CEGUI. Check out the website:
[http://www.snakeworldsgame.com Snakeworlds - A spherical snake game!].

=== CEGUI 0.6.2 Released! by ''' [[User:CrazyEddie|CrazyEddie]] 3rd December 2008 ===

Read the [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=3712/ buzz]

=== New 0.6.x in-progress LayoutEditor! by ''' [[User:scriptkid|scriptkid]] 2th August 2008 ===

See the [[CELayoutEditor Downloads 0.6.x]] page for the link (bottom of the page!).

=== New 0.6.x in-progress LayoutEditor! by ''' [[User:scriptkid|scriptkid]] 7th May 2008 ===

See the [[CELayoutEditor Downloads 0.6.0]] page for the link (bottom of the page!).

=== New 0.6.0 Release of CEGUI and tools! by ''' [[User:The CEGUI Development Team|The CEGUI Development Team]] 27th March 2008 ===
The Crazy Eddie's GUI System project (crayzedsgui on sourceforge.net) is pleased to announce the release of version 0.6.0 of the Crazy Eddie's GUI System library and associated CELayoutEditor and CEImagesetEditor tools.

Founded in 2003, Crazy Eddie's GUI System has consistently been one of the favourite choices for the serious game or multimedia developer needing a mature, stable and flexible rendered GUI solution. The library is open source, highly configurable and offers virtually unrivalled skinning opportunities via its "Falagard" XML skinning system. Crazy Eddie's GUI System library is released under the MIT license, thus offering the ultimate flexibility for all usage scenarios.

The 0.6.0 release comes some 16 months after the previous release, and marks the official return of Paul D Turner (CrazyEddie) as project leader and as a permanent member on the development team.

For more information about Crazy Eddie's GUI System see the project website at http://www.cegui.org.uk. Support requests for the library and associated tools, in the first instance, should be directed at the Crazy Eddie's GUI System project forums at http://forums.cegui.org.uk.

You can get the files at the [[Downloads|CEGUI Downloads page]].

See also this forum thread: http://www.cegui.org.uk/phpBB2/viewtopic.php?p=13973

=== New MSVC++ 9 binary packages for CEGUI and [[SILLY]] by ''' [[User:CrazyEddie|CrazyEddie]] 3rd February 2008 ===
We have released binary dependency packages and pre-built SDK packages for both [[SILLY]] 0.1.0 and CEGUI 0.5.0b for use with Microsoft's Visual C++ 9 (2008 edition) compiler.

See the [[Downloads]] page and the announcement on the [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2965 forums] for additional information.

=== New CELayoutEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 18th December 2007 ===
A new update that adds new features to the property grid, improves exception handling, adds version information and more misc stuff has been committed to the CELayoutEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2825/ forum entry].

=== New CEImagesetEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 10th December 2007 ===
A new update that adds VS2003 & VS2005 solutions and modifies configuration settings has been
committed to the CEImagesetEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2822/ forum entry].

=== New CELayoutEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 06th December 2007 ===
A new update that adds Vectored Exception Handling (VEH) support, stack trace info to all thrown exceptions and
other misc stuff has been committed to the CELayoutEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2821/ forum entry].

=== New Widget: GroupBox ''' [[User:Scriptkid|Scriptkid]] 02th December 2007 ===
A new update adds Levia's GroupBox to the trunk. Thanks to Levia!

=== New CEGUI SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 30th November 2007 ===
A new update that adds RTTI info to debug builds and performs some logger modifications has been committed to the CEGUI SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2816/ forum entry].

=== New CELayoutEditor SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 22th November 2007 ===
A new update that includes important bug fixes and internal changes that increase performance and code quality has been committed to the CELayoutEditor SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2811/ forum entry].

=== New CEGUI SVN trunk update by ''' [[User:fjeronimo|fjeronimo]] 10th November 2007 ===
A new update that adds type, file name and line number to all thrown exceptions has been committed to the CEGUI SVN trunk.

More details can be found in the following [http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2799/ forum entry].

=== New developments by ''' [[User:Scriptkid|Scriptkid]] 06th November 2007 ===
Starting a few weeks ago, new development is being done on CEGUI, mainly on its tools. User [[User:fjeronimo|fjeronimo]] has made some valuable modifications already. Besides that, we are moving through the Mantis list and verifying+fixing bugs. We will keep you up-to-date regarding these matters.

=== Release of 0.5.0b source packages by [[User:CrazyEddie|CrazyEddie]] 28th November 2006 ===
We have issued new versions of the 0.5.0 source packages - the previous ones were missing the files for the Microsoft Direct3D based renderer modules, the packages contain no other changes Thanks go to dmail for raising this issue.

=== Release of 0.5.0b binary packages for Win32 by [[User:CrazyEddie|CrazyEddie]] 14th November 2006 ===
The Win32 binary dependency and SDK packages released on the 6th contained an inconsistency related to the [[SILLY]] library. Today I have issued a new set of binary packages which have been fixed - the new version is known as 0.5.0b, and contains no other changes. Many thanks to forum member vasmann for alerting me to the issue.

=== Release of 0.5.0 stable by [[User:CrazyEddie|CrazyEddie]] 6th November 2006 ===
It has been almost a year in the making, but it is finally here! The CEGUI development team is immensely proud to announce the release of Crazy Eddie's GUI System 0.5.0 - the first stable release of code in the 0.5.x series.

There are pretty vast changes in this release from the previous stable (0.4.1) - many of these changes are breaking, so please agian review [[Changes and Porting Tips for 0.5.0|Release Notes 0.5.X]] to see details of most of these changes.

This release consists of various files that you may need, depending on your usage of the system. We are providing source packages, documentation packages, dependency packages, and binary SDK packages (for VC7.1 and VC8).

To coincide with this release, we are also happy to announce a stable 0.1.0 release of Simple Image Loading LibrarY (SILLY), and the 0.5.0 release of the CELayoutEditor. Please see the [[Downloads|downloads page]] for full details.

=== CEGUI 0.5.0 Release Candidate 2 by [[User:Dalfy|Dalfy]] 13 august 2006 ===
We are pleased to announce the second release candidate of the 0.5 branches of CEGUI. There has been a lot of changes between 0.4.1 and 0.5.0. They are listed in [[Changes and Porting Tips for 0.5.0|Release Notes 0.5.X]]. Please have a try at it and help us get a final release soon. Check the download page.

=== CEGUI 0.5.0 Release Candidate 1 by [[User:Dalfy|Dalfy]] 20 June 2006 ===
We are pleased to announce the first release candidate of the 0.5 branches of CEGUI. There has been a lot of changes between 0.4.1 and 0.5.0. They are listed in [[Changes and Porting Tips for 0.5.0|Release Notes 0.5.X]]. Please have a try at it and help us get a final release soon by sending a lot of bug report in Mantis bug tracker. The download page for CEGUI-0.5.0-RC1 contains some typos but most link are already valid and mirrored on sourceforge. The link on the download page are going to be fixed during the day.

For any question regarding this release you can use either the forum either irc.

=== Migration to Subversion by [[User:CrazyEddie|CrazyEddie]] 11:13, 3 April 2006 (PDT) ===
We have taken the decision to migrate the code for main CEGUI Mk-2 library and the CELayoutEditor tool from using the CVS revision control system, over to Subversion (SVN). If you're using the stable releases, this will not affect you at all. If you're using code out of some branch of CVS, then you will need to switch to SVN instead - we will not be maintaining both repositories. You will find that for general usage, CVS and SVN are similar, and have similar commands. For Windows users, we heartily recommend the use of [http://tortoisesvn.tigris.org/ TortoiseSVN].

For full details of how to obtain the source code from the subversion repository, please see the page [[Obtaining the library source from Subversion|HOWTO: Obtain the library source from subversion]]

All 'ceguiaddons' projects will continue to use CVS for revision control.

=== Site Moved (again) ===
We have now moved the site back to the sourceforge servers, and made a few changes as to the way the site is handled in general - as you have probably noticed!

Basically the main 'content' areas of the site are now entirely wiki based, and we also have a few other bits installed to handle certain requirements where the wiki is less suited to the task.

The features of the new site are:
* Wiki based system for all main site content
* phpBB2 being used for community forums
* Coppermine based gallery
* Mantis for all bug and feature tracking
* Single, unified, log-in for all site areas

The Zandalar project

2013-07-19T21:02:02Z

Timotei: /* Semantics Table */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
* Payload:
** float[2]
** PointerSource enum member
*** PS_Left
*** PS_Middle
*** PS_Right
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
* injectMouseWheelChange
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseMove + injectMousePosition
* PointerMove
injectMouseButtonDown
* PointerHold (PointerSource)
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL + CLICK)
injectMouseButtonUp
* PointerActivate (PointerSource)
injectMouseButtonClick
* PointerActivate (PointerSource)
injectMouseButtonDoubleClick
* SelectWord (double click)
injectMouseButtonTripleClick
* SelectAll (triple click)
<strike>'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'</strike>: YES

<strike>'''Question2:''' What we do with the right/middle/extra mouse buttons (TabControl uses middle and nobutton buttons)?:
* Introduce the idea of 'PointerSource' which can be left/right/middle
* Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)</strike>: We go for 'PointerSource' enum in the Semantic Event payload.

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* GoToPreviousCharacter (left arrow)
* GoToPreviousWord (CTRL + left arrow)
* GoToNextCharacter (right arrow)
* GoToNextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)
* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)

injectMouseWheelChange
* VerticalScroll
* HorizontalScroll

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-19T09:18:33Z

Timotei: /* Proposed design */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
* Payload:
** float[2]
** PointerSource enum member
*** PS_Left
*** PS_Middle
*** PS_Right
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
* injectMouseWheelChange
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseMove + injectMousePosition
* PointerMove
injectMouseButtonDown + injectMouseButtonUp
* PointerActivate (PointerSource)
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL+CLICK)
injectMouseButtonClick
* PointerActivate
injectMouseButtonDoubleClick
* PointerActivate
* SelectWord (double click)
injectMouseButtonTripleClick
* PointerActivate
* SelectAll (triple click)
<strike>'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'</strike>: YES

<strike>'''Question2:''' What we do with the right/middle/extra mouse buttons (TabControl uses middle and nobutton buttons)?:
* Introduce the idea of 'PointerSource' which can be left/right/middle
* Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)</strike>: We go for 'PointerSource' enum in the Semantic Event payload.

injectMouseButtonUp
* PointerDeactivate

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* GoToPreviousCharacter (left arrow)
* GoToPreviousWord (CTRL + left arrow)
* GoToNextCharacter (right arrow)
* GoToNextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)
* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)

injectMouseWheelChange
* VerticalScroll
* HorizontalScroll

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-18T21:04:48Z

Timotei: /* Semantics Table */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| PointerMovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
* Payload: float (for now)
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
* injectMouseWheelChange
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseButtonDown + injectMouseButtonUp
* PointerActivate
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL+CLICK)
injectMouseButtonClick
* PointerActivate
injectMouseButtonDoubleClick
* PointerActivate
* SelectWord (double click)
injectMouseButtonTripleClick
* PointerActivate
* SelectAll (triple click)
'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'

'''Question2:''' What we do with the right/middle/extra mouse buttons (TabControl uses middle and nobutton buttons)?:
* Introduce the idea of 'PointerSource' which can be left/right/middle
* Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)

injectMouseButtonUp
* PointerDeactivate

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* GoToPreviousCharacter (left arrow)
* GoToPreviousWord (CTRL + left arrow)
* GoToNextCharacter (right arrow)
* GoToNextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)
* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)

injectMouseWheelChange
* VerticalScroll
* HorizontalScroll

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-18T20:43:18Z

Timotei: /* Proposed design */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| PointerMovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
* Payload: float (for now)
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
* injectMouseWheelChange
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseButtonDown + injectMouseButtonUp
* PointerActivate
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL+CLICK)
injectMouseButtonClick
* PointerActivate
injectMouseButtonDoubleClick
* PointerActivate
* SelectWord (double click)
injectMouseButtonTripleClick
* PointerActivate
* SelectAll (triple click)
'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'

'''Question2:''' What we do with the right/middle/extra mouse buttons (TabControl uses middle and nobutton buttons)?:
* Introduce the idea of 'PointerSource' which can be left/right/middle
* Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)

injectMouseButtonUp
* PointerDeactivate

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* GoToPreviousCharacter (left arrow)
* GoToPreviousWord (CTRL + left arrow)
* GoToNextCharacter (right arrow)
* GoToNextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)

injectMouseWheelChange
* VerticalScroll
* HorizontalScroll

* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-16T21:04:51Z

Timotei: /* Semantics Table */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| PointerMovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
| ScrollInputEvent ||
* Delta : int
* Direction : ScrollDirection(0 - horizontal, 1 - vertical)
||
* injectMouseWheelChange
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseButtonDown + injectMouseButtonUp
* PointerActivate
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL+CLICK)
injectMouseButtonClick
* PointerActivate
injectMouseButtonDoubleClick
* PointerActivate
* SelectWord (double click)
injectMouseButtonTripleClick
* PointerActivate
* SelectAll (triple click)
'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'

'''Question2:''' What we do with the right/middle/extra mouse buttons (TabControl uses middle and nobutton buttons)?:
* Introduce the idea of 'PointerSource' which can be left/right/middle
* Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)

injectMouseButtonUp
* PointerDeactivate

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* GoToPreviousCharacter (left arrow)
* GoToPreviousWord (CTRL + left arrow)
* GoToNextCharacter (right arrow)
* GoToNextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)

* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-16T16:43:56Z

Timotei: /* Semantics Table */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| PointerMovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
| ScrollInputEvent ||
* Delta : int
* Direction : ScrollDirection(0 - horizontal, 1 - vertical)
||
* injectMouseWheelChange
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseButtonDown + injectMouseButtonUp
* PointerActivation
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL+CLICK)
injectMouseButtonClick
* PointerActivation
injectMouseButtonDoubleClick
* PointerActivation
* SelectWord (double click)
injectMouseButtonTripleClick
* PointerActivation
* SelectAll (triple click)
'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'

'''Question2:''' What we do with the right/middle/extra mouse buttons (TabControl uses middle and nobutton buttons)?:
* Introduce the idea of 'PointerSource' which can be left/right/middle
* Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)

injectMouseButtonUp
* PointerDeactivation

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* PreviousCharacter (left arrow)
* PreviousWord (CTRL + left arrow)
* NextCharacter (right arrow)
* NextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)

* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-16T16:42:13Z

Timotei: Add semantic input events

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key *** || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm) **** (check the semantics table)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| PointerMovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| SemanticInputEvent ||
* Value: Enum/int (see below table)
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
| ScrollInputEvent ||
* Delta : int
* Direction : ScrollDirection(0 - horizontal, 1 - vertical)
||
* injectMouseWheelChange
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values (members of an ENUM) and the raw event(s) from which they are generated.

injectMouseButtonDown + injectMouseButtonUp
* PointerActivation
* SelectMultipleItems (SHIFT + click)
* SelectCumulative (CTRL+CLICK)
injectMouseButtonClick
* PointerActivation
injectMouseButtonDoubleClick
* PointerActivation
* SelectWord (double click)
injectMouseButtonTripleClick
* PointerActivation
* SelectAll (triple click)
'''Question:''' Maybe we should create a standalone event type for pointer activation which also 'records' the number of activations? (for example in the case of double/triple click). The editbox uses double/triple click to select all text. Maybe let semantic action 'select all?'

'''Question2:''' What we do with the right/middle/extra mouse buttons? -- TabControl uses middle and nobutton buttons.

** Introduce the idea of 'PointerSource' which can be left/right/middle
** Add separate values: LeftPointerActivation, RightPointerActivation, etc? (I'd go for this)

injectMouseButtonUp
* PointerDeactivation

injectKeyDown + injectKeyUp
* DeleteLastCharacter (backspace)
* DeletePreviousCharacter (del)
* Confirm/Submit (Enter/tab/numpad enter -> This should go into the GUI navigation module)
* SelectLeftCharacter (SHIFT + left arrow)
* SelectRightCharacter (SHIFT + right arrow)
* PreviousCharacter (left arrow)
* PreviousWord (CTRL + left arrow)
* NextCharacter (right arrow)
* NextWord (CTRL + right arrow)
* GoToStartOfLine (home)
* GoToEndOfLine (end)
* SelectAll (CTRL+A)
* Back (escape)

* Undo (CTRL+Z)
* Redo (CTRL+Y)
* Cut (CTRL+X)
* Copy (CTRL+C)
* Paste (CTRL+V)
== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-15T21:59:13Z

Timotei: Some reorganisation

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || PointerMovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PointerActivationInputEvent
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || PointerDeactivationInputEvent
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || SemanticInputEvent(Confirm)
|-
| Release the ENTER key || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Confirm)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press backspace (delete last char) || Key Button press || injectKeyDown(key) || SemanticInputEvent(DeleteLastCharacter)
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| PointerMovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| SemanticInputEvent ||
* Value: Enum + int (see below table)
||
* injectMouseButtonDown
* injectKeyDown
* injectMouseButtonUp
* injectKeyUp
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
| ScrollInputEvent ||
* Delta : int
* Direction : ScrollDirection(0 - horizontal, 1 - vertical)
||
* injectMouseWheelChange
|}

Unmapped (yet) functions:
* injectMouseLeaves

=== Semantics Table ===
The following table represents the semantic values and the raw event(s) from which they are generated

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have three ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.
* Using just SemanticInputEvent WITHOUT raw events.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-15T10:44:00Z

Timotei: /* Proposed design */

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || MovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PressedButtonInputEvent(Mouse_LMB)
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || ReleasedButtonInputEvent(Mouse_LMB)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || PressedButtonInputEvent(Keyb_Enter)
|-
| Release the ENTER key || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Keyb_Enter)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press a non-character key || Key Button press || injectKeyDown(key) || PressedButtonInputEvent(Keyb_key)
|-
| Release a non-character key || Key Button release || injectKeyUp(key) || ReleasedButtonInputEvent(Keyb_key
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| MovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| PressedButtonInputEvent@@@ ||
* Button : Buttons Enum/integer or long for maximum flexibility
||
* injectMouseButtonDown
* injectKeyDown
|-
| ReleasedButtonInputEvent@@@ ||
* Button : Buttons Enum/integer or long for maximum flexibility
||
* injectMouseButtonUp
* injectKeyUp
|-
| ActivatedInputEvent or SemanticInputEvent@@@ ||
* Count (1+) : int
* Semantic value : int (can come from an enum)
||
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
| ScrollInputEvent ||
* Delta : int
* Direction : ScrollDirection(0 - horizontal, 1 - vertical)
||
* injectMouseWheelChange
|}

Unmapped (yet) functions:
* injectMouseLeaves

@@@ subject to the next section, Decisions.

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have two ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-15T10:43:16Z

Timotei: Add decision section for button press

The Zandalar Project is a codename for the new Input archtecture and GUI navigation features.

= Input Aggregator & events =
== Use Cases ==
The use cases are described by steps. For each step there might be some actions done at different levels:
* Raw input = the data that comes directly from the input system the application is using (OIS, glfw, etc.).
* Input Injection = the `InjectedInputReceiver`-ish function called with the right parameters
** For backwards compatibility-ish, we can persist the same interface(InjectedInputReceiver), but provide in it a default implementation that generates the input events for the current interface's functions.
* InputEvent = the `InputEvent` type generated from the injected input. This is the final step, and this is fed to the CEGUI library.

=== Clicking a button using a mouse ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Move the mouse over the button || Mouse movement || injectMouseMove/injectMousePosition || MovementInputEvent
|-
| Press the LMB || Mouse button press || injectMouseButtonDown(LMB) || PressedButtonInputEvent(Mouse_LMB)
|-
| Release the LMB|| Mouse button release || injectMouseButtonUp(LMB) || ReleasedButtonInputEvent(Mouse_LMB)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

=== Clicking/activating a button using the keyboard (new feature) ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the button || colspan = 3 | Uses the use case "''Focus a button using the keyboard/gamepad''"
|-
| Press the ENTER key (1) || Key Button press || injectKeyDown(Enter) || PressedButtonInputEvent(Keyb_Enter)
|-
| Release the ENTER key || Key Button release || injectKeyUp(Enter) || ReleasedButtonInputEvent(Keyb_Enter)
|-
| The button is clicked (Click event is triggered)|| N/A || N/A || N/A
|}

(1) the key will be defined as per the NavigationStrategy (GUINavigation project part). If there is no such key defined, the event will be ignored.

=== Clicking/activating a button using a gamepad ===
The same as previous ''Clicking/activating a button using the keyboard'', but with the difference that it uses a Gamepad button instead of a Keyboard one.

=== Type text into a textbox ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Focus the textbox || colspan = 3 | Uses the use case "''Focus a textbox using the keyboard/gamepad''"
|-
| Press a character key || Char press || injectChar(chr) || TextInputEvent(chr)
|-
| Press a non-character key || Key Button press || injectKeyDown(key) || PressedButtonInputEvent(Keyb_key)
|-
| Release a non-character key || Key Button release || injectKeyUp(key) || ReleasedButtonInputEvent(Keyb_key
|}

=== Scroll horizontally with the mouse wheel ===
{| class="wikitable"
|-
! Step description !! Raw input !! Input Injection !! InputEvent fed to CEGUI
|-
| Rotate the wheel || Wheel rotation delta || injectMouseWheelChange(delta) || ScrollInputEvent(direction, delta)
|}

== Proposed design ==
=== Events ===
For start, the following events will cover all existing functions in the 'InjectedInputReceiver' interface:

{| class="wikitable"
|-
! Input Event name !! Data !! Functions covered
|-
| MovementInputEvent ||
* Position : Vector2
* Delta : Vector2
||
* injectMouseMove
* injectMousePosition
|-
| PressedButtonInputEvent ||
* Button : Buttons Enum/integer or long for maximum flexibility
||
* injectMouseButtonDown
* injectKeyDown
|-
| ReleasedButtonInputEvent ||
* Button : Buttons Enum/integer or long for maximum flexibility
||
* injectMouseButtonUp
* injectKeyUp
|-
| ActivatedInputEvent@@@ ||
* Count (1+) : int
||
* injectMouseButtonClick
* injectMouseButtonDoubleClick
* injectMouseButtonTripleClick
|-
| TextInputEvent ||
* Text : string/char
||
* injectChar
|-
| ScrollInputEvent ||
* Delta : int
* Direction : ScrollDirection(0 - horizontal, 1 - vertical)
||
* injectMouseWheelChange
|}

Unmapped (yet) functions:
* injectMouseLeaves

@@@ subject to the next section, Decisions.

== Decisions ==
=== Combining keyboard, gamepad and mouse button pressed actions ===
We have two ways of handling this.
* Using two types of events (Pressed/ReleasedButtonInputEvent) AND SemanticInputEvent
** We have a "big" enum which contains all possible values for a keyboard, mouse and the gamepad
** The 'raw' events (Pressed/ReleasedButtonInputEvent are triggered every time
** The semantic events are generated only based on a mapping configuration: (button_id) -> (semantic_value). If a specific (button_id) present in the mapping is pressed then a semantic event will be generated with the specified (semantic_value).
*** (button_id) is a member of the "big" enum
*** (semantic_value) is a user-defined value. Inside CEGUI's system we'll have an enum which is used instead of magic numbers. Users could define their own enum which has indices starting from the last CEGUI's enum member number.
* Using just the raw types of event (Pressed/ReleasedInputEvent) WITHOUT SemanticInputEvent
** This would involve '''ignoring the explicit click calls''', and rather generate them inside the system.

= GUI navigation =
== Use cases ==

=== Focus a button using the keyboard/gamepad ===
Just calling focus()

=== Navigate a form ===
Prerequisite: first control in the current window is focused; navigation is configured.
* Pressed("Tab") = focus next ("next")
* Pressed("CTRL + Tab") = focus previous ("previous")
Steps:
* Press `Tab`
* The next control is focused.

=== Navigate a 2D Menu ===
Prerequisite: first control in the current window is focused; navigation is configured:
* Pressed("left") = go left ("left")
* Pressed("right") = go left ("right")
* Pressed("top") = go left ("top")
* Pressed("up") = go left ("up")
* ^The same items but with the gamepad's D-Pad configuration instead of the keys
Steps
* Press a configured key/gamepad button.
* The control in the specified direction is focused.

The Zandalar project

2013-07-09T21:49:11Z

Timotei: /* GUI navigation */

The Zandalar project

2013-07-09T21:48:33Z

Timotei:

The Zandalar project

2013-07-09T06:27:25Z

Timotei:

The Zandalar project

2013-06-28T00:12:38Z

Timotei: /* Input Aggregator & events */

The Zandalar project

2013-06-28T00:06:58Z

Timotei: /* Input Aggregator & events */

The Zandalar project

2013-06-27T23:59:51Z

Timotei: /* Use Cases */

The Zandalar project

2013-06-26T22:55:53Z

Timotei: /* Use Cases */

The Zandalar project

2013-06-25T22:24:45Z

Timotei: /* Input Aggregator & events */

The Zandalar project

2013-06-24T13:07:01Z

Timotei: /* Input Aggregator & events */

The Zandalar project

2013-06-24T13:04:00Z

Timotei: More work on the events

The Zandalar project

2013-06-23T14:46:32Z

Timotei: Initial version

User:Timotei

2013-06-23T13:15:22Z

Timotei: Created page with "Yup. That's me."

Yup. That's me.