Submitted by “One of the many new technologies for KDE 4 is the often mentioned, but seldom explained Solid hardware API. Hardware has always been a bit of an annoying element of using Linux and other UNIX-like operating systems, but Solid hopes to fix that for KDE 4. In many ways, Solid is like Phonon, in that it’s a Qt/KDE style API around already existing components at the lower level, such as freedesktop.org’s HAL. It is already quite functional in the backend, and it’s already affecting visible KDE components.”
If I understand it right, Gnome already does this, as it directly uses HAL, am I correct?
Dave
Well, partly. KDE is directly using HAL too for some operations. What Solid does it that it wraps the stuff into a nice API for application developers to use. For an example if an application wants to know when some device is plugged in it doesn’t have to poll the device or to use HAL directly. This allows far more easier way for developers to achieve new functionality without duplicating the code. And besides that it hopefully will be cross-platform in the future, even though HAL may not be ported on those platforms (I can imagine at least MS Windows, OS X, which aren’t going to have HAL backend perhaps ever).
Sounds like duplicating to me, why not just make HAL better and easier to talk to, and talk to it directly? That makes logical sense to me…
Dave
HAL would need a proper C++ layer anyway, it’s just that solid adds to this layer also win and Mac OS X support and some other minor features.
Also, it makes KDE independent of binary incompattible changes in HAL.
Fair enough, that makes sense. Shouldn’t HAL have been written in C++ then in the first place? I’m no programmer, but I understand that C++ is better for that sort of thing. Whether that’s true or not, I have no idea, so feel free to correct me.
Dave
To be honest, I have no idea either – C++ is supposed to be a more efficient programming language, so that would make sense. But I don’t think that’s the point anyway – the reason it’s C is that Gnome uses C, and it was mostly initiated by the Gnome project (not exactly true, but this is what it boils down to).
So write it in C++, and gnome has to write a layer. Write it in C, and KDE must write a layer…
Anyway, even if KDE could just use HAL, they would prefer a KDE-like API (application programmers interface) so they would most likely write a layer for it in KDElibs anyway. This is also for example the case for D-Bus, and even more or less for strigi (which is written mostly for KDE, though desktop independent and written in C).
These layers are much more common than you might think, and they aren’t bad at all – it’s not THAT much work (well, it is in case of solid, because they don’t just wrap HAL, but also network management and much more, and HAL-independent) and doesn’t really slow things down, while it makes programming easier and more efficient.
So write it in C++, and gnome has to write a layer. Write it in C, and KDE must write a layer…
No, the language HAL is written in does not affect the languages aviable for HAL clients since there is always D-Bus between them.
However, using D-Bus directly, i.e. through one of the bindings, is not as nice as using a library which hides the communication.
Such an API for C is provided by the HAL project, called libhal.
A C++ program that does not use D-Bus for anything else could also use this library just like it uses other libraries with C-APIs, however if the program uses D-Bus for other means as well, it will have more control over its D-Bus connections if all such connections are handled by the same bindings, so in this case it would make sense to build your own variant of a HAL client library upon the D-Bus bindings used elsewhere in the program.
Additionally, mapping the data transported over D-Bus to your data structures is likely to be more efficient than having libhal map them to some data structures and then map those to yours
This is also for example the case for D-Bus, and even more or less for strigi (which is written mostly for KDE, though desktop independent and written in C)
D-Bus is a pretty good example, since no D-Bus are generally built directly on the core library and are not using any other binding underneath (e.g. Java bindings are directly implemented in Java, not through wrapping the C/glib bindings)
But as a correction to what you wrote, Strigi is written in C++ (plain C++, no dependency on Qt)
tnx for the info, I’m no hacker, so the details aren’t always perfectly clear for me
and I KNEW strigi was C++ just forgot…
Sounds like duplicating to me, why not just make HAL better and easier to talk to, and talk to it directly?
That’s the idea. C developers use libhal to talk to HAL, KDE developer user Solid.
One also gets better control over the D-Bus connections since all connections now use the same bindings.
That makes logical sense to me…
Exactly! Why would one want to talk to HAL through two layered APIs if you can make your API talk to HAL?
Or are you suggesting to directly use D-Bus in all applications and not use a convenience library?
I dont get it, why would Windows or OS X want HAL when they have there own HAL(Hardware Abstraction Layer). To me this seems that KDE are trying to reinvent the wheel when HAL do a good job and is userspace.
Seems to be another layer we dont need, even if it’s small code base like Phonon.
Edited 2007-04-25 23:57
the point isn’t to put HAL on Windows and OS X. the idea is to write backends for Solid that uses the native facilities on those platforms (same for other supported OSes that don’t have HAL).
this is just another benefit of Solid: portability. and that covers both between platforms that exist today and changes to current platforms that will occur in the future.
I dont get it, why would Windows or OS X want HAL when they have there own HAL(Hardware Abstraction Layer).
Exactly right.
To me this seems that KDE are trying to reinvent the wheel when HAL do a good job and is userspace.
Unfortunately you (and a few moderators) completely misunderstood what Solid is. The whole point of Solid is that not every platform that KDE runs on has HAL. So using HAL directly is not optimal. With Solid, people can write applications that take advantage of hardware discovery and all that without caring about whether the system uses HAL or the windows hardware layer underneath.
Edited 2007-04-26 01:20
eems to be another layer we dont need, even if it’s small code base like Phonon.
Well, even the HAL developers think there is a reason to have such a layer, i.e. a convenience library libhal which translates between the D-Bus API and a C-Style API.
Sure, using D-Bus directly through the various bindings might work as well, but it requires some understanding of D-Bus concepts and adding a convenience layer on top of this will make the life easier for those who do not want to go as low level as D-Bus bindings
> Gnome already does this, as it directly uses HAL,
> am I correct?
gnome and kde3 both use HAL more or less directly for these things.
solid brings portability to the table as well as a very easy to use API that makes it absolutely trivial to do things like find out how many cpu cores are available (think of matching a thread pool to the # of cpu’s in 4-5 lines of code), being notified when devices or network status change, querying the system in pretty generic ways for hardware capabilities, getting details on hardware components, and sending common commands to these devices such as mounting, unmounting, ejecting, enabling networking, etc.
while HAL, networkmanager and powermanager made it possible on one set of systems, Solid makes it *easy* and provides a way to do the same on non-HAL/etc systems.
solid also encompasses things like process listings and bluetooth
take a look at the examples in kdelibs/solid/examples to see just how easy it all is. =)
the likely result: we’ll start to see all kinds of hardware and system awareness features pop up in applications because it’s easy to do. possible isn’t good enough, simple and consistent is also required to make something pervasive.
What non HAL systems are we talking about here, I think must people are confused because your no talking on a level with desktop users.
I guess alot of people know, GNOME Volume Manager and kioslaves as the desktop layer of HAL, HAL is bing ported to BSD and Solaris and already has “Portability”
Surely it’s easy for Windows/Other systems to make applications to do what Solid does anyway?
Look at it this way – every kde app could create it’s own hw management code like this:
#ifdef WINDOWS
use native ms hw management
…
…
…
#ifdef HAL
use hal hw management
…
…
…
#ifdef OSX
use apple hw management
…
…
…
#else
put up an error???
Or, it could just do this, which uses the exact same code we spelled out manually above:
Solid.NotifyMeOfWhatever();
Making a bunch of somewhat complicated code into a simple and portable library makes it much more likely to be used and much less likely for the end user to encounter bugs.
On top of that, every time HAL is updated every single kde app would need to be modified and tested to make sure everything still worked. Now everything is located in a single point of failure, and can be updated/tested all at once. Maintainers of the apps don’t have to worry about it anymore because the HAL experts are taking care of it all.
Edited 2007-04-26 02:29
“What non HAL systems are we talking about here, I think must people are confused because your no talking on a level with desktop users.
I guess alot of people know, GNOME Volume Manager and kioslaves as the desktop layer of HAL, HAL is bing ported to BSD and Solaris and already has “Portability”
Surely it’s easy for Windows/Other systems to make applications to do what Solid does anyway?”
Not by my understanding. A lot of the new APIs that are coming with KDE 4 aren’t about munging around with the hardware, but about providing and abstraction layer above the native OS level.
Think of it the way– maybe not for KDE 4.0.0, but for say KDE 4.1 there may very well be a solid backend for Windows (and/or Phonon, and/or whatever). It’s not about using KDE to configure your DHCP connection with your cable modem, it’s about Kmail or Konqueror or Kopete being able to gracefully figure out if they can connect to the Internet or not. It’s not about configuring you flash based mp3 (or Ogg) player, it’s about Amarok being able to get files on and off the thing. It’s about developing KDE apps with KDEish APIs. It’s about platform Independence. It’s about NOT BEING WED TO SOMETHING LIKE THE ARTS SOUND SERVER FOR THE BETTER PART OF A DECADE.
“What non HAL systems are we talking about here”
OpenBSD is one, Windows another. There are probably more that I am not aware of.
“HAL is being ported to BSD and Solaris and already has “Portability””
Porting HAL is by no means easy. I’ve looked into porting it and after reading the specification it’s my impression that it’s convoluted and over engineered. An easier way is to just implement the HAL dbus interfaces but this is still no small task. (And not something I personally want to do)
“Surely it’s easy for Windows/Other systems to make applications to do what Solid does anyway?”
Sure, with the disadvantage that every application needs to be aware of every OS’ way of doing things.
The point is that you can use the same api in both the linux/bsd/etc. and windows/macosx version of your application to do these things.
I like the way the KDE seems to be done: less design-by-commitee and more internal elegance. Maybe their interface is by programmers and for programmers, but the internal workings of KDE have always seemed to be quite good. And they don’t seem to have a problem with reinventing the world (i.e. not using stuff that’s sorta broken and instead just rewriting an area until it works).
What I’d like to see (though I’m a nobody and my opinion really doesn’t matter) is for the KDE developers to make an entire desktop distro in their vision. Take the latest stable version of XOrg, the KDE configuration panels, a stable and recent kernel, one of the popular package managers, and fill in the gaps with purely KDE technology. If they have the manpower, I think the K folks are in the best position to reduce the splintering that happens because the Linux desktop is cobbled together from so many loosely-coordinated projects. It’s better to have 1 vision than 20.
I think that’s a fantastic idea, although I’m sure many of the KDE devs are working very hard as it is.
They can only do so much. But an actual KDE Linux distro would be along the lines of a mac or windows……. as opposed to (this distro over here) which happens to be KDE based………….
I think KDE’s strength has been distro independence. It’s reasonably self-contained and fairly simple to compile/package, which is why it is generally the default DE of choice for smaller distros where resources are limited, in addition to being supported by the mainstream ones. KDE4 now brings a degree of platform independence as well.
The nice thing is the consistency it offers. You can generally get a consistent KDE experience across any *nix platform. It’s up to the distros to better integrate KDE into their platform if they choose to, it shouldn’t be the KDE devs doing so. If you look at the job leading KDE distros like openSuse, Mandriva, Kubuntu, PCLinuxOS etc. it’s hard to see the advantage of KDE devs doing themselves, let alone the resources it would take.
Sort of along those lines, I think the thing that is most impressive with KDE4 is the forward-thinking they’re doing with all of the different abstraction layers and frameworks. Yes, the Gnome folks tend to think this is bloat. Just use gstreamer, what’s the point of phonon… Just use HAL, what’s the point of Solid… Ignoring the fact that KDE4 is also being presented as an application framework for non-*nix environments, something many people seem to frequently overlook, I suspect those advantages will become even more clear over the next few years as KDE4 matures and is able to rapidly adopt and integrate new technologies as required across different platforms, with minimal tear-down/rebuild required. That’s the sort of thing that will also address the splintering and controlled chaos you’re referring to.
Counting on applications being able to “just work” without caring about the state and support of various underlying subsystems, or even the host operating system itself, will be a substantial advantage for users and developers.
Personally I think it’s a little bit sad that most of the time KDE4 has come up over the past few months, people tend to want screenshots or to see wobbly plasmified windows beaming across an SVG rendered screen, totally overlooking the impressive foundation being laid with the other components so far. I guess the irony is that the success of frameworks like solid and phonon relies on average users not needing to be aware of or to even know anything about them.
Oh well, the geek in me is fascinated, even if others are just waiting for plasma and oxygen. It’s good stuff even if I can’t see it.
This is a decent idea actually. Funny thing is your final line
This is partly why I use FreeBSD combined with KDE as my OS/Desktop of choice. FreeBSD to me is what I wish Linux was. Don’t get me wrong Linux is fantastic for many but for me I like how the FreeBSD system is organized, base system is separate from the ports. KDE to me is very much like that, with the same sort of organization within the underlying code, streamlined and clean.
But that’s just my random off-topic rant.
Creating a new API is not the same as “not invented here”. Think of it as defensive cooperation.
Qt/KDE has its own set of APIs, and these APIs have a certain design philosophy and a certain personality to them that is (in theory) consistent. The API and ABI may remain stable, and the specific behavior and documentation of the API may be tweaked to fit the system. The developers of Qt (and KDE by extension) are largely in control of their ecosystem, and this control is what allows the consistent design.
By writing something like Solid the KDE developers are incorperating the work of other people. They aren’t rewriting HAL, they are using it. But since HAL is a dependency that is outside their direct sphere of influence, they are creating a go-between (the Solid API) that allows them the freedom of stability (as well as the freedom of portability beyond what HAL offers, on top of yet other possible advantages).
They aren’t really reinventing the wheel; they’re just making sure that their wheel will behave in a manner that is controllable by them, to fit the whims and needs of their respective projects. It also allows them to cast off restrictions to these lower level dependencies on platforms they are not present on.
I think it’s a good idea to do up front on a big release like 4.0, and the fact that their developers are pretty excited about what looks to the user as KDE 3.5 ported to Qt 4.0 reflects the fact that these APIs are coming along and are opening up exciting possibilities.
I’d also add to the above that KDE is not just using Solid as a buffer against HAL being outside of their control (or the same with Phonon and xine/gstreamer/NMM/etc) but it also future proofs the API to a degree. If some new technology comes along that is better/faster/gooder/whatever on any of the platforms KDE runs on then a backend can be written, shipped and used with out the apps even knowing anything changed.
Edited 2007-04-26 18:55 UTC
Could this kind of API abstraction be used to create an alternative to Direct X for FOSS and other systems, such as game consoles? I really think that if this kind of API abstraction is possible for KDE why not for the entire FOSS ecosystem with regards to an API for gaming? Wouldn’t the hardest part be having to basically write an independent toolkit that would be compatible with everyone from FOSS to Apple to Sony and Nintendo? I’m just user with no real programming skills so maybe I’m off here.
I mean think about how many resources could be saved by Sony, Nintendo, and Apple by sharing the same basic gaming API. I guess it wouldn’t necessarily have to run with zero porting to be effective either. It just needs to make porting cheap enough to make it worth it. Also this could be used to reinvigorate OpenGL and as a basis for future desktop effects etc.
I think that’s what SDL is supposed to be, isn’t it?
SDL and openGL if you want 3D.
sadly it seems that with DX10, microsoft is telling the GPU companys to jump rather then the other way round. just look at them talking about being DX10 compatible, ugh…