Linked by Thom Holwerda on Sun 20th Jan 2008 11:11 UTC
At Google's offices in Mountain View, California, KDE 4.0's release event has ended. Various KDE people have given presentations, and a set of them has been posted online. Among them is Aaron Seigo's keynote presentation, which is very interesting to watch, and gives you a very good idea of what the KDE project is trying to achieve with KDE 4 (I just finished watching). Other presentations have also been put online.
Thread beginning with comment 296985
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Looking forward...
by segedunum on Sun 20th Jan 2008 23:18
in reply to "RE[3]: Looking forward..."
Member since:2005-07-06
For example if we look at KDE2 or KDE3 technology like DCOP or KIO, there are misconceptions about them being KDE specific things, i.e. somehow depend on KDE in the sense of linker requirements.
I'm not entirely sure what you mean there or what could be done differently. Arts was adopted basically because it wasn't KDE specific at all (DCOP and KIO are really), and other desktop environments could come in and use it, and what happened?
...and also if non-associated developers will be able understand this separation sufficiently to not turn away working solutions just because someone associated with KDE created it.
Well, that's more an issue for other people. As far as I can see, KDE's developers have been really open to DBus, as they moved to it, there's an event loop to hook into Glib and various other things to make interoperability better that have nothing to do with KDE and weren't developed by KDE people.
Many people have various non-KDE dependencies installed on their system, and no one really cares as long as things work well. However, I have seen more than one bug report where the basic premise is that all Qt and kdelibs dependencies should be kept off the system. Why don't you start with them?
RE[5]: Looking forward...
by anda_skoa on Sun 20th Jan 2008 23:29
in reply to "RE[4]: Looking forward..."
Member since:2005-07-07
I'm not entirely sure what you mean there or what could be done differently.
I meant that software developed by KDE developers is often assumed to be KDE specific whlile in fact it isn't. aRts is a pretty good example.
Arts was adopted basically because it wasn't KDE specific at all
It wasn't adopted despite not being KDE specific, but probably other developers thought it is.
(DCOP and KIO are really)
No, good examples of really entrenched misconceptions.
KDE's implementations of the two system of course are KDE specific, i.e. depend on Qt and KDE code, but since both technologies operate by communication of process through a protocol over Unix domain sockets, there is not tranfer of dependencies from one side of the communication to the other, similar to how it is possible for a D-Bus service to be implemented using one software stack and any client being implemented in any other.
Well, that's more an issue for other people. As far as I can see, KDE's developers have been really open to DBus, as they moved to it, there's an event loop to hook into Glib and various other things to make interoperability better that have nothing to do with KDE and weren't developed by KDE people.
D-Bus is a really promising incumbator for solutions to this problem, because it makes it more obvious that client and server implementation are in fact independent from each other.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-07
One area where KDE as a software project and developer community still needs to become better in is making the scope of parts of their work more explicitly visible.
For example if we look at KDE2 or KDE3 technology like DCOP or KIO, there are misconceptions about them being KDE specific things, i.e. somehow depend on KDE in the sense of linker requirements.
Both examples above are centered around the concept of communicating processes, where the actual interoperability constrains are in the respective protocol and where the implementation details of one side are shielded from them implementation details of the other.
It will be intersting to see if the KDE developers will manage to make this base requirements more visible and also if non-associated developers will be able understand this separation sufficiently to not turn away working solutions just because someone associated with KDE created it.