[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [RFC] Adding a new filter status
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-07-14 23:09:39
[Download RAW message or body]

On Sonntag, 14. Juli 2002 07:54, Clarence Dang wrote:
> On Sun, 14 Jul 2002 06:48, Nicolas Goutte wrote:
> > On Samstag, 13. Juli 2002 12:22, Clarence Dang wrote:
> > > On Sat, 13 Jul 2002 08:05, Nicolas Goutte wrote:
> > > > I am wondering if we should not introduce a new filter status between
> > > > "beta" and "good".
> > >
> > > I think this is an excellent idea!
> > >
> > > > The problem that I have found is that you need to have at least the
> > > > status "beta" before users report bugs and that users consider that
> > > > "good" means that everything should function perfectly. However all
> > > > these make "beta" being very broad.
> > >
> > > I'm thinking that it might also be a good idea to have a table of what
> > > "basic" features each filter imports/exports e.g. character formatting,
> > > paragraph formatting, page formatting (includes
> > > headers/footers/pagination), images etc so that if someone wants to
> > > help with kword filters, they have a better idea of what can be
> > > improved and users know what filters work best for their purposes (eg.
> > > I did not know that the HTML exporter could do images until yesterday
> > > when I used it).
> >
> > I do not understand the difference with the filter status files (all the
> > status.html files in each filter directory)
> >
> > The filter status already have all the data. Why would you want a central
> > table, which would be in the ACL-protected part of the CVS?
>
> Different status.html's lay out the information in different ways and/or
> leave out information.  I'm suggesting a table where the information can
> quickly be seen at a glance, instead of having to go through each
> status.html. Just curious, but aren't the status.html's also ACL-protected?

The problem is that is not the same criteria for all applications.

For example, for a KWord filter, you would probably want to know if it support 
pictures, headers/footers or endnotes. For a KSpread one, if it support some 
advanced function, in KPresenter if such effect is preserved and so on...

However, perhaps adding some common application criteria to each filter status 
page could be better. You could then take care of this difference of interest 
between the applications.

>
(...)
>
> Thanks!
> Clarence

Have a nice day/evening/night!

> _______________________________________________
> koffice-devel mailing list
> koffice-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]