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

List:       kde-devel
Subject:    Re: Regarding KDE 4
From:       Thiago Macieira <thiago.macieira () kdemail ! net>
Date:       2004-07-01 22:26:21
Message-ID: 200407011926.22059.thiago.macieira () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Ulrik Mikaelsson wrote:
>I assume KDE 4 will be built around Qt 4, correct?

Correct.

>If the precious question is true, it will require rewriting a lot of
> code. Will KDE 4 overall be rewritten?

Your premise is correct (Qt4 will imply lots of rewriting), but the 
answer is "no" for your question. We won't rewrite KDE from scratch. 
We'll just upgrade it to Qt4, remove old code that isn't used and bring 
in new one.

>If the previous question is true, will the overall design/architecture
> of KDE be re-evaluated? 

Overall design? Care to be more specific on this?

If you mean the packages, I doubt it.

If you mean the architecture, what's wrong with ioslaves and DCOP?

If you mean the libraries, what do you propose?

> I know KDE haven't changed it's architecture 
> much since 1.0,

you mean 2.0.

> and it have worked excellent so far, but IMHO in some 
> areas the limitations of the current architecture/design is beginning
> to reveal themselves.

Please tell us what they are. I know of a couple of limitations, but 
nothing major. You seem to have major problems with a couple of points.

> A re-evaluation would probably benefit KDE 
> greatly, and it seems 4.0 is the right time to do it, now that
> Trolltech have taken their time to refactor so much of the Qt
> framework. Some things previously solved by KDE will now probably be
> better taken care of at a Qt-level, while new needs will most likely
> emerge.

That much is true.

>Will the KConfig class be obsoleted and replaced by KXConfig?

They don't do the same thing. And, to your question in the other e-mail, 
no, KXConfig isn't XML-based.

>Will Arts be replaced by GStreamer, or will at least KDE applications
> be able to use GStreamer directly, without going through Arts, to
> reduce latency?

As has been said, KDE applications will probably use something else 
other than aRts. As for replacing it with GStreamer, last time I heard, 
their developers weren't completely up to the requirements we would 
impose on them (for instance, binary compatibility maintained for 3 
years).

>Will DCOP be replaced by D-BUS to improve cooperation with other
> Desktop Environments, and enable interprocess-communication on a
> system-wide level?

DCOP will probably be kept, and a bridge to D-BUS will be written. I'm 
speculating.

>Will KDE abandon CVS in favour of Subversion or something else for
> 4.0?

I'd love for that to happen, but that's not my call. Even if Subversion 
can win CVS on any comparison hands down, you have to factor in the 
migration effort. Maybe it's just not worth it.

> It would
> function to start letting people know what to expect of 4.0 and focus
> interest on 4.0. Perhaps the form of a restricted Wiki, would be a
> great idea?

Maybe not yet. We need people instead to test KDE 3.3 and fix its bugs. 
It's no use speculating for KDE4 right now, because not even the first 
Qt4 tech preview has been released.

Yes, there are  lots of TODOs in KDE code for KDE4, especially those 
that break binary compatibility.

-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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