1 Feb 2008 20:13
beta1
Boudewijn Rempt <boud <at> valdyas.org>
2008-02-01 19:13:00 GMT
2008-02-01 19:13:00 GMT
Hi, Nobody will have missed the fact that I haven't released beta1 yet. There are a couple of reasons -- I have had/am having a bit of a bear of a time at work, for instance. But the main thing is that I don't think we've made our beta1 release goals yet. For beta1, we should have been feature complete (with brokenness allowed) and have 100% succeeding unittests. The latter is a given and we can decide to skip that requirement, or fix it. The former (feature complete) is something that we can argue about: I don't have a clear list of features that we feel need to be in a sufficiently present state for beta1, so it's just my feeling. I would really like to get that list fixed, though. (btw, I haven't sent out the mail about the logo either, I will work on that tomorrow afternoon, promise! The rest of tonight is for work-work again). -- -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi
> * keep filters/generic_wrapper
xsltfilter would belong there too, then; it's a generic filter, not a library, iirc.
> * move liboofilter, xsltfilter, libdialogfilter, libkowmf to libs/filters
One reason for regrouping them was to have shared libraries indeed - but indeed we can share them another way.
Another reason would be, well, saving time by not having to recompile filters every time for every change in
the application
(OTOH this gave us frequent breakages of the kspread csv filter since it relies on kspread internal API).
But with automated builds we detect such problems quickly nowadays, I believe the gain is more than the loss
if we
keep the filters separated.
Another reason is that it makes it much clearer that filters are not part of the applications.
You can work on kword's rtf import filter (to pick a random one) without having to dig into
kword's code; it's not like in some other office suites where filters are really part of the apps;
in koffice they are separate modules, which you can even test using koconverter for many of them
(exception being the ones that use the app's internal api for performance reasons like the CSV import filter).
Also, not all filters are specific to one application. My kpresenter-to-kword filter (kpr2kwd and
odp2odt)
is as useful in kpresenter (to export) as it is in kword (to import).
You mention packaging as a reason for moving them back, I guess that's a valid reason, but whether
RSS Feed