[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:       Frank Dekervel <Frank.dekervel () student ! kuleuven ! ac ! Be>
Date:       2001-08-29 16:22:28
[Download RAW message or body]

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)

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.

   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)

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

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