Updates about Enhanced Database Ranges.
shetyeakash at gmail.com
Mon Jul 8 06:31:35 PDT 2013
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
On Jun 4, 2013 1:15 AM, "Markus Mohrhard" <markus.mohrhard at googlemail.com>
> Hey Akash,
> 2013/6/2 Akash Shetye <shetyeakash at 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
> > alternating) row formatting (not just colouring) feature. Please help
> > 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
> > 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
> > it will cover/applied to. When the user defines another band, the new
> > 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
> > 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
> > 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
> > 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
> > is assigned to it by picking it up from the
> > 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
> > 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
> > object.
> > The rendering half will have to iterate over each row of the the range
> > iterating over the ScDBRowFormat items in the container in
> > 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
> > 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
> > 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
> > objects taking care of their band sizes as it moves over each row adding
> > 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
> > One way out can be having a member function in ScDBData that returns an
> > array of size[No.OfRows], each entry containing the applicable
> > for that row. This shifts the 'making sense of' part, out of the
> > 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
> > [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,
> > alternately.
> > Or, since clicking format as table option in MS Excel marks a bunch of
> > as a table with a name, which 'optionally' can be coloured; we will need
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LibreOffice