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. Solid will also include a knowledge base providing a way for users to easily provide feedback on incorrect behaviour.

Nobody can be certain yet as to how Solid will be used by developers, but according to Kévin Ottens, Solid project lead, "Solid will be a giant leap for KDE. For example, the desktop will be able to deal wisely with your computer hibernating. You'd want network interfaces to go down and for network-enabled applications to gracefully handle the disconnection; USB devices should be synced to avoid data loss". In the long run we can even imagine turning on a bluetooth video screen and having every multimedia application provide you with the option of remote playback.

Not all of the ideas described so far will make it into KDE 4.0, but with more developers for the APIs, the Plasma engine and the knowledge base web site, much more can be achieved. Application developers are also encouraged to experiment with Solid, which will help it mature faster. If you would like to get involved in this exciting area of the free desktop visit the Solid web site and get in touch with the team.

Notice the reverse definition they're using for portability: "Each platform providing the necessary Solid backends will be supported." In other words, Solid does not support platforms, instead platforms must support Solid. This is insane. Solid needs to examine how other crossplatform software has been written. Imagine how non-crossplatform Qt would be if Trolltech had this philosophy and left it up to Microsoft and Apple to do their own native ports.

I fully realize how difficult it is to make a crossplatform hardware/device layer. But when "Solid is specifying the features the underlying system must provide", it's doing nothing more than passing the buck.

What they mean (I think) is that the platforms will provide something like HAL on linux and then a backend for Solid will be developed for that platform using the available technologies, I don't think they are saying that on Windows or OS X that they would rely on microsoft and apple to do it, they are going to rely on the developers on that platform primarily (though probably many Solid developers will work on many platforms).

I think "Solid is specifying the features the underlying system must provide" means stuff like the OS must have some way for apps to be notified of hardware or network changes, preferably through means other than the app being forced to periodically poll the status.

perhaps clearer wording would be "Additional platforms can be supported by writing a Solid backend for that target." who actually does the work, which is what you seem to be hung up on, hardly matters. either a solid back end exists .... or it doesn't. =)

> But when "Solid is specifying the features the underlying system must
> provide", it's doing nothing more than passing the buck.

it's not passing the buck, it's defining the needs of the desktop. if those requirements aren't well defined, how can anyone be expected to fill them? this is how HAL originally got going (and why it didn't exist earlier): they sat down and figured out what the desktop needed and wrote code to fill those requirements.

so now we have a list of requirements. if a platform already provides those facilities it's simply a matter of writing a Solid backend for it. otherwise the platform needs to be improved first before Solid can be ported to it.

this is really no different than requiring a network stack to be able to use a network-centric app like kopete or requiring that the system (hardware and OS) offers hardware meters before you can show CPU temperatures in a GUI. =)

It seems that Solid is trying to specify a standard, but Solid isn't a standard. What if the underlying platform doesn't choose to accept the imposition of that standard? What if a platform decides it likes another desktop and decides not to implement any of those kernel features Solid tells it to? What if some kindly soul at KDE writes those features, but that platform won't accept them?

This is a concern to me for two reasons. First, I don't use Linux. Second, I refuse to use proprietary video drivers. Will KDE be fully functional for me? If not, I'll be moving to a different desktop.

a) Solid is an API for device/network detection and hardware information. It's features are provided through backends like HAL.

b) If the platform decides not offer any hardware probing features in its kernel, it's there problem, right?

c) If the platform does offer the needed kernel features, it just a matter of either porting HAL or writing a new backend for Solid. Solid neither specifies the implementation nor the API of those kernel features. This is all handled by the Solid backend.

d) I'm sure KDE will also function on platforms that don't provide the necessary functionality. You will just miss certain features.

This is why that quote is so confusing, because it is stating that the backends must conform to the Solid specification. In other words, a platform can provide sufficient hardware probing features, but Solid won't use them because they didn't follow the Solid specification. Hopefully that's not what their portability definition means, but that is how it is written.

p.s. Sorry about the video driver reference. I had recently read about XGL only supporting proprietary drivers, and I conflated the two hardware issues in my mind.

Well, if there are hardware probing features that don't do what Solid needs, then no it may not support the platform. If it's just that the platform doesn't do things in the exact same way as Linux does, then that's the purpose of Solid. Systems like solid and hal are just a way to let people developing application ignore the specifics of an individual OS, just like QT mostly allows you to ignore whether your app is for Windows, Mac OSX, or Linux.

Solid wouldn't be saying exactly how the platform has to behave, it just specifies what information it needs to be able to get somehow to work properly. Some OS's may be more efficient about providing it than others though.

It's the only way it can be done. HAL is a back-end, but the only way it can be used in different operating systems is if it is actually there - which is only Linux at the moment. There is a lot of OS dependant stuff when it comes to hardware communication. Likewise, Solid can only be used if the Solid backends are there.

Another way of wording this is to say that you port the necessary Solid backends to each platform and they will then be supported ;-).

> Solid needs to examine how other crossplatform software has been written.

Actually, take a look at GCC and most other cross platform tools and you will discover this is exactly how they work. Firefox is the same way, and so is Mono. I don't know about OpenOffice, but I would expect that to be the same, too. The proper way to develop any cross-platform application is to abstract away the differences, which means writing a driver for each platform that has a specified API, and any platform that provides that API should run the application.

Hi,
i'm a big kde fan but i'm wondering why there is the need for such a low-level library integrated in a high-level component : the desktop. I have the feeling that solid will be another layer on the top of hal and dbus and that the knowledge base will profit kde users only. I imagine this is not the purpose of the developers but the article sounds a bit like that.

Could you explain the need of implementing such a lib into kde if i'm wrong ? I'm not sure i've understood the whole thing.

An example use of this technology is that when you plug in your MP3 player, amaroK would recognize it and add it to the list of media devices. Without something like Solid or media:/, amaroK would have to depend on HAL directly (which is what Banshee does).

Really I would consider the DE to be part of the operating system, as it plays roles given to the OS in MS or Mac.

But the Unix desktop is NOT part of the operating system, no matter how often Microsoft and Apple tell you otherwise. The Unix model is an onion, with the desktop being a layer on top of lower level layers. Because of this, KDE can run on *ANY* Unix system with an X11 server. Yes, the desktop does need to access kernel services and other low level resources, but that doesn't mean you have to tightly couple the desktop to the operating system the way Microsoft and Apple do.

Right I'm saying the definition of "operating systems" now encompasses the functions of a DE. It isn't a stretch to say that providing to developers easy access to multimedia, hardware, and an HTML viewer are functions of an operating system. I'm not saying that this somehow means that DE's need to be unportable and stuck on a kernel.

I mean, if you look at the functionality KDE provides they are often because on the other platforms Qt resides they are already provided by the OS.

In a Java VM, you get the core interpreter, which basically knows about the byte code and the underlying OS. But no Java Runtime or SDK comes without a huge set of libraries (handling IO, ZIP files, GUI stuff), but Java would be long dead if it did not come with them. They are bundled with the JDK, but not part of the core system, and yet Java specific. some of them have OS-dependent back-ends too.
Solid will be that set of libs shipping with for a given OS, for KDE apps. And who knows, future may lead to have Gnome and KDE sync up on this topic too :-)

it's actually more of a "mid-level" library much like Qt is: it sits between low level (usually OS-specific, often non-portable) implementations and desktop GUI apps. this provides both abstraction (and portability) and a more friendly API.

this way a KDE app has exactly one API to deal with for hardware instead of one per platform. superkaramba, ksim, ksysgaurd and others have all duplicated efforts trying to achieve this for that one app to varying degrees of success.

as a bonus, the API is much like the ones KDE/Qt developers are already familiar with. they don't have to learn yet another API style, they can remain portable and start interacting better with hardware for a minimal time investment.