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

List:       kde-i18n
Subject:    Re: konqueror components
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-16 18:19:01
[Download RAW message or body]

On Tue, Feb 16, 1999 at 06:09:38PM +0000, Teodor Romeo Mihai wrote:
> 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.

Of course it can be done !
But if you did it, you could have contributed to the KDE by sharing your
work, so that the whole KDE would have a fully functional clipboard.

> 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. 

Feel free to contribute, if you something misses work !
We're doing what we can !!

> You can't make the things perfect, but nobody asks that.

You seem to ask that.... Without having contributed an inch.

> 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.

Personally, I'm doing both at the same time. Have a look at how many bugs
I've fixed in kfm - the current one, kfm II - since I maintain it (October
1998). You'll _really_ be surprised.
About the clipboard, I implemented copy/paste of text (from line edits,
HTML pages, ...) as well as URLs. So yes, I addressed the problem of the
clipboard (but I had to deal with the old internal kfm clipboard for URLs,
so it wasn't a global solution for KDE). But there were many many other
things to fix.

I don't need somebody to tell me what I should do. Certainly not the way
you do.
I think I can at the same time fix the current kfm AND think about the next 
version of it without this being an immature choice.

-- 
 ____________________________________________________________________
|                                                                    |
|  David FAURE                                                       |
|  E-mail : David.Faure@insa-lyon.fr, faure@kde.org                  |
|  http://www.insa-lyon.fr/People/AEDI/dfaure/index.html             |
|____________________________________________________________________|

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