Re: [Libreoffice] binfilter and features...
Hi, There is alright, a phonecon typically once a week or so. maybe we can put this topic on the agenda would be great and you could dial in if its at a suitable time. doing this during free time, I may really depend if the possibility arise or not. But basically, we could think of a kind of general rule according to the following points: Do we want to support the file format X ? if yes Is the product that produce this file format as default / main / native file format out of support ? if yes Is this product out of support since more than X (3??) years? if yes == LibO supports this file format as read only. In case of changes, the user has to choose another file format, supported for writing. Note: for me, for an average user, having to install a plug-in is not an option. At least as I see even in my west-european neighborhood, despite well educated (university-level!) people, but not computer freaks, using it as a mere tools. I always wonder as people are using computer in a way much more nearer of using hammers than cars Of course, if the product is still on support, this is another story, since there other criteria should determine if this is read or read-write. But this kind of rule could help to shrink down in a regular manner the LibO code, having a basis for suppressing some part of the code. I proposed 3 years, this in average, this is the renewal time for PC's. Actually, for basic users, this is somewhat longer (about 5 years), but as you have seen (or not) for docx-format, after 3 years of the introduction of the new format, people not able to read the new format are really in trouble. This also helps or forces the end-user to migrate to the new format / up to date format, without loosing access to its archive. This is a good help for LibO, I think, avoiding having X former file-format existing around. Other views, ideas? regards ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter and features...
On Sun, 2010-12-05 at 21:23 +0100, Pierre-André Jacquod wrote: I was thinking of taking a 2 steps approach: first silent warning in a conservative way (this is also less risk to introduce bugs) and then to down-size the module just keeping the needed part. That works for me. In my opinion, the needed part would be, for the next releases, just the read capability of (older?) binary format build in within LibO. If we didn't currently have the capability to write them I definitely wouldn't be in favour of adding it. But seeing as we already have the capability of writing them, I wonder if we should retain it, on the other hand, maybe this is the best route to take :-), drop support for writing new ones and help prod the format into extinction. Is there a technical steering committee for this kind of decision, where we could propose / give reasons for thinking this or that? There is alright, a phonecon typically once a week or so. maybe we can put this topic on the agenda and you could dial in if its at a suitable time. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter and features...
On 12/05/2010 12:39 PM, Caolán McNamara wrote: All true. It was just a note that it might be easier, if you have an interest in binfilter, to just take the conservative approach and silence warnings with e.g converting I was thinking of taking a 2 steps approach: first silent warning in a conservative way (this is also less risk to introduce bugs) and then to down-size the module just keeping the needed part. In my opinion, the needed part would be, for the next releases, just the read capability of (older?) binary format build in within LibO. But if the decision is to drop it anyway for the next release, does not bring a lot I did not found any inputs about it within mailing lists. Has the point been discussed somewhere? Is this to be handle by the steering committee? Is there a technical steering committee for this kind of decision, where we could propose / give reasons for thinking this or that? Currently, as said, I am doing conservative warning fixes, but to start something more intrusive, would like to have first a kind of direction decision. regards ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] binfilter and features...
Hi,
currently trying to reduce the number of warning coming from binfilter,
I found quite a lot functions like:
func(var x)
{}
or
func(var x)
{ ASSERT (lksd)
}.
sometimes
func (var x)
{return false}
Would someone mind if I track down the call of such functions, remove
the calls and at the end remove the function? This would reduce and
simplified the codebase, also more efficient (less function calls) and -
I hope - a smaller LibO.
Of course, these functions are marker, but intend someone really to
developp binfilter ?
Which make me think: as new feature, for the next LibO release after
3.3, could it be that StarOffice file format are not supported any more,
at least in writing modus?. Reading files would open it in read only,
trying to save would produce a warning like this old format is
deprecated, please save in a new one. Maybe the same for the old OOo
format?
Or do you intend to drop this in a quicker way?
Just for feed-back.
regards
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter and features...
On Sat, 2010-12-04 at 16:43 +0100, Pierre-André Jacquod wrote: Would someone mind if I track down the call of such functions, remove the calls and at the end remove the function? Sure, if you want. Watch out for virtual methods however, e.g. removing an empty virtual that overrides something that isn't empty would change behaviour of course. I wouldn't like to see too much effort spent on binfilter though. If you're interested in removing unused code I suggest have a poke at the callcatcher output which lists non-virtual methods which nothing either calls or takes the address of. The last run I did for OpenOffice.org is at http://people.redhat.com/caolanm/callcatcher/DEV300_m86/ (I cleared desktop myself recently, I should generate up-to-date lists for LibreOffice master) Look at that juicy list of unused methods in e.g. sd, sc, sw and slideshow and so on. (Its always possible that some of the C signature methods are dlopened by something so skip over those for the first iteration). Those would be the easy low-hanging fruit that would have most bang for your buck. Of course, these functions are marker, but intend someone really to develop binfilter ? No. Which make me think: as new feature, for the next LibO release after 3.3, could it be that StarOffice file format are not supported any more, at least in writing modus?. Reading files would open it in read only, trying to save would produce a warning like this old format is deprecated, please save in a new one. Maybe the same for the old OOo format? Or do you intend to drop this in a quicker way? A lot of people are of the view to delete the whole thing. I'd prefer to move it out of LibreOffice entirely into a standalone project that outputs a import/export extension so that there remains some way to import legacy .sdw format documents. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
