History log of /haiku/src/apps/debugger/user_interface/gui/value/TableCellValueRendererUtils.cpp
Revision Date Author Comments
# b6c4fc96 01-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Implement #9946.

TableCellValueRenderer{Utils}:
- The rendering calls now take a boolean indicating if the value
being rendered differs from its previous state. This is taken
into account by rendering it in a different color to indicate
the change. Adjust all implementing subclasses accordingly.

VariablesView::ModelNode:
- Now stores the previous value of the corresponding value node,
and can be queried if its value has changed. Used by renderers.

VariablesView::_{Add,Apply}ViewStateDescendentInfos():
- When walking the model, also store/restore the values of nodes in the
history.

In summation of all the above changes, when stepping through a function,
we now display values that have changed since the last step, or that have
appeared for the first time in a different color.


# 59ea286f 05-Nov-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b6c4fc962c6b0d6a0f071069fd0e90053e58f135 01-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Implement #9946.

TableCellValueRenderer{Utils}:
- The rendering calls now take a boolean indicating if the value
being rendered differs from its previous state. This is taken
into account by rendering it in a different color to indicate
the change. Adjust all implementing subclasses accordingly.

VariablesView::ModelNode:
- Now stores the previous value of the corresponding value node,
and can be queried if its value has changed. Used by renderers.

VariablesView::_{Add,Apply}ViewStateDescendentInfos():
- When walking the model, also store/restore the values of nodes in the
history.

In summation of all the above changes, when stepping through a function,
we now display values that have changed since the last step, or that have
appeared for the first time in a different color.


# 59ea286fac914a808edc6989becc77dadff10383 05-Nov-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96