diff options
Diffstat (limited to 'kspread/DESIGN.html')
| -rw-r--r-- | kspread/DESIGN.html | 44 |
1 files changed, 22 insertions, 22 deletions
diff --git a/kspread/DESIGN.html b/kspread/DESIGN.html index a2248654..2358c3c2 100644 --- a/kspread/DESIGN.html +++ b/kspread/DESIGN.html @@ -22,7 +22,7 @@ and the source code itself.</p> <h2>Document/View Architecture</h2> -<p>Status: IN PROGRESS.</p> +<p>tqStatus: IN PROGRESS.</p> <p>MVC (Model/View/Controller) means that the application consists of three big parts, the <i>Model</i> which holds the data structure and objects, @@ -49,7 +49,7 @@ to some extent he can take most part of the KSpread back-end and glue a new user interface around the code.</p> <h2>Dependency Handling</h2> -<p>Status: IN PROGRESS.</p> +<p>tqStatus: IN PROGRESS.</p> <p>When a cell holds a formula, then it is likely that it depends on other cell(s) for calculating the result. For example, if cell A11 has the formula @@ -181,10 +181,10 @@ and the dependency manager will do the rest. In addition, this gives us recursive dependency calculation at almost no cost.</p> <h2>Manipulators</h2> -<p>Status: PLANNED.</p> +<p>tqStatus: PLANNED.</p> <p>Currently, every operation on a cell or on a range of cells is quite complex. -You need to ensure correct repainting, recalculation, iterate on a range and so on.</p> +You need to ensure correct tqrepainting, recalculation, iterate on a range and so on.</p> <p>To address this issue, manipulators shall be implemented. A manipulator will implement one operation (formatting change, sequence fill, ..., ...).</p> @@ -218,7 +218,7 @@ below.</p> accomplish this.</p> <h2>Selection handling</h2> -<p>Status: PLANNED</p> +<p>tqStatus: PLANNED</p> <p>The selection shall be an instance of some RangeList class, or however we want to call it - this will contain a list of @@ -227,10 +227,10 @@ more entries. This will allow easy implementation of CTRL-selections and so, because thanks to manipulators, each operation will automatically support these.</p> <h2>Repaint Triggering</h2> -<p>Status: PLANNED</p> +<p>tqStatus: PLANNED</p> <p>As mentioned above, the interface between the core and the GUI needs to be kept -at minimum. Also, the number of repaints needs to be as low as possible, and repaints +at minimum. Also, the number of tqrepaints needs to be as low as possible, and tqrepaints should be groupped whenever possible. To achieve all this, the following approach can be used:</p> @@ -246,8 +246,8 @@ methods - disableUpdates(), enableUpdates(), rangeListChanged() and rangeListFormattingChanged(). All these will be used (solely?) by manipulators, preferably by the base manipulator class, so that we don't have to call these functions in each operation. After a call to disableUpdates(), there will -be no repainting and no dependency calculation. Note that a call to -enableUpdates() won't cause any repaints either, as the sheet cannot remember +be no tqrepainting and no dependency calculation. Note that a call to +enableUpdates() won't cause any tqrepaints either, as the sheet cannot remember all the calls (due to loss of range information). Hence, the base manipulator class needs to call the correct rangeList*Changed method to trigger an update in an effective way. The base manipulator needs to be configurable by @@ -255,7 +255,7 @@ the manipulators that derive from it, so that it knows whether it changed cell's content or formatting.</p> <h2>Formula Engine</h2> -<p>Status: FINISHED.</p> +<p>tqStatus: FINISHED.</p> <p>This formula engine is just an expression evaluator. To offer better performance, the expression is first compiled into byte codes which will @@ -353,7 +353,7 @@ to follow its algorithm from there.</p> based on Polish notation. Instead of ordering the tokens in suffix Polish form, the parser (which is also the code generator) simply outputs byte codes. In its operation, the parser requires the knowledge of operator -precedence to correctly translate unparenthesized infix expression and +precedence to correctly translate untqparenthesized infix expression and thus requires the use of a syntax stack.</p> <p>The parser algorithm is given as follows:</p> @@ -376,7 +376,7 @@ Step 4: If it is an operator<br> <p>The reduce rules are:</p> <p>Rule A: <i>function argument</i>: -if token is semicolon or right parenthesis, +if token is semicolon or right tqparenthesis, if syntax stack looks as: <ul type="square"> <li>non-operator <--- top</li> @@ -422,7 +422,7 @@ then reduce to:<br> </ul> </p> -<p>Rule D: parenthesis removal<br> +<p>Rule D: tqparenthesis removal<br> if syntax stack looks as:<br> <ul type="square"> <li>operator (</li> @@ -472,7 +472,7 @@ token right before the percent. If yes, then the following code is generated: <h2>Value</h2> -<p>Status: FINISHED.<br> +<p>tqStatus: FINISHED.<br> </p> <p>to be written.</p> @@ -480,7 +480,7 @@ token right before the percent. If yes, then the following code is generated: <h2>Commands Based on KCommand<br> </h2> -<p>Status: IN PROGRESS.</p> +<p>tqStatus: IN PROGRESS.</p> <p>Until lately, to implement undo and redo, KSpread creates corresponding KSpreadUndo classes for each action and runs them when the user undoes @@ -492,15 +492,15 @@ hence we should be able to undo/redo every operation (provided that the corresponding manipulator provides methods to store/recall the undo information).</p> <h2>Cell Storage</h2> -<p>Status: PLANNED.</p> +<p>tqStatus: PLANNED.</p> <p>Cells are grouped together, and then hashed.</p> <h2>Format Storage</h2> -<p>Status: PLANNED.</p> +<p>tqStatus: PLANNED.</p> <p>Formatting specifies how a cell should look like. It involves font -attributes like bold or italics, vertical and horizontal alignment, +attributes like bold or italics, vertical and horizontal tqalignment, rotation angle, shading, background color and so on. Each cell can have its own format, but bear also in mind that a whole row or column format should also apply.</p> @@ -589,7 +589,7 @@ be in more than one leaf in the quad-tree. <i>Details on the possible use of quad-tree or other methods should be explored further more</i>.</p> <h2>Default Toolbars</h2> -<p>Status: IN PROGRESS.</p> +<p>tqStatus: IN PROGRESS.</p> <p>Relevant mailing-list threads:</p> @@ -652,7 +652,7 @@ Borders, Background, Foreground</li> </ul> <h2>Test Framework</h2> -<p>Status: IN PROGRESS.</p> +<p>tqStatus: IN PROGRESS.</p> <p>Relevant mailing-list threads:</p> @@ -704,7 +704,7 @@ test cases.</p> </p> <h2>Coding Style</h2> -<p>Status: IN PROGRESS.</p> +<p>tqStatus: IN PROGRESS.</p> <p>(to be written in details).</p> @@ -718,7 +718,7 @@ classes and functions should write the documentation.</p> <p>In complex source files, list of header includes can be very long. Unless there is special reason not do it, try to group them together, i.e. standard -C/C++ headers come first, followed by Qt headers, and then KDE headers, +C/C++ headers come first, followed by TQt headers, and then KDE headers, KOffice core/UI headers and application specific headers. For each group, sort the header files alphabetically. </p> |