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

List:       kde-devel
Subject:    Re: Regarding KDE 4
From:       Ulrik Mikaelsson <rawler () rsn ! bth ! se>
Date:       2004-07-02 11:26:03
Message-ID: 200407021326.08777.rawler () rsn ! bth ! se
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Friday 02 July 2004 00.26 skrev Thiago Macieira:
> >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?
I just meant re-evaluating the overall KDE architecture/design in relation to 
new technologies, such as Qt4 and D-BUS.

For example, if a total transition to D-BUS should occur, perhaps it would be 
a wise idea to review the IO-slave components. Perhaps at that point, the 
possibility of having a component shared with GNOME and other applications to 
abstract I/O should be considered?

Perhaps some of the KDE hardware configuration frameworks should be 
reconsidered if D-BUS enables system-wide communication between daemons?

And since Qt4 offer a LOT more regarding threading, perhaps parts of KDE have 
to be radically re-thought to fully benefit from the potential 
performance-gain?

There are a lot of new possibilities, and it would be sad to only discover 
them at 4.1, when such radical changes are more difficult to perform.

> > I know KDE haven't changed it's architecture
> > much since 1.0,
> you mean 2.0.
Yes, I do.

> > 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.
Take the KParts framework for instance. It works excellent for an application 
like Konqueror. However, since KDE 3.2, a new KParts-based plugin-framework 
emerged. The problem with this plugin framework is that even though it may 
work fine for Kopete, other applications do have issues with it. Amongst 
other things, the KPluginSelector does to my knowledge not provide any means 
of enabling/disabling plugins during runtime? Another problem I had was when 
creating applications without a main-windows. Much of the KParts-API:s are 
closely tied to the idea of having one main application-window, which is 
quite often not the case.

The I/O-slaves is another example. Having an abstraction of I/O is great and 
this is something where KDE really exceeds other competitors, like Windows. 
But at least the current implementation DO have a few problems.

One problem that is often annoying me is the way I/O-slaves are pooled. I can 
often increase performance greatly, but when I discover I have an I/O-slave 
running on one computer, keeping a FTP-connection to some FTP-server, 
preventing me to log on from somewhere else, with no "simple" (yes, I do just 
kill it, but would the average user figure that out?) Neither do I know how 
to tell the FTP I/O-slave for one single server, to limit the amount of 
connections to one single connection.

Another issue I have with I/O-slaves is that if I using Konqi browse to some 
certain URL over, say fish://. I can see the files, I can view the files 
contents, but if I right-click a file and choose to open it using Quanta, I 
can edit the file and I can save the file, but the file won't be sent back up 
to the server until I close down Quanta. If I on the other hand just open the 
file using Quanta:s own open-dialog. Editing and storing the file works 
right-away, without closing or anything else.

I don't know whether the latter problem is a problem of the I/O-slaves, or 
something else. And I don't know if ANY of the problems are related to the 
architecture or design itself, but at the point of 4.0 beeing released, it 
MUST in my opinion be verified that such problems is NOT a result of the 
design/architecture, or the problems will persist for the entire KDE 4 series 
as well.

> >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).
Hehe, that might be a problem, yes. :)

> > 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.
Perhaps. Although a lot of the preparation work could start now. Even if Qt 
haven't released 4.0 yet, you don't have to look a long time at 
http://doc.trolltech.com/qq/qq09-qt4.html to realise that almost every single 
new feature is going to have a huge impact on KDE.

It's always good to come prepared. :)

Regards
/ Ulrik

- -- 
"I don't have to take this abuse from you -- I've got hundreds of
people waiting to abuse me."
		-- Bill Murray, "Ghostbusters"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA5UZN069SELtZwIkRAhziAJ4yPQlslNprkFaZFgtjqEY6attMRgCdEhqU
mN2Edgmn+yofIJrR1M+z9AE=
=VIdm
-----END 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]