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

List:       kfm-devel
Subject:    Re: konqueror components
From:       Teodor Romeo Mihai <teddy () piercom ! ie>
Date:       1999-02-16 18:09:38
[Download RAW message or body]

David Faure wrote:
> 
> On Tue, Feb 16, 1999 at 04:29:07PM +0000, Teodor Romeo Mihai wrote:
> > rupert THURNER wrote:
> 
> > Like I said before, guys, I'm talking about the non-working clipboard in
> > KDE and you're talking about openparts.
> 
> Clipboard is something a bit special (because handled by X and by Qt - even
> before KDE can do something about it).
> Qt, as of 1.42, clipboard is text-only, and not associated to a type.
> Qt 2.0 implements a clipboard with mimetype to determine the contents,
> multiple formats for the data (I think), and binary data (afaik).
> So when we switch to Qt 2.0, we'll benefit from all this.
> 

I really know this. I have read most of the Qt 1.42 source code and most
of the kdelibs code, so I can say I'm familiar with the problem.
However, saying that "clipboard is a bit special because of the X" and
"we switch to Qt 2.0, we'll benefit from all this" is barely an excuse.
I can't believe you decided to wait for Qt 2.0 before handling the
clipboard. Anyway, I've decided not to wait, so I have implemented my
own clipboard for internal objects, which acts as well as a wrapper over
the Qt clipboard, and it works fine. Therefore it can be done.
And it's not only the clipboard. It's the drag-and-drop. And I could go
on for a long time like that, but this is not the point. There is
nothing wrong about thinking of the future - as long as we have a steady
present. A real desktop environment is made with good applications,
which we don't quite have, and they require good libraries and good
documentation. You can't make the things perfect, but nobody asks that.
What you can do is provide a base, before thinking too hard about the
next kfm. I know it's more exciting  to decide the next features of the
version 1.1 rather than writing the help for 1.0, but it's up to you to
decide which one is the mature choice.


> This clipboard problem doesn't prevent us from taking design decisions now
> for KDE 2.0, and this involves the technology we call openparts. Nothing
> wrong in thinking about the future as well as fixing bugs in the current KDE.


Regards,
 teddy

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