"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."
Post a Comment
Member since:
2005-08-07
Member since:2005-07-06
Member since:2005-06-29
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.
Member since:2005-06-29
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?
Member since:2006-01-02
Member since:2005-08-07
Member since:
2005-11-11
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.
Member since:
2006-01-01
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.
Member since:2005-07-06
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.
Member since:
2005-08-28
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...
Member since:
2005-11-05
"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
Member since:2005-07-06
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
Member since:2005-07-06
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.
Member since:2005-06-29
Member since:2005-07-06
Member since:2005-06-29
Member since:2005-07-06
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.
Member since:2005-06-29
Member since:2005-07-06
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.
Member since:2005-07-06
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?
Member since:2005-11-14
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.
Member since:
2005-11-13
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.
Member since:
2005-07-06
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
Member since:
2005-07-07
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...
Member since:
2005-07-06
> 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.
Member since:2005-07-06
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
Member since:2005-07-07
> 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
Member since:2005-09-08
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 
Member since:2005-07-06
Member since:2005-09-08
Member since:2005-07-06
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?
Member since:
2005-07-06
Member since:2005-07-07
Member since:
2005-07-06
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.
Member since:
2005-07-06
>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
