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

List:       koffice
Subject:    Re: using filters for non-plain-text clipboard/dnd contents.
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-08-29 19:03:24
[Download RAW message or body]

I am just giving a few ideas, just in case that the change of the filter 
interface would not accepted by the KOffice core developers.

On Wednesday, 29. August 2001 18:22, Frank Dekervel wrote:
> Hello,
>
> while trying to implement my idea of yesterday i faced some problems:
> 1 the filter API is not totally suited for the job. It requires a temporary
>   input file, and an output file (i'd like to pass the data on via a
>   QByteArray directly from the filter).
>
> 2 Also, i can't 'force' a mime type ( in the 'import' method of
>   koFilterManager  i can't pass a 'source' mime type, only a destination
>   mime type.) i think i will be able to get around this by using my own
>   object instead of koFilterManager. This will result in a lot
>   code duplication (since the 'filter' method has several variants).
>   can i assume a filter always supports the 'simple' method ? (file in,
> file out, no QDomDocument or KoDocument). Note i won't need all the filters
> (probably only the rtf,csv and html input filters, because the clipboard
> content will never be application/x-word97 or so)

1. & 2. : You can save your QByteArray into a KTempFile with a forced 
extension, like for an RTF file:

KTempFile temp (QString::null, ".rtf")

Note for HTML import: HTML import is not supposed to work (see: 
http://www.koffice.org/filters/status.phtml .) It will only work the day I 
(or someone else) achieve to intergate khtml in it or to use libxml2 with it 
or to finish the parser I have writen (it can only XHTML and well-formed 
HTML.)

>
> 3 all the current filters use a tar output file, generated by a koStore.
> the application/x-kword-selection and other koffice clipboard formats are
> plaintext. (but, for kword, are just a <FRAMESET> or a couple of
> <PARAGRAPHS> out of a kword xml 'file' - and i think that will be similar
> for the other applications). So the filters i will use will be 'different
> filters' (they convert to x-blabla-selection instead of x-blabla), but the
> code will be 99% the same as the old filters, so i wouldn't like to create
> new filters.

Open the resulting tar.gz file like the export filters do and take out the 
part that interest you.

>
>    i think a clean approach for this is adding another 'filter' variant to
>    koFilter (filterSelection) with a QByteArray input/output
> (filterSelection) and maybe adding another set of .desktop files for the
> new mime types. something like this: virtual bool filterSelection(const
> QByteArray in, QByteArray *out, const QString from, const QString to, const
> QString &config=QString::null), and a supportsSelection or so method. would
> this be okay ?
>
> i have currently a (semi-)working implementation of this (but the filter
> method is really ugly for the above reasons):
>
> class KoClipboardManager : public QObject
> {
>     Q_OBJECT
> public:
>     KoClipboardManager(QMimeSource *m);
>     ~KoClipboardManager();
>     QStringList availableClipboardTypes();
>     QStringList availableSourceTypes(QString m);
>     QByteArray getClipboardContents(QString m);
>     QByteArray filter(QString mimetype, QString sourcetype);
> protected:
>     QMimeSource *_ms;
>     KoFilterManager *_fm;
> }
>  ;
>
> A paste would then be the following:
> - if there is no native selection format in the clipboard
> - see if i can get it in my native selection format
> (l=availableSourceTypes("application/x-kword-selection"))
> - filter(l[0],"application/x-kword-selection");
> - if no, take the plain text variant
>
> I cannot really test it because khtml only provides plaintext clipboard,
> and mozilla provides html in some strange charset (as someone pointed out
> on irc yesterday)

Which strange charset is it, please? If the resulting HTML clearly states 
(with a <meta> tag) which encoding it is, there should be no problem 
(especialy not if the encoding is UTF-8, UTF-16 or ISO-10646.)

>
> Could someone comment on this as i'm not sure if i'm doing (even remotely)
> the right thing.
>
> greetings,
> Frank
>
> P.S. will there be a standard 'rich text' clipboard format for kde ?
>
> >Hello,
> >
> >one of the things missing from kde are being able to copy/paste
> >non-plain-text data accross applications. Well, missing, they ain't really
> >missing... if the apps speak the same 'clipboard language' (= mime type)
> > it works.
> >If i now wanted to copy something from mozilla to kword, mozilla speaks
> >text/html, and kword speaks application/x-kword-clipboard or so...
> >Or i want to copy a html table in kspread, i would have something similar.
> >Now
> >- we have existing apps that provide clipboard content in several mime
>
> types,
>
> >like mozilla, the koffice apps, ...
> >- we already have a "filter plugin" API (the koffice filters)
> >- we already have a lot of filters, eg from text/html to
> > application/x-kword (which could be modified easily to support
> > x-kword-clipboard, being a small xml tree with some kword paragraphs in
> > it, upon first look)
> >
> >Maybe we could use these to create some more generic filter system using
> > the koffice filters,  where you could eg ask 'can i have the clipboard in
> > application/blabla, if you don't have to convert it from text/plain and ,
> > if no can i have it in text/plain'.
> >Please tell me if this idea is just plain stupid, already obsoleted by
> >something i did not see, ...
> >
> >I'd volunteer for writing a small lib implementing the above, and a couple
>
> of
>
> >test filters if the idea is accepted .. :)
> >
> >greetings,
> >Frank

Have a nice day/evening/night!

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