The InfoVis Toolkit - Revision history

Anfe: /* General Approach */

2006-08-20T16:51:05Z

General Approach

Anfe: /* Summary */

2006-08-20T16:31:15Z

Summary

← Older revision		Revision as of 16:31, 20 August 2006
Line 8:		Line 8:

	''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br />		''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br />
	''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://~~www~~.~~rsmas~~.~~miami.edu~~/~~environment/wx/time-series-cstars~~.pl Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://~~www-2.cs~~.~~cmu~~.~~edu~~/~~%7Esage/Papers/CHI90/DC.figure6~~.~~gif~~ Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br />		''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://ivtk.sourceforge.net/TableTimeSeries.png Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://ivtk.sourceforge.net/GraphNodeLink.png Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br />
	''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br />		''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br />


	The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was ~~paid~~ to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.		The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was set to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.

	Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type ~~a column should map~~ and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single records in it.		Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type as columns and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single tubles or records in it.

	The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design\|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes.		The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design\|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes.

	However, ~~the toolkit seems not be suitable to realize~~ own complex [[Information Visualization\|visualizations]] which ~~requires~~ a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data sources.		However, realization of own complex [[Information Visualization\|visualizations]] which require a lot of special functionality may be hard work and enforces developer to understand the internal structure of the toolkit itself. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data sources.

	=== Pros ===		=== Pros ===

Anfe at 09:28, 31 July 2006

2006-07-31T09:28:11Z

← Older revision		Revision as of 09:28, 31 July 2006
Line 122:		Line 122:
	; utils		; utils
	: contains several helper classes like comparators, etc <br />		: contains several helper classes like comparators, etc <br />


	=Conclusion=		=Conclusion=

62.178.132.205 at 09:26, 31 July 2006

2006-07-31T09:26:46Z

← Older revision		Revision as of 09:26, 31 July 2006
Line 18:		Line 18:
	The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design\|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes.		The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design\|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes.

	However, the toolkit seems not be suitable to realize own complex [[Information Visualization\|~~visualization~~]] which requires a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data ~~records~~.		However, the toolkit seems not be suitable to realize own complex [[Information Visualization\|visualizations]] which requires a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data sources.

	=== Pros ===		=== Pros ===
Line 32:		Line 32:
	* demos and examples included		* demos and examples included
	* open source		* open source


	=== Cons ===		=== Cons ===
Line 51:		Line 50:
	[[Image:infovis_toolkit_structure.png\|400px]]		[[Image:infovis_toolkit_structure.png\|400px]]

	The proper functionality of the toolkit is ~~combined in~~ an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of ~~the~~ item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.		The proper functionality of the toolkit is maintained by an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of an item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.

	The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each ~~java~~ Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.		The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each Java Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.

	Controlling of the visualization is done by manipulating ~~visual attributes~~ of the ''~~Visualization~~'', by manipulating ~~‘’Renderers’’~~, or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality.		Controlling of the visualization is done by manipulating mapped columns of the ''Table'', by manipulating ''Renderers'', or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality.

	==Readers and Writers==		==Readers and Writers==

	''Readers'' and ''Writers'' are associated with a ''Table'' ~~and used to fill it or write its content back to the file system~~. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc.		''Readers'' and ''Writers'' are associated with a ''Table''. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc.

	==Table==		==Table==
Line 67:		Line 66:
	[[Image:infovis_toolkit_table.png\|700px]]		[[Image:infovis_toolkit_table.png\|700px]]

	Several ''Columns'' to map standard types like ~~strings~~ or ~~integers~~ are already predefined. The ''ObjectColumn'' can store each thinkable Java Object.		Several ''Columns'' to map standard types like Strings or Integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. Therefore, a tuple in the table is composed of several differnt objects that may contain own data again.

	~~Following this way, a table can contain each possible data.~~ As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data.		As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data.

	A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.		A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.
Line 77:		Line 76:
	The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.		The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.

	Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by ~~lay outing~~ algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''.		Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by layouting algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''.

	The ''ShapeColumn'' is only updated when needed. This happens on following events:		The ''ShapeColumn'' is only updated when needed. This happens on following events:

	* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' ~~are~~ changed, new ones ~~are~~ inserted, or existing ones ~~are~~ deleted.		* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' have changed, new ones were inserted, or existing ones were deleted.
	* A user-interaction forces a new layout of the items.		* A user-interaction forces a new layout of the items.
	* A user-interaction changes the filtering process.		* A user-interaction changes the filtering process.

	Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on ~~the~~ visual attributes. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).		Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on visual attributes of the ''Visualization''. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).

	Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling.		Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling.
Line 91:		Line 90:
	==Components==		==Components==

	In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, set filter expressions ~~to restrict the visual content~~, or select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.		In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, components to set filter expressions, or handler to select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.

			Note, that interactions in the '''InfoVis ToolKit''' may change columns in the underlying table. Further, the table is also used to store flags that indicates the actual state of an tuple.

	==Image==		==Image==
Line 125:		Line 126:
	=Conclusion=		=Conclusion=

	The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed.		The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But, the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed. Nevertheless, many included examples are buggy or partially not runable anyway. When using a predefined sample, an exact testing is necessary.

	= External links =		= External links =

Anfe at 23:02, 28 July 2006

2006-07-28T23:02:43Z

← Older revision		Revision as of 23:02, 28 July 2006
Line 49:		Line 49:
	An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:		An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:

	[[Image:infovis_toolkit_structure.png\|~~600px~~]]		[[Image:infovis_toolkit_structure.png\|400px]]

	The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.		The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.
Line 65:		Line 65:
	The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata:		The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata:

	[[Image:infovis_toolkit_table.png\|~~600px~~]]		[[Image:infovis_toolkit_table.png\|700px]]

	Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object.		Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object.

Anfe at 23:02, 28 July 2006

2006-07-28T23:02:19Z

← Older revision		Revision as of 23:02, 28 July 2006
Line 49:		Line 49:
	An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:		An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:

	[[Image:infovis_toolkit_structure\|600px]]		[[Image:infovis_toolkit_structure.png\|600px]]

	The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.		The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.
Line 65:		Line 65:
	The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata:		The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata:

	[[Image:infovis_toolkit_table\|600px]]		[[Image:infovis_toolkit_table.png\|600px]]

	Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object.		Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object.

Anfe at 22:57, 28 July 2006

2006-07-28T22:57:10Z

Show changes

Iwolf at 01:50, 17 June 2005

2005-06-17T01:50:48Z

← Older revision		Revision as of 01:50, 17 June 2005
Line 1:		Line 1:
			== Summary ==

	'''Author'''<nowiki>: Jean-Daniel Fekete / INRIA Futurs</nowiki><br />		'''Author'''<nowiki>: Jean-Daniel Fekete / INRIA Futurs</nowiki><br />
	''' Project Webpage''': [http://www.lri.fr/%7Efekete/InfovisToolkit/ http://www.lri.fr/~fekete/InfovisToolkit/]<br />		''' Project Webpage''': [http://www.lri.fr/%7Efekete/InfovisToolkit/ http://www.lri.fr/~fekete/InfovisToolkit/]<br />

Iwolf at 01:48, 17 June 2005

2005-06-17T01:48:37Z

← Older revision		Revision as of 01:48, 17 June 2005
Line 62:		Line 62:
	:label<br />		:label<br />
	:size<br />		:size<br />

			[[Category:Toolkits]]

Iwolf at 01:48, 17 June 2005

2005-06-17T01:48:26Z

← Older revision		Revision as of 01:48, 17 June 2005
Line 59:		Line 59:
	==== Generic ====		==== Generic ====

	color<br />		:color<br />
	label<br />		:label<br />
	size<br />		:size<br />

← Older revision		Revision as of 16:51, 20 August 2006
Line 50:		Line 50:
	[[Image:infovis_toolkit_structure.png\|400px]]		[[Image:infovis_toolkit_structure.png\|400px]]

	The proper functionality of the toolkit is maintained by an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are ~~declared by visual~~ attributes. ~~These attributes can be~~ associated with a certain ''Column'' of the ''Table''. Further, an ~~associated~~ ''ItemRenderer'' provides the painting routines of an item. After ~~the~~ items are layouted, the ~~resulting~~ shapes are stored in the ''ShapeColumn'' within the ''Visualization''.		The proper functionality of the toolkit is maintained by an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are described with attributes. Each used attribute is associated with a certain ''Column'' of the ''Table''. Further, an ''ItemRenderer'' provides the painting routines of an item. After all items are layouted, the resulted shapes are stored in the ''ShapeColumn'' within the ''Visualization''.

	The view of a visualization ~~done with the '''InfoVis Toolkit'''~~ is the ''VisualizationPanel''. This graphical component can be embedded in each Java Swing application. However, there is no ~~force~~ to use this panel, also other targets like ~~an image~~ or a standard ''JComponent'' can be taken to communicate the output to the user.		The view of a visualization is the ''VisualizationPanel''. This graphical component can be embedded in each Java Swing application. However, there is no need to use this panel, also other targets like a ''BufferedImage'' or a standard ''JComponent'' can be taken to communicate the output to the user.

	Controlling of the visualization is done by manipulating mapped columns of the ''Table'', by manipulating ''Renderers'', or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which ~~combines~~ several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality.		Controlling of the visualization is done by manipulating mapped columns of the ''Table'', by manipulating ''Renderers'', or by setting dynamic queries to filter the visual content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combine several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality.

	==Readers and Writers==		==Readers and Writers==
Line 62:		Line 62:
	==Table==		==Table==

	The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata:		The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers like vectors or hashtables. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata:

	[[Image:infovis_toolkit_table.png\|700px]]		[[Image:infovis_toolkit_table.png\|700px]]
Line 68:		Line 68:
	Several ''Columns'' to map standard types like Strings or Integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. Therefore, a tuple in the table is composed of several differnt objects that may contain own data again.		Several ''Columns'' to map standard types like Strings or Integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. Therefore, a tuple in the table is composed of several differnt objects that may contain own data again.

	As an array is indexed, the table itself has indexes too. The index is used to access a data ~~tuple~~, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data.		As an array is indexed, the table itself has indexes too. The index is used to access the data records, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data.

	A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.		A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with the index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.

	==Visualization==		==Visualization==
Line 76:		Line 76:
	The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.		The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.

	Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by ~~layouting~~ algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''.		Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by layout algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''.

	The ''ShapeColumn'' is only updated when ~~needed~~. This happens on following events:		The ''ShapeColumn'' is only updated when it is required. This happens on following events:

	* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' have changed, new ones were inserted, or existing ones were deleted.		* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' have changed, new ones were inserted, or existing ones were deleted.
Line 84:		Line 84:
	* A user-interaction changes the filtering process.		* A user-interaction changes the filtering process.

	Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on visual attributes of the ''Visualization''. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).		Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on the visual attributes of the ''Visualization''. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).

	Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling.		Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling.
Line 92:		Line 92:
	In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, components to set filter expressions, or handler to select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.		In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, components to set filter expressions, or handler to select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.

	Note, that interactions in the '''InfoVis ToolKit''' may change columns in the underlying table. Further, the table is also used to store flags that ~~indicates~~ the actual state of an ~~tuple~~.		Note, that interactions in the '''InfoVis ToolKit''' may change columns in the underlying table. Further, the table is also used to store flags that indicate the actual state of an item.

	==Image==		==Image==
Line 98:		Line 98:
	The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler.		The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler.

	The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics.		The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics.

	=Details=		=Details=