Hello, Progress so far is. +finally finished with import of column and row formatting data for tables. +progressing on exporting back to ooxml.
Need to code faster since i am behind schedule. But I think I can cope up well. This week by thursday you should see export feature for ooxml in place. On Jun 4, 2013 1:15 AM, "Markus Mohrhard" <markus.mohrh...@googlemail.com> wrote: > Hey Akash, > > 2013/6/2 Akash Shetye <shetyeak...@gmail.com>: > > Hey devs, > > > > Thank you moggi and kohei for helping me out on the IRC constantly. > > > > With the design I am describing now, the feature becomes an n-ternating > (not > > alternating) row formatting (not just colouring) feature. Please help > with > > your advice and discussions. > > > > The feature design can be compartmentalised as follows: > > 1. The 'Row Formatting definition' part, where used selects the targeted > > database range and the styles to be applied to it. > > 2. The 'Row Formatting core' where DB Range code and this feature > interact. > > 3. The rendering end. > > After reading this I think we need to split the task into smaller and > easier to handle steps. Hopefully it helps us to focus on the > important tasks for now. I'll explain some of the problems with your > proposal below but the general point is that we should work on the > model right now. Don't think about anything redering related, updating > references or similar stuff until we have implemented the model and > maybe have the import and export implemented. The visual > representation of the feature is something that we can later add but > is of less importance than you think right now. > > > > > Row Formatting definition: > > > > [Data Structures] > > > > About the storage of this formatting information and how alternating > > formatting info will be defined: > > > > User defines each alternating format as a band, and as such 'n' number of > > bands constitute particular n-ternating format. The user select the > > formatting options and the size of the band i.e, how many consecutive > rows > > it will cover/applied to. When the user defines another band, the new > band > > will follow the previously defined band. Thus we can have more than just > > alternating colours for our DB ranges. Eg. define first band of size 1 > and > > bold text, band 2 of size 3 italic text and band 3 of size 1 underlined > > text; for a range of 10 rows, the first will be bold followed by 3 italic > > rows followed by 1 underlined row and so on.. > > > > Every defined band for an Alternating row format will be stored as a > > ScDBDataRowFormat that will have the attributes: 1. index number which > helps > > define the sequence of these bands 2. band size 3. Formatting information > > (ScStyleSheet instance??). It has its method GetStyle() that returns the > > style to be applied > > Let us limit ourself for now to 2 alternating styles. Extending this > later is easier than trying to implement everything at once. > > > > > Many such ScDBDataRowFormat instances are added to a container which is a > > part of ScDBDataRowFormatting object. This object represents the total > style > > you have created and also contains the defined style name you give to it. > > > > All such defined styles are added to a pool of ScDBDataRowFormatting > > objects; lets say this pool is represented by > > ScDBDataRowFormattingCollection (the names are getting scarily long), so > > styles once custom defined can be used again and again. > > > > Associating every ScDBData object with it's ScDBDataRowFormatting object: > > > > Every ScDBData object has an attribute of type ScDBDataRowFormatting > which > > is assigned to it by picking it up from the > ScDBDataRowFormattingCollection > > pool. > > Thus many DB Ranges can use the same style without having to have any > > multiple copies to themselves. > > That design is overcomplicated and lacks some of the important > features. We need at least the following features: two column styles, > two row styles, information about header row, total row, column > labels, ... Please have a look at Excel to see some of the information > we need to store in data structures. A good starting point for the > design is to list all the information we need to store for each table. > Starting with the list we will then decide for each information how to > represent it and how they interact and influence each other. > > Just a short note: When you think about styles in Calc's core > implementation please always think only about the style name. > Everything that is hidden behind ScDocument should at least for you > only use the style name and never the ScStyleSheet object. If there is > ever a case where we need access to the full style we will need to > look closer into it. > > > > > > Row Formatting Core: > > > > The row formatting core is composed of the modifications needed in > ScDBData > > itself to support the new alternating colour functionality. > > > > ScDBData will have a new method GetRowFormatting() just like the one in > > conditio.cxx (GetData()); however this will return a > ScDBDataRowFormatting > > object. > > > > The rendering half will have to iterate over each row of the the range > while > > iterating over the ScDBRowFormat items in the container in > ScDBRowFormatting > > instance taking care of the band size of each and thus applying it to the > > row cells accordingly. This makes the rendering code a little more > > complicated as multiple styles have to be related to different rows. > > > > Events (not actually events) in ScDBData such as: > > > > UpdateMoveTab - changes the table > > UpdateReference() > > ExtendDataArea - extends/shrinks the area under ScDBData > > Don't worry about them right now. We will come back to them when we > have implemented all the data structures and the import/export. > > > > > make changes to the structure and coverage of the defined database > range. We > > need to take care of such events that may wipe out or add newer rows to > the > > range. Such updates set the bModified bool in ScDBData, this needs to be > > known and be handled by the rendering half of this feature. > > > > The rendering end: > > > > This rendering end is the something I am discovering with each passing > day. > > Not much to write here. > > > > Some design issues: > > > > I see one big problem with the way this are laid out now. The formatting > > information and ScDBData's bounds (i.e its rows) are very decoupled. It > > becomes the job of the rendering end to apply the correct formatting by > > iterating over the ScDBRowFormatting container and getting the > ScDBRowFormat > > objects taking care of their band sizes as it moves over each row adding > in > > the formatting information. > > > > This makes the rendering end very complicated (maybe). Since rendering is > > not just taking the concerned rows and style and shoving in the > attributes. > > One way out can be having a member function in ScDBData that returns an > > array of size[No.OfRows], each entry containing the applicable > stylesheet > > for that row. This shifts the 'making sense of' part, out of the > rendering > > part. > > Don't think about the rendering right now. This will be much simpler > than you expect and all most of the logic that you think belongs into > the rendering part actually is part of the mode and we will need it > also for other parts of the mode implementation. In the end we will > just have a method that returns the style name for a cell and not much > more. But please don't worry about that right now because in the end > you'll see that this will look just natural after all other parts are > implemented. > > > > > [UI Stuff] > > Speaking of what to call this functionality and where to place it in the > > menu hierarchy: > > Either we can: > > That is even one step past the implementation of the rendering. We'll > work with the UX team when we are ready to come up with a mock-up for > the UI parts. > > > > > Greet the user with the same dialog as seen in Calc's Data->Select Range, > > from where the user selects a range to be formatted as table i.e, > coloured > > alternately. > > Or, since clicking format as table option in MS Excel marks a bunch of > cells > > as a table with a name, which 'optionally' can be coloured; we will need > to > > incorporate the alternate colouring option in the Data -> Define Range > > dialog in its 'more' section. > > > > In any case once this option is clicked, the user must define a custom > > design or choose from a few existing ones, just like in Excel. > > > > > So let us split the task into several smaller steps that we tackle and > where you should not worry about the next step. > > 1.) Model data structures > 2.) Import/export (OOXML and ODF) > 3.) Rendering and user interaction > 4.) UI > > So for now we concentrate on how to implement all the model data > structures. Mainly how we can represent all the information we need in > calc's core implementation and let them work together. As first step > please list all the information we need to store in the model and we > will discuss on IRC how to represent them. > > Regards, > Markus >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
