Hi Kohei, On Mon, 2011-05-16 at 22:14 -0400, Kohei Yoshida wrote: > 1. Promote the chart8 filter as the preferred filter for the > chart2.Document type. This can be done by the attached > chart8-is-preferred-for-chart-document.diff patch.
Patch looks great to me :-) can we get that into -3-4 and get some more reviews for -3-4-0 ? > 2. Remove the type detection definition for the chart2.Document type > from the report builder itself. This can be done by the > report-builder-dont-act-like-chart-handler.diff patch. This will > prevent ORB from advertising itself as the chart filter provider. Did you manage to play with the ORB chart feature ? I would strongly prefer a potential, transient breakage there, than an ODF incompatibility that will create broken files when we save ;-) > I think option 1 is pretty safe, but I don't really know if this would > cause any side effect in other, unexpected places. For instance, the > latest ORB seems to claim some limited charting functionality, and this > may mess that up, or perhaps it may not. Well - it sounds like the ORB is pretty messy anyway :-) so ... can it really make it much worse if it crashes the whole app left and right ? > My preferred option is option 3. Because, while I was test-driving ORB, > it crashed several times due to null pointer exception from the Java > code. And when it does that, it takes the whole soffice process down > with it. And for those complaining about the idea of removing ORB altogether: doing some work to help out improve the stability of the implementation sounds like it would be a good plan. Rather than just wishing it was better, we need (new) developer resource applying to fixing it, with a set of clearly filed and isolated bug reports - preferably with the Java stack-frames that can come from the console (I think), and so on. If the functionality is extremely sub-standard, and creates the risk of data-loss for its users, then we may well want to disable it - or make it 'experimental'. "just reverting a commit" is not an easy thing to do - it requires first finding the problematic commit, also there are a lot of interlocking pieces in most such piles of software :-) so again, real developer resource is required: that can be grown out of sweat & tears from technical QA guys digging deeper - or preferably from interest from those who most need / use the feature. ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice