“After a lot of hacking behind the scenes, a new initiative to improve KDE’s interaction with network and hardware devices has been launched. Solid will provide a robust basis for the dynamic modern desktop in KDE, which needs to be aware of available hardware and networks, paving the way for innovative functionality. Users should see KDE applications taking advantage of Solid in KDE 4, from the most basic Plasma applets and complex applications to desktop-wide awareness. Developers will be able to take advantage of a robust, flexible and portable API and will be integrated into the Plasma engine. It will make use of existing technologies like HAL.”
Lots of KDE fuzz lately. I wonder what triggered the increased media coverage. Linus?
Nah, it’s just the OSNews is pro KDE. (only kidding)
Seriously though, I just think that they are finally doing a better job of getting their news out and may have had more developments of late.
Lots of KDE fuzz lately. I wonder what triggered the increased media coverage.
There’s less GNOME news. Not more KDE news.
But anyway, I’m *really* looking forward to KDE 4; the individual projects (Appeal, Solid, etc.) are all very well defined, and if all they promise comes true, KDE will make a serious leap forward. The only danger I can see is that they will not follow whatever they’ve put out as predictions on the websites of those projects’ pages. That they’ll be unable to deliver what they’ve promised.
Only time will tell.
If I could mod you up for that I would.
I think it would be fair to say though that OSNews is covering more KDE news, although I sincerely doubt it has to do with anyone playing favourites. KDE 4 is going to be a huge development, and if Gnome people can get their news posted for almost every cool new feature they get, why not grant the same to KDE?
No, just the consequence of the very active development that is currently happening on KDE4.
So you can’t ask a question without people voting down your post. People are constantly abusing the voting system on OSNews. A shame, really.
Great! Device interaction is important!
IMHO, KDE is even more important than the kernel or even the underlying OS from a user’s perspective. Of course, the kernel does the low level work that must be done but from a user’s perspective the GUI is more important because of the letter I in GUI – interface. Many OS’s can do things, but how easily can they be done? Does the interface make things accessible? Do I need to research (google) every task I want to do or does the interface take care of it intuitively?
Not saying this is always the most important but for a general purpose user interface, it is.
Device interaction is improving rapidly in the Linux world. My Ubuntu desktop works well with usb, CD-ROM etc thanks to HAL and DBUS. But HAL is not really cross-platform and other OS’ may well implement their own, differing solution in the future.
So, this initiative is a logical development for KDE. It keeps KDE from relying on Linux only APIs and makes it much easier for coders to add support for dynamic services. In the end it will make for reliable, pervasive support for removable devices, which is good news.
Maybe one day I can plug my iPod in Windows, and a ‘native’ amaroK automatically syncs with it! One can always dream.
According to a post on the dot, Sun are working on a Solaris backend for HAL, and some other people are working on a FreeBSD backend. Further, it seems Solid will feature an abstraction layer, so you could develop a custom device detection backend instead of HAL if you wanted.
HAL and DBUS automounting are different from udev and hotplug automounting, right? Or am I just very confused?
As for Plasma, I thought Plasma was just their new display device to replace kwin+kicker+superKaramba into one shiny new interface. I guess they’ve got really great plans to roll it ALL together…
“KDE will make use of existing technologies like HAL” correct me if I’m wrong, but hasn’t gnome used HAL for sometime now? Also, how is dbus coming along in KDE? Are they transitioning to it, or do they still insist on DCOP?
I think I might try out KDE 4 when it comes out…
Edited 2006-01-04 20:35
correct me if I’m wrong, but hasn’t gnome used HAL for sometime now?
Both GNOME and KDE have been using HAL.
Also, how is dbus coming along in KDE? Are they transitioning to it, or do they still insist on DCOP?
D-BUS will be used in KDE 4, and there is < 90% of chance that it will replace d-cop. And “insisting” in d-cop is just a silly way to put a complex decision, d-bus is not so much better than d-cop, and there is a lot of code to port.
And if KDE developers decide to port to d-bus, it will demonstrate that the “not invented here” syndrom is not part of the KDE process. After all, then already:
1) Abandoned their sync code to support OpenSync
2) Dropped arts, and will provide flexibility, paving tha way for GStreamer (which BTW, is not there yet)
3) Are collaborating strongly in the portland (freedesktop) / osdl desktop architect forum.
4) Try to support GTK software (and other toolkits / languages) on the KDE desktop as well as they can (see the GTKQt theme, kprinter, kdialog and more recently, the RUdI proposal).
Therefore colaboration is going on nicely, thank you. KDE is “the inclusive” desktop, and they seem to reach out for the community even more than the GNOME guys. The GNOME solution for sharing desktop services seems to be “use GNOME/GTK” as the only option. The KDE guys look for solutions that keep everybody in the game.
Edited 2006-01-04 21:03
It’s worth pointing out that Gnome doesn’t really use DBus at all, despite many protestations to the contrary and the DBus FAQ which states “At this time, KDE has not committed to using D-BUS…or even changing DCOP’s implementation to use D-BUS internally (so that GNOME and KDE would end up using exactly the same bus)”. I really don’t see why the emphasis must be on KDE as Gnome hasn’t committed to adopting it either, but there you go.
Gnome uses it as much as KDE does, for things like communicating with HAL. Gnome fully using DBus would probably be more work than it would for KDE, and is why it looks as though they’ve looked beyond Bonobo to simpler options that won’t rock the boat and cause them to re-write things. It’s a huge amount of work.
As for KDE transitioning to it, I suppose it will depend on whether it’s actually good enough. It will also depend on how much slower it is as well. One of the aspects I’d be looking for is future proofing, and being able to do reliable and simple IPC over a network. You have to live with an IPC system for a long time.
GNOME uses DBus so do many GNOME applications.
GNOME uses DBus so do many GNOME applications.
You misunderstand the word using. I’m talking about using DBus in the same way that KDE uses DCOP rather than individual applications simply using it themselves. What does ‘GNOME uses DBus’ actually mean?
It means it provides an infrastructure for GNOME developers to exploit it if need be (e.g Epiphany, Gajim, Xchat-gnome etc all use dbus). It also means it is a core part of the desktop.
Edited 2006-01-05 09:42
It means it provides an infrastructure for GNOME developers to exploit it if need be (e.g Epiphany, Gajim, Xchat-gnome etc all use dbus).
Well no, they’re just applications. I have a feeling that your idea and my idea of what constitutes a framework for common applications differ.
Oh, then I am curious. What do you mean by “GNOME doesn’t use DBus?”
Oh, then I am curious. What do you mean by “GNOME doesn’t use DBus?”
I don’t know how he does, but here is how I see it:
I understand “DBUS” as a common interface for the desktop, one that is available for all apps, with a promise keep binary compatibility (just like the public API) in order to allow stable inter app/desktop communication, notifications, etc… allowing applications using other frameworks or even simple scripts to join the fun.
Currently definition holds for KDE/dcop, but not for GNOME/DBUS. The way GNOME currently uses DBUS, is the same way KDE currently uses it: in isolated places.
I understand “DBUS” as a common interface for the desktop, one that is available for all apps, with a promise keep binary compatibility (just like the public API) in order to allow stable inter app/desktop communication, notifications, etc… allowing applications using other frameworks or even simple scripts to join the fun
Your vision is wrong then. DBus is just a message bus system. It works at the system level to be desktop agnostic. But it needs to be integrated in each desktop : the DM (or login, or whatever logs you in) must launch a dbus for each user.
And the message bus system means it handles broadcast of info, and ACL. IIRC dcop does not provide that, you have to query the info.
The binary stability is a requirement for such a system. I don’t think DBus is ready yet for that, the latest 0.60 being ABI incompatible with 0.50.
Currently definition holds for KDE/dcop, but not for GNOME/DBUS
Thta’s not true, DCop is more like a remote control, DBUS is more than that.
And I have to disagree with you when you say DBus is not integrated in Gnome.
DBus is integrated with gnome-vfs, which is part of the Gnome framework, and with the notification system IIRC. So you can’t say DBus is not integrated in Gnome.
The way GNOME currently uses DBUS, is the same way KDE currently uses it: in isolated places
But depending on what these places are, you can say if it is integrated or not.
Integrated in a library (gnome-vfs, kio plugin) is not the same as just in an app (K3B).
Your vision is wrong then. DBus is just a message bus system. It works at the system level to be desktop agnostic. But it needs to be integrated in each desktop : the DM (or login, or whatever logs you in) must launch a dbus for each user.
OK, OK, I know what DBUS is. What I said is what i think “integrating DBUS” means.
That’s not true, DCop is more like a remote control, DBUS is more than that.
Wrong. dcop is much more than a remote control. It is much closer to DBUS than you seem to think.
DBus is integrated with gnome-vfs, which is part of the Gnome framework, and with the notification system IIRC. So you can’t say DBus is not integrated in Gnome.
Yes, you are right. I stand corrected. I can say that dcop is more integrated in KDE than DBUS is integrated in GNOME, but I can’t say that DBUS is not integrated in GNOME.
OK, OK, I know what DBUS is. What I said is what i think “integrating DBUS” means
You’re right then, but the DBus is still young and not stable enough to be integrated so deeply in a DE IMHO.
Wrong. dcop is much more than a remote control. It is much closer to DBUS than you seem to think
That’s very possible, I don’t know enough about DCop. But every example I see of it, even on article that promotes DCop (like we had recently) always show us the remote control like features, and the query features. But it’s true you can configure notifications very finely in KDE (with sound, messages, blinking bar, …), and perhaps that’s done through DCop, I don’t know. I don’t mean that DCop is not powerful, but everyone (including KDE developers) seems to agree that DBus offers more, and I can’t understand what that is.
What do you mean by “GNOME doesn’t use DBus?”
It means exactly that. Gnome doesn’t use DBus. A small collection of GTK applications, that might also be Gnome ones, use DBus. I think that shows the difference in philosophy of what a framework is.
Anyway, what is Gnome? Can you define it? Does Gnome use Mono?
It means exactly that. Gnome doesn’t use DBus
Why are you on a war against Gnome ?
A small collection of GTK applications, that might also be Gnome ones, use DBus
Wrong, gnome-vfs is not a GTK app (it’s a Gnome library with plugins) and it uses DBus.
You could say the same with Gnome apps that don’t all use GConf or gnome-vfs, but that would not mean that Gnome does not use gnome-vfs or GConf.
I think that shows the difference in philosophy of what a framework is
It doesn’t. You can bypass a framework (for different reasons), that does not mean it is not there.
Perhaps it’s still incomplete, and that’s why the framework limits itself to using DBus for communication with the kernel for now. Some apps start using it for notification, and you can be sure it will be integrated in the notification framework as soon as there are enough apps.
Anyway, what is Gnome? Can you define it? Does Gnome use Mono?
These are trollish questions, especially as the answers are on http://www.gnome.org.
And yes Gnome can use Mono through bindings. Python too. You should know better.
Wrong, gnome-vfs is not a GTK app (it’s a Gnome library with plugins) and it uses DBus.
Hmmm. I’ll rephrase it. Do Gnome applications get to communicate with other Gnome applications through DBus for free through a central Gnome framework? No.
GNOME is a desktop and development platform. From a developer perspective, DBus is an API for IPC-like mechanisms that allow applications to communicate with each other as well as themselves. From a user’s perspective it is a daemon that runs in the background.
If you start a GNOME session, DBus is one of core daemons that is automatically initialized. Not all applications need an IPC mechanism, consequently, not all GTK/GNOME applications should have to interact with DBus. But for applications that need such mechanisms, it is there and definitely a part of GNOME.
Thus, it is not far fetched to say GNOME uses DBus.
If you start a GNOME session, DBus is one of core daemons that is automatically initialized
Is that really true ?
I use GDM as DM, and until recently, I believed that DBus was launched automatically at each session start by gnome-session. It appears that was not the case !!!
I had no user DBus launched, and Evolution was silently complaining at each session start that it could not contact DBus. So, I had to patch GDM startup scripts.
If even GDM does not do dbus launch by default, I think that asserts that DBus support is still in the experimental state in Gnome.
For my distribution you have to add dbus to you startup scripts to use GNOME. Most other distributions do that for you automatically. Many GNOME apps will whine if you don’t have DBus running. I think its been that way since GNOME-2.10.
ut the framework is udev+DBus+HAL, it’s already there, but only for Linux.
From what I understand, Solid is there to add another layer on top of this, so that other framework can be used.
Because, for example, on Windows, Gnome apps lose a lot of appeal, as they can’t use a lot of technology present in Linux.
Thinking “Linux only” is the reason people don’t see the benefits of Solid (the “portable” thing).
People have same problems in other areas, when they think “american only” and so don’t see the benefits of Gnome features or Linux desktops in general.
There is alot of hype in the kde camp lately, but i think its a good thing. Historically kde has never been a hypemachine (though gnome has) and has imho been underhyped.
Whether they will live up to the hype is another question. They have yet to disappoint me, but still, plasma cant possibly turn out to be _that_ good.
This is goode news. KDE 4 will rock. The names are interesting, Plasma, and now Solid. They need to come up with a project and name it Liquid or something. However, Gas, or Vapour (or Vapor) would be a poor choice, eh.
Yes, there is more kde in the news lately, and I think that’s for several resons. Before, they (the devs) didn’t really promote and push the kde out into the media and news as much. Don’t know why. Also KDE 4 development is really starting to pick up now I think, which is great. Finally, as Thom said, maybe there’s less Gnome news.
Anyway, just to add to the d-bus vs. DCOP issue, AFAIK it is planned that d-bus will be the optimal method for KDE IPC. However, I think they are traying very hard t omake KDE 3 apps compatible to some extent, or at lieast with reduced effort and modification, with KDE 4. So, I think, part of this will be keeping DCOP for compatibility reasons. That’s what I’ve gathered from reading various things and mailing-lists. It could all change, who knows, since all the details regarding KDE 4 are long ways off from being finalized and complete right now.
Edited 2006-01-04 21:41
KDE does use HAL already, its just the induvidual apps won’t know it anymore… 😉
for the apps it won’t matter anymore if they use HAL or some other unix’ hardware abstraction layer.
and well, kde 3.x uses dcop. if DBUS can have a STABLE abi throughout the whole KDE 4 timeline, it can be used. but most likely, it won’t, so i think DCOP or some other in-between layer will be connected to DBUS. won’t be difficult, as DBUS is just a newer DCOP after all…
> As for Plasma, I thought Plasma was just their new
> display device to replace kwin+kicker+superKaramba
> into one shiny new interface.
kdesktop+kicker+superkaramba. the window manager and composite manager roles in plasma (if any) are still being worked out.
> I guess they’ve got
> really great plans to roll it ALL together…
well, you need to do something with that interface, right? =) plasma will be exposing Solid to the applets so that you can write an applet in, say, javascript to show and open your usb sticks or maybe bring network interfaces up / down.
If I understand this correctly this is some kind of hardware abstraction layer to make KDE portable.
Wouldn’t that mean that most KDE applications would need to link to it.
From the KdE Solid website I take it that this solid thing links to QT. As QT is GPLed so would Solid be GPLed. And if applicatons need to link with Solid they too need to bee GPLed.
This would mean that there will be only GPL compatible software for the new KDE4. This will not exactly make KDE popular in commersial settings, and we can expect the remaining KDE based Linux distros targeting commersial use will go Gnome.
Having one GUI API for developers like Oracle and other closed source developer to port applications to would probably be a good thing, but it would have been even better if the technically most elegant solution had been the winner.
AFAIK the “GPL-Only-For-Free-QT” requirement applies to everyone EXCEPT perhaps KDE – I think they have a special arrangement with Trolltech.
I believe much of KDE is licensed under LGPL, which in my limited experience, allows linking to non-GPL stuff…
——————————————————–
EDIT
Trolltech and KDE do have a rather special arrangement..see pages two and three of their updated agreement at http://www.kde.org/whatiskde/kdefreeqtfoundation.php
——————————————————
I’m no expert, but the LGPL is considered a valid OSS license, right?
Therefore, there should be no legal problems with Solid…
Edited 2006-01-05 03:36
> If I understand this correctly this is some kind of
> hardware abstraction layer to make KDE portable.
> Wouldn’t that mean that most KDE applications would
> need to link to it.
>
> From the KdE Solid website I take it that this solid
> thing links to QT. As QT is GPLed so would Solid be
> GPLed. And if applicatons need to link with Solid they
> too need to bee GPLed.
That situation is nothing new, really. All KDE apps have a dependency on Qt and thus fall under its license.
But one of your premises is wrong (“As QT is GPLed”): It’s true, Qt is available under the GPL but there’s also the closed source license option from Trolltech (and as a third option there’s also the QPL for non-GPL-compliant OpenSource software, but I’ll not go into this now).
The conclusion “so would Solid be GPLed” doesn’t follow either: Since the GPL and the LGPL are compatible Solid can and will be LGPLed (just like the rest of kdelibs).
So there are two options:
The Free Software one:
GPLed Qt + LGPLed kdelibs including Solid + GPL-compatible apps
and the Closed Source one:
ClosedSource-licensed Qt + LGPLed kdelibs including Solid + apps with any license their authors choose.
Note that the intermediate LGPLed layer of kdelibs / solid does not circumvent the GPL of Qt. It’s Qt itself that is available under more than one license. kdelibs are “neutral” from a license point of view. Neither do they add restrictions, nor can they remove any (the GPL has been designed that way).
Edited 2006-01-05 07:17
So there are two options:
The Free Software one:
GPLed Qt + LGPLed kdelibs including Solid + GPL-compatible apps
and the Closed Source one:
ClosedSource-licensed Qt + LGPLed kdelibs including Solid + apps with any license their authors choose.
But what non-GPL-compatible open source apps? BSD/MIT? Sorry for my lack of license wisdom here
But what non-GPL-compatible open source apps? BSD/MIT?
Also possible. You can use the QPL license for that. You just have to make the source available.
Ah. Of course. Didn’t read the OP carefully enough. Thanks.
If I understand this correctly this is some kind of hardware abstraction layer to make KDE portable.
Wouldn’t that mean that most KDE applications would need to link to it.
That’s why kdelibs exists and is LGLed, and like a good, well structured system I would imagine that KDE applications would not link to it directly. The interfaces and helper classes for it would probably be inside kdelibs.
From the KdE Solid website I take it that this solid thing links to QT. As QT is GPLed so would Solid be GPLed. And if applicatons need to link with Solid they too need to bee GPLed.
This only applies to things that use Qt and have Qt code in them. If you were to create a LGPLed project that doesn’t use Qt code, as long as it is GPL compatible, which the LGPL is, you can link in KDE and to Qt to your heart’s content.
People have this really strange idea that everything in KDE has to be written with Qt or you have licensing problems for absolutely everything because of the GPL. You don’t.
and we can expect the remaining KDE based Linux distros targeting commersial use will go Gnome.
I don’t see any distros going Gnome, except the few ones that already use it, and I don’t see anything being different should any distributions use Gnome more exclusively nor do I see it or them going anywhere. It’s their loss.
Having one GUI API for developers like Oracle and other closed source developer to port applications to would probably be a good thing
I don’t see any developers porting anything at the moment.
but it would have been even better if the technically most elegant solution had been the winner.
What winner would that be?
Well, as this has something to do with library things, I think it’ll follow the way shown by kdelibs. (which is LGPL/BSD) So there shouldn’t be any problems to use kdelibs if you have a license from Trolltech.
> Well, as this has something to do with library things,
> I think it’ll follow the way shown by kdelibs. (which
> is LGPL/BSD) So there shouldn’t be any problems to use
> kdelibs if you have a license from Trolltech.
Exactly.
This is all really good stuff though, really good ideas and I love the name (KDE doing marketing and thinking of catchy names!) and they’ve also come up with this recently:
http://ev.kde.org/corporate/twg_charter.php
Sounds like there’s some pretty good initiative being taken in the project.
>Wrong. dcop is much more than a remote control. It is much closer to DBUS than you seem to think
That’s very possible, I don’t know enough about DCop.
From various D-BUS and DCOP sources:
– D-BUS is a message bus system, a simple way for applications to talk to one another.
– DCOP is a simple IPC/RPC mechanism, to enable interprocess communication between KDE applications.
– D-BUS is intentionally pretty similar to DCOP,
They are more or less the same thing, intended for the same use. It’s usually said D-BUS is modeled after DCOP.
every example I see of [..] DCop [..] always show us the remote control like features, and the query features.
Which is only applied use of comunications with/between applications. And really all there is to it when applications communicate, either asking to do stuff or query about something.
you can configure notifications very finely in KDE (..), and perhaps that’s done through DCop,
Yes, the applications communicates with the notification daemon through DCOP. One of the simpler uses of DCOP. More complex use cases, are how Digikam can use K3B to burn CDs. Or how KMail/Addressbook can show on-line/offline contacts based on status in Kopete.
but everyone (including KDE developers) seems to agree that DBus offers more, and I can’t understand what that is.
As a technology it does not really offer more. D-BUS is a bit more complex than DCOP, and probably somewhat slower(from D-BUS FAQ). But it does offer greater opportunity of interoperability, which is always important for the KDE developers. One added benefit with D-BUS is the intergration you get with HAL(Linux only atm), giving access to mounting of devices etc. KDE already uses D-BUS for this, much the same as Gnome.
but the DBus is still young and not stable enough to be integrated so deeply in a DE IMHO.
Which combined with performance is the really important factors regarding replacing DCOP with D-BUS, or have some sort of side-by-side use as it’s done now.
To put stuff somewhat into perspective, regarding your statement of young and unstable. The first public release of D-BUS was in January 2003, development obviously started sometime before. While development of of DCOP started around 7-11 October 1999. And it was deeply intergrated and widely used in KDE 2, released 23 October 2000.
Edited 2006-01-06 02:53