On Sun, Aug 25, 2002 at 04:17:32PM -0400, Maks Orlovich wrote:
> Running the following:
> #include <qapplication.h>
> #include <qclipboard.h>
> #include <qmime.h>
>
> int main(int argc, char** argv)
> {
> QApplication app(argc,argv);
>
> QClipboard* clip = QApplication::clipboard();
> clip->setSelectionMode(true);
> QMimeSource* data = clip ->data();
> if (!data)
> qFatal("No data in clipboad!");
> int pos = 0;
>
> while (data->format(pos))
> {
> qDebug("Format supported:%s", data->format(pos));
> pos++;
> }
> }
>
> On the paste results for text I get:
> Format supported:text/plain;charset=UTF-8
> Format supported:text/plain
> Format supported:text/plain;charset=ISO-8859-1
> Format supported:text/plain;charset=UTF-8
> Format supported:text/plain;charset=ISO-10646-UCS-2
> Format supported:text/plain
>
> While for the URL copy I get:
> Format supported:text/plain;charset=UTF-8
> Format supported:text/plain
> Format supported:text/plain;charset=ISO-8859-1
> Format supported:text/uri-list
> Format supported:text/plain
>
> I don't know anything about QClipboard internals, but I guess I'll look it
> up.. Thoughts?
Yup I have lots of thoughts and a workaround...
The following is an analysis of what's going on... The format is
like this for what's in the clipboard:
mime-type:X Target Name (if any):Contents
This is from an app that is running code that is identical to the Copy
Link Location that I wrote. It's copying the URL
"http://www.mandrakesoft.com";.
The current method in the CLIPBOARD we have:
text/uri-list::http://www.mandrakesoft.com^M
text/plain:COMPOUND_TEXT:http://www.mandrakesoft.com
application/x-kio-metadata:(null)
:UTF8_STRING:(null)
text/plain:COMPOUND_TEXT:http://www.mandrakesoft.com
text/plain;charset=ISO-8859-1:STRING:(null)
(null)'s mean literally it returned nothing which is supposed to mean
that the content type is unsupported. And the double listing of
COMPOUND_TEXT is because it advertises a text/plain and a COMPOUND_TEXT
target that are really the same...
The current method in STRING we have:
Exactly the same as above.
And herein lies the problem. Most apps are looking for the STRING
target type when pasting the middle button. The reason gnome-terminal
works is because it's using COMPOUND_TEXT or UTF8_STRING (it requests
both not sure how it decides which to use).
For some reason KDE never puts data in UTF8_STRING or STRING. But it
still advertises them as available targets. It shouldn't be doing this.
I would guess that Eterm might very well be smart enough to look for
COMPOUND_TEXT or UTF8_STRING if KDE advertising it as an available
TARGET (incidentally gnome-terminal doesn't ask what targets are
available it just grabs blindly).
Now STRING from my reading of the ICCCM is supposed to be the primary
text transfer method of the PRIMARY clipboard.
Why the clipboard is returning bad data I don't know.
However I do have a workaround for khtml for the time being.
Rather than setting the PRIMARY clipboard with a KURL::List rather just
set it as text with the URL. Here's what we get when we do that.
In CLIPBOARD:
Same as above.
IN PRIMARY:
text/plain;charset=UTF-8:UTF8_STRING:http://www.mandrakesoft.com
text/plain;charset=ISO-10646-UCS-2::ÿþh (note I have no idea what this
charset is... or if it's right but I don't see this as an issue)
text/plain:COMPOUND_TEXT:http://www.mandrakesoft.com
text/plain;charset=iso8859-1::http://www.mandrakesoft.com
:UTF8_STRING:http://www.mandrakesoft.com
text/plain:COMPOUND_TEXT:http://www.mandrakesoft.com
text/plain;charset=ISO-8859-1:STRING:http://www.mandrakesoft.com
Now you might say "but text/uri-list and application/x-kio-metadata"
aren't in PRIMARY anymore. Nope they aren't. But I seriously doubt
that any application expecting PRIMARY only to contain the selection
(which is the standard) is going to be expecting a specific mime-type
for the data. And application/x-kio-metadata is KDE only and those apps
are probably going to be using CLIPBOARD for anything they might need it
for.
Attached is a patch that makes the change to khtml. Like I said it's
only a workaround. It's not a good fix. The fix is to figure out why
STRING is getting set to null and is still being advertised. In my
review I couldn't find it but I'm not super familiar with KDE or QT
code. Perhaps someone who is better informed can find it.
I'll be passing this analysis and patch on to the KDE folks.
--
Ben Reser <[EMAIL PROTECTED]>
http://ben.reser.org
If your love has no hope of being welcomed do not voice it; for if it
be silent it can endure, a guarded flame, within you.
- The Wisdom of the Sands
--- khtml/khtml_ext.cpp.orig 2002-08-27 23:00:20.000000000 -0700
+++ khtml/khtml_ext.cpp 2002-08-27 23:01:57.000000000 -0700
@@ -386,7 +386,12 @@
#ifndef QT_NO_MIMECLIPBOARD
// Set it in both the mouse selection and in the clipboard
QApplication::clipboard()->setSelectionMode(true);
- QApplication::clipboard()->setData( KURLDrag::newDrag( lst ) );
+ // Ben Reser <[EMAIL PROTECTED]>:
+ // Don't use the below method for now. The clipboard isn't setting
+ // the XA_STRING type for some reason and it brakes middle click pasting
+ // QApplication::clipboard()->setData( KURLDrag::newDrag( lst ) );
+ // This temporarily works around the issue:
+ QApplication::clipboard()->setText(d->m_imageURL.url());
QApplication::clipboard()->setSelectionMode(false);
QApplication::clipboard()->setData( KURLDrag::newDrag( lst ) );
#else
