Hi Sounds like a good idea would be to create a master tracking bug in bugzilla around this plan, then split off the different changes into blocking sub-bugs, and mark some of the easier ones so that other people can start doing them.
Regards, Noel. Michael Meeks wrote: > Hi Kevin, > > On Thu, 2011-10-20 at 02:00 -0400, Kevin Hunter wrote: >> I'm hesitant to ask this because I cannot personally promise time toward >> LO (only on an as-can basis, which is dismally small ATM), but hey, you >> can easily so no. :-) You mention "really need[ing] a whiteboard" to >> elaborate properly. > That really helps; having said that - I sat down with Eike & Kohei to > discuss this in Paris, and (I hope) managed to communicate the essence > of the idea. > >> I submit that putting your thoughts together, perhaps in picture >> form and available on the LO wiki, or put together as a small video >> to Youtube, would be extremely useful to casual LO coders >> like myself. > Sure - so first off, since I'm not actively hacking on calc (as of > now), this is really not my call. I tried to persuade Kohei & Eike of > the intrinsic improvements possible with the new design - if I'm lucky > then they agree that I'm not mad & might think about that. Of course - I > can create a video too, but ... ;-) > >> As an individual volunteer without a face-to-face LO team >> member against whom to bounce ideas, I'd thoroughly love an >> actual-paid-engineer's thoughts on how best to proceed on this front. > So - the very essence of what I'd like to see happen in calc, and the > foundation for it - is to remove the idea that a spreadsheet is a > collection of 'Cell' objects. This seems (to me) to be the foundation of > our scalability problems. > >> I'm personally motivated for Calc because in my science career, I really >> have to bend over backwards to make Calc work effectively for my needs >> where Excel works just plain better/faster/smaller, yet I >> philosophically have stuck myself with Free software. To me, one of the >> biggest areas of weakness for LO, after the various random crashes >> (which are getting better!), is the memory bloat, and speed. It's not >> features. > Right. So the biggest piece (I see) that need tackling here before we > can take advantage of the new code is to start restricting the scope of > 'ScBaseCell' pointers in LibreOffice calc. Last I looked (which was a > while ago) we use ScBaseCell pointers all around the place for things > like undo/redo, change tracking, copy/paste, document construction etc. > > If you wanted to re-start the effort to remove ScBaseCell's mpNote > pointer (which is very infrequently used) - that'd be a great place to > see some of the problems: ultimately I think we want to remove > ScBaseCell (and it's derivatives) entirely - leaving a (numeric) cell as > a single 'double' inside a fixed column-array of entries of the same > type. > > Of course, even without the grand vision coming to fruition, saving 4 > (or 8) bytes per cell would be worthwhile, and improving the above areas > to handle storage of ranges of cell contents in a better encapsulated > way would be rather valuable - I think. > > But of course, you really want to talk to Eike / Kohei / Markus. > >> I'm happy to mess with Ixion (and indeed have poked at it some already) > Right - IMHO, the real problem we have is not so much Ixion (which is > great), but massaging the existing code into a good shape to be ready > for it's heart transplant ;-) The above would be a great step in that > direction. > > Of course, if the calc developers don't object, I'm happy to create a > video of me making a fool of myself with a whiteboard too if you think > it helps :-) > > All the best, > > Michael. > Disclaimer: http://www.peralex.com/disclaimer.html
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice