Difference between revisions of "Chart2"

From Apache OpenOffice Wiki
Jump to: navigation, search
(→‎Application-Framework-Related Problems)
 
(268 intermediate revisions by 12 users not shown)
Line 1: Line 1:
−
''Chart2'' is a sub-project of the [http://graphics.openoffice.org/chart/chart.html OpenOffice.org Chart Project]. Our goal is to develop a new Chart component for (presumably) OOo 2.6.
+
{{ChartQuickLinks}}
  
−
Charts are used for visualizing data sets from e.g. spreadsheets by two and three dimensional diagrams. There are a lot of different two- and three-dimensional chart types you can choose from. This page gathers information about the new chart implementation of OpenOffice.org. It is especially written to help new comers to the process of developping in the new OOo chart module.
+
The Chart module was exchanged completely on the way to OpenOffice.org 2.3.
 +
This is the basis for further enhancements and long awaited features.
  
−
If you would like to participate, if you have comments or questions related to the chart you are welcome on the graphics mailinglists:  (users,dev,features,bugs,cvs)@graphics.openoffice.org. See also the section at the bottom of this page called [Some useful information].
+
This page documents ongoing work, implemented and still missing features. It also links to further useful information around the chart.
  
−
= Development in the New Chart =
+
== Helping with the Chart ==
  
−
As the information on how to compile the new chart and on how to develop in this project have become quite lenghty, they can be found now on separate pages:
+
[[Image:ProgrammingLanguage2s.png|frame|right|Example Chart made with OpenOffice.org 2.3 (ods-file see [[Image:ProgrammingLanguages.ods]])]]
  
−
* [[Compiling the new chart module]]
+
=== Development ===
−
* [[Developing for the new chart module]]
+
  
−
= Open Technical Issues in the New Chart =
+
If you are new to OpenOffice.org development have a look at the more general pages first:
 +
*[[Documentation/Building_Guide/Getting_the_source|  Getting the source code]]
 +
*[[Documentation/Building_Guide/Building_on_Windows| Building on Windows]]
 +
*[[Cpp_Coding_Standards|C++ Coding Standards]].
  
−
There still some architectural issues left that have to be solved. This section serves for showing those problems and showing the progress in finding solutions.
+
The file format used for OpenOffice.org is the ODF format.
 +
* [http://www.oasis-open.org/specs/index.php#opendocumentv1.1 ODF 1.1] is final.
 +
* The upcoming format ODF 1.2 is still in progress (look for the latest announcements and available documents [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office here]).
 +
* [[Chart2/Proposals| Proposals]]
  
−
== Application-Framework-Related Problems ==
+
If you like to help developing the chart, you can find useful information at the following places:
 +
*[http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Charts/Charts Chart chapter in the Developers Guide]
 +
*[http://wiki.services.openoffice.org/wiki/Documentation/BASIC_Guide/Charts Chart chapter in the BASIC Developers Guide]
 +
*[[FAQ about Chart API Compatibility]]
 +
*[http://api.openoffice.org/docs/common/ref/com/sun/star/chart/module-ix.html Published UNO API (com::sun::star::chart)]
 +
*[http://graphics.openoffice.org/chart/chart2codestructure.html Rough overview of the code Structure in module chart2]
 +
*[[Chart2/Open Technical Issue in Chart2|Notes on some technical issues]]
  
−
=== Identify the XDataProvider reliably ===
+
The module for the chart implementation is chart2. It is a submodule of the graphics project. The chart implementation makes heavy use of UNO (Universal Network Objects), thus it would be good to learn about [http://udk.openoffice.org/ UNO] first. The new chart does support a published stable UNO API [http://api.openoffice.org/docs/common/ref/com/sun/star/chart/module-ix.html com::sun::star::chart] for external use.
 +
There is also an internal API com::sun::star::chart2. The internal API is not published and is not guaranteed to be stable. It is subject to further changes - so don't count on it in scripts or something! Furthermore several things you can set with the internal API will not be saved by the application. So for stable work please use the published standard chart API com::sun::star::chart.
  
−
If the chart is embedded in a container document that provides the data for this chart, the chart contains range-strings at several places in its <tt>conten.xml</tt> stream that are understood by the container, so that the data can be located there. In Calc such a string would look like this: "Sheet1.A2:A7". Such range-strings can appear in the chart:plot-area element of a chart or at a chart:series, chart:categories or chart:domain element.
+
If you have questions on the chart development please use the mailing list [http://openoffice.org/projects/graphics/lists dev@graphics.openoffice.org].
  
−
If a chart has its own data, this data is stored in a local table in the XML-file. The mentioned range-strings are then of a similar form, with the fixed table-name "local_table". But, the local table is also stored, as a kind of cache, if the data comes from outside. Therefore the existence of the local table does not imply that a chart has own data.
+
To find a concrete task to work on, check the issue queries of open chart bugs and features. Maybe there is something that catches your interest:
 +
* [http://openoffice.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=STARTED&bug_status=REOPENED&cf_bug_type=DEFECT&cf_bug_type=TASK&cf_bug_type=PATCH&columnlist=short_desc%2Ccf_bug_type&field-1-0-0=bug_status&field0-0-0=product&field0-0-1=short_desc&query_format=advanced&type-1-0-0=anyexact&type0-0-0=equals&type0-0-1=anywordssubstr&value-1-0-0=UNCONFIRMED%2CNEW%2CSTARTED%2CREOPENED%2CRESOLVED%2CVERIFIED&value0-0-0=Chart&value0-0-1=chart%20diagram&order=bugs.bug_id%20desc&query_based_on= Open chart bugs] (defects and tasks)
 +
* [http://openoffice.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=STARTED&bug_status=REOPENED&cf_bug_type=FEATURE&cf_bug_type=ENHANCEMENT&columnlist=votes%2Cshort_desc%2Ccf_bug_type&field-1-0-0=bug_status&field0-0-0=product&field0-0-1=short_desc&query_format=advanced&type-1-0-0=anyexact&type0-0-0=equals&type0-0-1=anywordssubstr&value-1-0-0=UNCONFIRMED%2CNEW%2CSTARTED%2CREOPENED%2CRESOLVED%2CVERIFIED&value0-0-0=Chart&value0-0-1=chart%20diagram&order=bugs.bug_id%20desc&query_based_on= Requested chart features] (enhancements and features)
  
−
So, neither the existence of local data, nor the existence of range-addresses (and even the content, considering that it is allowed that a sheet may also have the name local_table) determines whether or not a chart uses own data or data from the container document.
+
=== Testing ===
  
−
In the old chart implementation, the chart always reads the internal data and uses it. If the data comes from the container, the container has an additional attribute that contains the complete data-range as one string. It then sets this string at the chart, which gives the chart the knowledge that data comes from outside (actually, in the old implementation, there is always local data. If data in Calc changes, the Calc prepares an SchMemChart object that contains the new local data and sets this object at the chart).
+
You can help a lot with identifying new problems or verifying fixed and integrated issues!
  
−
In the new implementation, we must to get rid of the badly-designed approach, as we no longer have one complete address-range for the entire chart.
+
[http://download.openoffice.org/next/ Download] the latest developer build and give it a try. When you find a bug please check whether someone else already did submit an issue for that problem. The following issue list can help you with the research:
  
−
<b>Solution</b>: We have to introduce a new XML-attribute at the chart that identifies the data provider. This may be a flag denoting "own data" or "external data", or even a URL, or the like, that uniquely identifies the data provider document.
+
* [http://openoffice.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=STARTED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&columnlist=votes%2Cshort_desc%2Ccf_bug_type&field-1-0-0=bug_status&field0-0-0=product&field0-0-1=short_desc&query_format=advanced&type-1-0-0=anyexact&type0-0-0=equals&type0-0-1=anywordssubstr&value-1-0-0=UNCONFIRMED%2CNEW%2CSTARTED%2CREOPENED%2CRESOLVED%2CVERIFIED&value0-0-0=Chart&value0-0-1=chart%20diagram&order=bugs.bug_id%20desc&query_based_on= Open chart issues].
 +
* Or create your [http://openoffice.org/bugzilla/query.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=STARTED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&field-1-0-0=bug_status&field0-0-0=product&field0-0-1=short_desc&query_format=advanced&type-1-0-0=anyexact&type0-0-0=equals&type0-0-1=anywordssubstr&value-1-0-0=UNCONFIRMED%2CNEW%2CSTARTED%2CREOPENED%2CRESOLVED%2CVERIFIED&value0-0-0=Chart&value0-0-1=chart%20diagram own query].
  
−
<b>Problem</b>: Currently, it is necessary that when loading a chart, the container document is set as XParent before the chart itself is loaded. Otherwise there is no data provider, and the ranges are not valid for the internal data provider, and therefore are forgotten. A later setting of the data provider does not re-establish the correct range-strings.
+
If the problem is unknown you are welcome to [http://openoffice.org/bugzilla/enter_bug.cgi?product=Chart&component=ui&rep_platform=All&op_sys=All&cc=iha@openoffice.org submit a new issue]. Please describe only one problem per issue.
 +
Thanks a lot for your help!
  
 +
== Implemented Chart Features ==
  
−
=== Update of the Chart on changed Data ===
+
* [[Chart2/Features3.3  | Additional Features in OOo 3.3 ]]
 +
* [[Chart2/Features3.2  | Additional Features in OOo 3.2 ]]
 +
* [[Chart2/Features3.1  | Additional Features in OOo 3.1 ]]
 +
* [[Chart2/Features3.0  | Additional Features in OOo 3.0 ]]
 +
* [[Chart2/Features2.4  | Additional Features in OOo 2.4 ]]
 +
* [[Chart2/Features2.3  | Additional Features in OOo 2.3 ]]
  
−
When a chart gets its data from the container document, and the data changes, the changes are notified via a listener mechanism. That is, when the chart queries for data at the XDataProvider, it gets XLabeledDataSequences. At those XLabeledDataSequences it starts listening for changes. If a change event is fired, the chart sets itself as modified, which forces the view to repaint, as it listens to model changes exactly via this mechanism.
+
== Open Chart Features ==
 +
* [[Chart2/ChartTypes      | Chart-Types ]]
 +
* [[Chart2/Legend          | Legend ]]
 +
* [[Chart2/DataLabels      | Data Labels ]]
 +
* [[Chart2/Axis            | Axis ]]
 +
* [[Chart2/ChartFormatting | Chart formatting ]]
 +
* [[Chart2/TrendLines      | Trend lines and error bars ]]
 +
* [[Chart2/Range          | Range and data series ]]
 +
* [[Chart2/ChartAnnotation | Chart annotation ]]
 +
* [[Chart2/Miscellaneous  | Miscellaneous ]]
  
−
However, if a Calc document containing Charts is loaded, the charts are either not loaded immediately because they are not visible, or because the contain a replacement image that shows the last rendered view.
+
== Basic Macro Examples ==
  
−
In both cases, changes in the spreadsheet, like a change in data (which should be visible via a newly rendered view) or moving around ranges (which must change the ranges that are stored in the model), are not propagated to the chart, as it is not loaded and therefore is not listening.
+
* [[Chart2/ChangeTitleFormattingForAllChartsInACalc | Change title formatting for all charts in a spreadsheet ]]
  
−
In the old implementation, again, the fact that the Calc knew the data-range for each chart, solved this problem. Because the Calc could load all unloaded charts affected by the change, and then notify it. However, this requires internal knowledge of the chart to be exposed to the container document.
+
* [[Chart2/GetPositionOfAChart | Get the position of a chart within a spreadsheet ]]
  
−
<b>Solution</b>: When an OLE-object is loaded, it only shows the replacement image. This state is called the "LOADED" state. This means only a small "stub" is loaded, not the entire object. The XModel of an object (including the entirely applied content of the XML-streams) is loaded in the "RUNNING" state. So when all charts would initially be set into the RUNNING state, this would ensure the existence of all XModels, which would allow the listening to work.
+
* [[API/Samples/StarBasic/Impress/Insert_a_Chart | Create Chart in a presentation document ]]
  
−
<b>Problem:</b>: It has to be evaluated, if loading the XModel objects of all charts in a document might take too long in loading a document, or if it consumes too much memory.
+
* [http://www.ooowiki.de/DiagrammExport Export Charts from a Calc spreadsheet ]
  
−
== Calc- and Writer-Related Problems ==
+
Also have a look at the [http://wiki.services.openoffice.org/wiki/Documentation/BASIC_Guide/Charts BASIC Developers Guide]!
  
−
=== The com.sun.star.table.XTableCharts object is based on the old chart ===
+
== Contact ==
  
−
When you want to insert a new chart into Calc or Writer, this can be done via the com.sun.star.table.XTableChartSupplier interface that returns an XTableCharts container. At this container there is a method:
+
* Development Contact: [[User:Iha|iha]]
  
−
<pre>
 
−
void addNewByName(
 
−
  [in] string                            aName,
 
−
  [in] ::com::sun::star::awt::Rectangle  aRect,
 
−
  [in] sequence< CellRangeAddress >      aRanges,
 
−
  [in] boolean                          bColumnHeaders,
 
−
  [in] boolean                          bRowHeaders );
 
−
</pre>
 
−
 
−
You need a sequence of CellRangeAddresses to give a range and the parameters whether to use the first column or row for labels. In comparison to the XDataProvider method:
 
−
 
−
<pre>
 
−
XDataSource createDataSource(
 
−
  [in] sequence< ::com::sun::star::beans::PropertyValue > aArguments );
 
−
</pre>
 
−
 
−
the parameters in aArguments differ in the following way: instead of sequence< CellRangeAddress >, we only have one string. This is no problem, as there exists a conversion. But the parameter "DataRowSource" is missing. So you can only say if the first column or row is used for labels, but not if the data comes from rows or columns. Without this information, the other information is also useless. This renders the entire interface useless.
 
−
 
−
As a work-around, you can create the chart with some dummy data, and then attach new data using the data provider interface. However, a new interface, probably one that only gets the name and the rectangle would be more appropriate than the work-around.
 
−
 
−
== Graphic-Framework-Related Problems ==
 
−
 
−
=== The type of the com.sun.star.drawing.BitmapTable ===
 
−
 
−
For gradients, transparency-gradients, hatches, line-dashes and bitmaps there are tables in the chart model that contain those elements together with names. E.g., you may have a gradient with the name "My Gradient". When you set the "FillGradientName" Property of an object to "My Gradient", the object will display the corresponding gradient found in this table. The same holds for fill-bitmaps.
 
−
 
−
However, there is a problem as the table for bitmaps maps a name to a URL rather than to some real graphic object. So, when you add an element to this table, the graphic itself isn't used anywhere in the document at this time. As we have a graphic-manager that deals with all graphics, that keeps graphics only if they are used (if there is a refcount > 0), the grapghics are dropped in this case.
 
−
 
−
<b>Solution</b>: Change this map to a mapping from names (strings) to objects of type com.sun.star.graphic.XGraphic. As the existence of an XGraphic object ensures that the graphic is available in the graphic-manager, this will solve this problem. Only in the moment an element in this list is used in no model object and also removed from the list, the underlying graphic will be dropped by the graphic-manager.
 
−
 
−
<b>Problem</b>: This affects also the other applications that implement this table, namely Writer, Calc and Impress. This table is also used in xmloff for a generic facility to export and import graphics in XML.
 
−
 
−
= Documentation =
 
−
 
−
= Some useful information =
 
−
 
−
* Main Chart Project Page: http://graphics.openoffice.org/chart/chart.html
 
−
* Chart Specifications: http://specs.openoffice.org/chart/index.html
 
−
* Current CWS Name: [[http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=1074&Path=SRC680%2Fchart2mst3 chart2mst3]]
 
−
* IRC channel: #chart2.openoffice.org (on freenode)
 
−
 
−
 
−
[[Category:Calc issues]]
 
 
[[Category:Chart2]]
 
[[Category:Chart2]]
−
[[Category:Source_directories]]
+
[[Category:Source directories]]

Latest revision as of 16:28, 6 June 2011

Chart Quick Links


The Chart module was exchanged completely on the way to OpenOffice.org 2.3. This is the basis for further enhancements and long awaited features.

This page documents ongoing work, implemented and still missing features. It also links to further useful information around the chart.

Helping with the Chart

Example Chart made with OpenOffice.org 2.3 (ods-file see File:ProgrammingLanguages.ods)

Development

If you are new to OpenOffice.org development have a look at the more general pages first:

The file format used for OpenOffice.org is the ODF format.

  • ODF 1.1 is final.
  • The upcoming format ODF 1.2 is still in progress (look for the latest announcements and available documents here).
  • Proposals

If you like to help developing the chart, you can find useful information at the following places:

The module for the chart implementation is chart2. It is a submodule of the graphics project. The chart implementation makes heavy use of UNO (Universal Network Objects), thus it would be good to learn about UNO first. The new chart does support a published stable UNO API com::sun::star::chart for external use. There is also an internal API com::sun::star::chart2. The internal API is not published and is not guaranteed to be stable. It is subject to further changes - so don't count on it in scripts or something! Furthermore several things you can set with the internal API will not be saved by the application. So for stable work please use the published standard chart API com::sun::star::chart.

If you have questions on the chart development please use the mailing list dev@graphics.openoffice.org.

To find a concrete task to work on, check the issue queries of open chart bugs and features. Maybe there is something that catches your interest:

Testing

You can help a lot with identifying new problems or verifying fixed and integrated issues!

Download the latest developer build and give it a try. When you find a bug please check whether someone else already did submit an issue for that problem. The following issue list can help you with the research:

If the problem is unknown you are welcome to submit a new issue. Please describe only one problem per issue. Thanks a lot for your help!

Implemented Chart Features

Open Chart Features

Basic Macro Examples

Also have a look at the BASIC Developers Guide!

Contact

  • Development Contact: iha
Retrieved from "https://wiki.openoffice.org/w/index.php?title=Chart2&oldid=197032"
Personal tools