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. Read on for more...
Solid is an API for accessing device information such as available disks or networks. It does not deal with device drivers, leaving that to the OS. It does not deal with low level device information, leaving that to already existing, and very good tools such as HAL or other underlying subsystems.
Solid was introduced to the KDE world at large at aKademy, and the first signs of work were the appearance of its website. Since then it has mostly flown under the radar, with the odd mention here and there thanks to Danny Allen's Commit-Digests, or the occasional blog posting on the planet. If you visit the #solid channel at irc.kde.org (freenode), you'll find that it's sparsely populated, and mostly quiet. But appearances can be deceiving...
Solid's code base has been growing steadily for the last year and a half, with many parts of it becoming stable and usable already. In fact, things like Dolphin and the File Dialog are already using it in places to do removable storage management.
Internally, Solid is broken up into a variety of hardware domains, with each domain operating somewhat independently. For example:
One of the long term problems with UNIX ease of use has been access to removable devices. Many solutions have come up in the past, including kernel-based automounters (Mandrake of several years ago). HAL is the most recent project to tackle removable devices, and it does so quite well, but some distros still ship without, preventing across the board progress. KDE is building a generic API for removable devices so that applications don't have to know what's happening in the background. And by removable devices, I mean any removable devices, not just storage. Solid already does removable audio devices, laptop batteries and more...
Currently, the only backend supported is HAL, so removable devices will require HAL for KDE 4. Other backends for other OS's may be developed down the road, as HAL does not exist for every platform, but it should cover many of the more common UNIX platforms. One could even, if they really wanted to, write a backend that interfaced directly to the kernel.
It's not all just about removable hardware, but also about what is built into your system. Phonon uses Solid to detect available sound devices on your system, and can seamlessly switch between output devices, including hotpluggable sound devices. You may remember this from the demonstration in the Phonon article from several weeks back of switching audio devices on-the-fly. This is not just Phonon you're seeing, but also Solid providing the available device list.
There are other domains underway, including incorporating existing functionality from the NetworkManager Program into Solid so that more KDE applications can become aware of it. Most of the work will be done by a backend daemon that already handles ethernet and wireless ethernet (WiFi) connections, assuming the underlying drivers are available, and includes most forms of wireless encryption that exist. By the end of this week, VPN and dialup support should be available. We'll have to see what happens to KPPP as a result of this progress, but programs like this still have a role to play. The goal of this network work is to allow KDE applications to have a real implementation of an "offline mode", so you can read your mail, etc. without programs complaining about a lack of net connections. Will Stephenson suggests that cellular connections could automatically disconnect when no program is using the network, and so forth, and many other valuable applications will emerge as KDE 4 develops.
A third domain is Power Management, which is one of those areas on the Desktop where each distribution has done their own thing. Hopefully distributions featuring KDE 4 will present a more unified Power Manager interface. This domain presents an API that lets you configure and tune power and resource consumption of various elements within your system. This one is once again powered by HAL.
And very recently, Bluetooth support has been added. While it's still very young, it already allows device detection and connection. This is one I couldn't test, as I do not own a bluetooth device. :)
There is a very nice command line utility to interface with the various elements of Solid's API from scripts, or if you just want some manual control over your hardware. This program is called 'solidshell' and ships alongside the Solid libraries as part of kdelibs. An example command would be solidshell network set wireless disabled or solidshell hardware list details which will query HAL and return a list of all sorts of devices alongside some information about their capabilities. For those of you that have KDE 4 installed and want to test this feature, solidshell --commands is your friend.
Down the road, support for more devices within the Solid framework is definitely possible. I can imagine support for using additional input devices on-the-fly, or using Solid to detect changes in display (new monitor plugged in) so that it becomes easier to deal with X display settings on the fly. These domains are not yet a part of Solid, but with this architecture, they should be possible down the road.
How to help:
Kevin Ottens (aka "ervin"), the Solid lead developer, has a few suggestions for those willing to help Solid progress. The first thing he suggests is to use the API - the more applications that take advantage of Solid's features, the more complete the API will become. Also for developers, if you wish to extend Solid to other domains, or add backends for systems that are not supported by HAL, help is welcome.
Other ways to help include testing hardware, and reporting problems. Especially useful are reports of hardware that for some reason works in KDE 3.x, but doesn't work with Solid/HAL in KDE 4. If you find one of these, I'm sure the Solid developers would like to hear about it.
While there has been some adoption of HAL (a freedesktop.org project for hardware detection and more) by distributions, each distribution has (generally) in the past had their own implementation of hardware configuration and control interfaces. KDE of old had a policy of leaving hardware to the distributions, so this situation is partially one of our own making. However with the advent of HAL and now Solid, it is hoped that a more uniform system of hardware config and control will arise. Therefore, the KDE developers request that as distributions take a look at KDE 4 for adoption, they consider migrating their in-house hardware control solutions upstream into Solid, thereby benefitting all KDE users and making user support easier to provide by the community. The ongoing work of the distributions to make hardware better for their users is always appreciated - hopefully these new KDE technologies will facilitate collaboration.
Until next time...
Another great article!
Solid sounds very promising. One area where I would like to see Linux improve is power management. Linux (Kubuntu Feisty here) drains the battery faster than Windows. If I understand it correctly though the dynamic tick patch that's included in upcomming 2.6.21 kernel should help with that: http://lwn.net/Articles/138969/
What about the windows port of KDE4, if Solid can only manage unix-like systems?
What makes you think Solid can only support unix systems? It may be the case, that currently only support for unix systems is implemented.
But that's exactly why Solid is so useful. There only needs to be a Solid-backend for Windows (and OS X, and ...) implemented to make hardware-interaction reality for all KDE-appliations on that new platform. And that without changeing a single line of code in the applications.
I go along with you, there's no Solid-backend for Windows, therefore Solid can't manage Windows, therefore a lot of things from KDE4 won't work with windows, but It was said KDE4 will run with windows...
> but It was said KDE4 will run with windows...
Like the rest of KDE, it will only happen if contributors make it so. The major difference with respect to Windows between KDE 3 and KDE 4 is the licensing change for Qt which makes it possible to legally develop and distribute KDE software on the platform.
That's quite a leap there... Has it not occurred to you that the people porting KDE to Windows might, as part of the port, write a Solid backend? KDE's not due out for another six months or so, a lot can happen in that time..
No, it was said that individual KDE4 apps will be able to run on windows. Not the complete environment. This main focus will still be on unix.
There will surely be a Solid backend for windows sometime, but it might not be included in KDE 4.0.
and there will be lots of things that do work on windows even without solid functioning properly. same with phonon.
what you're missing here, and which has been touched on by others, is that this isn't a hand out. it isn't a hand-out on linux, bsd, solaris or the other unixes, and it won't be on windows or mac os either.
people working on the windows platform can write a backend for solid, a backend for phonon, etc. what we've done is made this _possible_. now it is up to the people who have this itch to start scratching it.
it'll happen, because it can happen.
Actually KDE 4.0.0 will probably only have a Windows beta released at most (thats what the word is).
KDE 4 is going to be with us for a while, all its features won't come at once!
If someone wishes to write a Phonon backend
for OpenAL, Windows or PortAudio, irrKlang
here's some documentation:
Windows Sound API:
#pragma lib "winmm.lib"
BOOL PlaySound( LPCSTR pszSound, HMODULE hmod, DWORD fdwSound );
BOOL successful = PlaySound("explosion.wav", NULL, SND_FILENAME | SND_ASYNC | SND_LOOP);
"open myfile.wav type waveaudio alias myfile",
lpszReturnString, lstrlen(lpszReturnString), NULL);
mciSendString("play myfile", lpszReturnString,
mciSendString("close myfile", lpszReturnString,
- http://www.portaudio.com/ for Windows, Macintosh (8,9,X), Unix (OSS), SGI, and BeOS
- DirectSound: http://msdn2.microsoft.com/en-us/library/bb219818.aspx
- USB devices are created dynamically in: HKLM\System\CurrentControlSet\Enum\USBStor\*
The solid webpage mentions a hardware browser. Has this program
materialized yet? I would like to try it out, but I have yet to
find such a program after building KDE4. Is solidshell right now
the only way to see what hardware is detected?
The hardware browser is still in Solid work branch where Solid work began.
I started the hardware browser but I left it because I have higher priority in KDE.
See it in http://websvn.kde.org/branches/work/kdehw/
It is 'solidshell --commands', not 'solidshell --comands'.
Copy-paste doesn't work that way. )
Heh - I was playing with solidshell in one X session (KDE 4) and writing the article in the other X session (KDE 3), so I wasn't copy'n'pasting. Which means it's just a typo on my part :) Maybe one of the dot editors can fix it :)
Hey, this article got pushed through to the dot just as I was in discussion with Ervin and Will about a few changes that took place during the Solid-Phonon sprint last week. So, while this article was accurate when I wrote it, some small changes have already taken place...
First: the term 'domains' has disappeared. Solid has been split into a hardware detection frame (mostly a KDE style API for HAL and friends) and a configuration framework that has just moved into kdebase. This was done to lighten kdelibs, and clean up the API.
And yes, this stuff is part of KDE 4 in trunk already, so you'll be able to snag it as part of Alpha 1 on May 1 (assuming no delays).
as now KDE is adopting more freedesktop standard ( DBUS, XDG ..) can you please write an article about how the next version of KDE will bring as enhassement to make other non qt application( gtk mainely) better integrated to KDE
because honestly it is a nosense situation to see that for example FIREFOX is better integrated to windows xp then to KDE
> because honestly it is a nosense situation to see that for example FIREFOX is
> better integrated to windows xp then to KDE
It is also a nonsense complaining with us. Please report to Firefox, thanks.
You are right here. However, it hits you with a certain surprise that key applications as firefox do not integrate well enough.
Not a KDE dev myself, but I'll repeat what was already said: Firefox isn't a KDE app, therefore not the responsibility of KDE.
Want a slap in the face? Run Firefox on OS X. That's a major surprise. :-> I've yet to get the Firefox Quicksilver plugin to work properly.
But back to KDE: I agree, I wish there were more work done to integrate GTK+ apps into KDE. But short of people patching GTK+ apps to work more closely with KDE, what should be done, eh? GTK+ apps also tend to be GNOME apps, which is a similar-yet-completely-different desktop designed to replace KDE, with some work going into integrating Firefox into GNOME (though it doesn't integrate well with GNOME either.) I don't think you'll see a KDE-friendly GNOME anytime soon, but that's my own opinion from the perspective of an outsider ;-D
The point of Freedesktop.org is to allow Gnome and KDE to work together where we can. HAL was created with the aim of making something useful for both desktops. Dbus is based on dcop, but the goal wasn't just to improve dbus, but to make something more useful for Gnome. There are many other little things going on there.
KDE and GNOME disagree on things like keyboard shortcuts. Both sides of excellent reasons behind their defaults, so it is unlikely we will ever come together.
Toolkit issues (gtk vs qt) are trivial to work around. A lot of effort is going in in this. Have you noticed that copy and paste works a lot better between applications now? That is because freedesktop.org defined how it should work, and the toolkits all do the same thing now. Expect to see more in the future - but only where there is an agreed upon best way. When there are two equally good ways of doing something we are better off if the two desktops go their own way (yet attempt to work together in everything else)
There is the GTK-QT theme, and there are ways to easilly use the KDE filedialogs in those applications (note, from gnome, there are no ways I know off to do the reverse). Aside from that, tell me what specific things you expect from the KDE developers? Most work for integration will have to come from the firefox (or other app) ppl...
"Aside from that, tell me what specific things you expect from the KDE developers? Most work for integration will have to come from the firefox (or other app) ppl..."
integrating with KDE4 GTK-QT for example.
Ubuntu uses Gnome, gnome apps are popular. Also users from windows now Thunderbird, Firefox etc and will use them. So it is important to show gtk in KDE as much consistient as it is possible.
integrating with KDE4 GTK-QT for example.
Yes, this theme is written by a KDE engineer to let Gnome apps fit in the KDE environment. You can find it (if installed) in Kcontrol: style and look of Gnome apps -> let Gnome apps use my KDE style. It's lovely, that's why I mentioned it... and it would be indeed great if it where ported to KDE 4.
Anyway, I wouldn't say this is something that is lacking - it's already there, not ported yet but there is no reason to not expect it to be ported, I guess. And such a theme doesn't exist on the gnome side, you can't let your KDE apps look like gnome apps. That's why Trolltech created the clearlooks-for-Qt4 style, to make KDE apps look like gnome apps. Qt 4 even automatically reverses ok/cancel button order when run in Gnome (again, gnome apps don't do such a thing). Trolltech also made it possible to plug GTK code in KDE/Qt apps, maybe in the future KDE apps will use gnome filedialogs (poor users...) when running in Gnome.
In other words, most integrative work comes from KDE/Trolltech already.
Now, as I already mentioned gtk-qt, anything I did NOT mention, and which is NOT being done, and which CAN be done by KDE in a reasonable time, which you would like to see?
> there are ways to easilly use the KDE filedialogs in those applications (note, from gnome, there are no ways I know off to do the reverse).
Ages ago KDE published some proof-of-concept work to allow GTK+ apps to access the Qt main event loop, allowing them to use KDE/Qt dialogs: http://dot.kde.org/1073668213/
Looks like nobody was interested.
And now, Qt4 uses the glib main loop.
no it doesn't. qt4 still has its own event loop. but you can now integrate a glib eventloop into a qt4 application.
*no it doesn't.*
Yes it does. Copy and pasted from qt 4.2 configure script:
-no-glib............ Do not compile Glib support.
+ -glib............... Compile Glib support.
Glib support means, using the Glib event loop
i had got a lot of expectation from the next KDE, i thought it will be independant from any particular OS,any particular language, independant from engines( xine, gstreamer etc)and even of course it use QT as the main toolkit, other toolkits as GTK, java or whatever will get the same love. i.e; integration using some open standard
we users, we just want applicationn we don't even care/know what is the toolkit used, we are just fed up with all those stupid Kde vs Gnome, GPL QT vs LGPL GTK
ok perhaps i am just a stupid dreamer.
@superstoned hi man, opensuse rock
well, thats just you.
what you want is totaly impossible. where did you ever read kde4 would do this!?
users should learn that allready care. they want features. features don't come out of nowhere....
I would be very happy to have GTK apps to support the KDe toplevel menu mode.
Anyway, on kubuntu feisty you don't really see a difference anymore. It is like people see a crystal theme and think its a KDE app etc.
The about window is different for GTK apps but that's all. And the rest is integration.
Sorry, but do you have any idea what a toolkit is? it's like bricks, you use to build an application. If you want to change the type of bricks a house is build upon, you must rebuild the house. So is Qt in KDE - you can't remove it, that's just totally impossible.
KDE 4 is independant of a OS, sound engines, language, hardware, but not of it's toolkit - that's just not possible.
KDE has gone out of it's way to integrate gnome apps in KDE - Qt can indeed use the glib event loop so you can use gtk code in KDE apps, Qt 4 automatically reverses the button order (cancel/OK) depending on it's environment, non-kde apps can easilly use the KDE file dialog (so when they detect they're running in KDE, they could use that) and there is the GTK-QT theme which hopefully will be ported to KDE 4, which lets Gnome apps use the KDE style, colors and icons. Qt even has a style similair to the Gnome Clearlooks style, because the gnome ppl haven't offered something like the GTK-QT style to integrate KDE apps in Gnome.
So KDE has done it's part, imho. It won't solve the flamewars, ppl just love to hate things, but I don't think end-users ever really cared about the difference between KDE and Gnome apps. On windows, you have far more styles and weird looking applications (eg compare IE7 with MS Word 2007 with MS Outlook 2007 with Media player 2007 with the latest messenger with notepad and you've got such a mess it's hard to believe - still windows users never complain. Same with mac, which has had a pletora of different styles in mac OS X, nobody cared).
eh ok i am not a developer, but i know what is a toolkit, i even used java swing when i was at university.
suppose i am new ISV to linux desktop, i want to develop a closed source software under linux and i don't want to pay trolltech for using the commercial licence for whatever reason ( anyway he already don't pay microsoft for developping software under windows) so what's the answear ?
i see KDE, as THE DESKTOP for linux, not one of many DE, so any enhassement to make GTK even better integrated it is welcome, after all it is a free software.
windows development isn't free. you have to buy a windows license at least. if you seriously want to make windows apps you also will buy visual studio, and if you have more than a hand full of developers you will pay for msdn.
For any non-trivial project the effort of doing what qt does automatically will cost more (as in $$$ you pay your developers to create the same thing) than then buying qt licenses.
Developers know this and keep telling non-developers this, but it never seems to sink in. No I don't work for trolltech. I am a developer though, and trolltech has done large parts of UI work that I find boring. (OTOH I get excited about individual bits on a wire, where I'm sure the trolltech guys would be bored out of their mind)
Well, I'll put up a vote for scanners as a hardware 'domain' to be added to Solid, but I'm not seeing it happening until 4.1 :-)
I am no friend of HAL. KDE is adopting a lot of material that has it seeds in the GNOME area. HAL is no solution at all - making it hard getting KDE or GNOME stuff ported to other operating systems.
And the reverse is happening as well. DBus is definitely inspired by dcop, and in most projects the 2(+) groups create the stardard together. HAL is meant to be portable to non-Linux OSes (even though afaik most ports don't exist yet). Fortunately Solid doesn't DEPEND on HAL, HAL is simply a backend for it, so that way if something better comes along, KDE can dump HAL in a heart beat and not break the API/ABI as well as not having to rewrite any applications.
I really don't care which camp comes up with or seeds the ideas, just getting cooperation between the camps on the stuff that has pretty much only been different for the sake of being different (the icon naming scheme is one example).
Also to address your last sentence, Solid using HAL as a backend on platforms with HAL available won't make it any harder to port KDE apps to different platforms. All it'll take is 1 person making a Solid backend for the platform and then the porting is done, instead of having to port all the hardware related stuff in EVERY single KDE app one at a time (not to mention all the developers having to reinvent the wheel for each platform).
Exactly. Solid and Phonon make it possible for KDE apps to not depend directly on HAL etc to get the job done on other platforms, whereas GNOME made the pragmatic decision to tightly couple to HAL, gstreamer, NetworkManager etc.
HAL itself is an abstraction layer portable to other platforms.
yeah, and how many does it support? Windows, Mac OS X, BSD and Linux, I suppose?
Linux, freebsd and solaris. More if you send patches.
That wasn't his point. The problem is, that you can not port HAL on every architecture and you can not simply sent in patches. As if things were that simple. Not every architecture shares the same metaphor or philosophy in doing things. And a lot of systems simply have their own HAL, there is no need to duplicate efforts.
Not sure what your point was. Are you saying Linux doesn't need a HAL because other systems have a HAL? That makes no sense.
As I understand it, Solid is a layer between HAL and KDE, so it could work with other HALs, I'm sure. iirc Phonon works on OS X now, so it wouldn't surprise me to see KDE apps on OS X dealing with plug-and-play events.
I wholeheartedly support taking KDE back to simple days of Sinclair ZX. I already cannot run KDE on my TexasInstruments 83 calculator... Now, it seems I will need to upgrade the video card in my e Nintendo Famicom just to be able to see shadows in KWin. Progress sux!
Note Kwin-with-composite can use OpenGL acceleration, but it'll run almost equally well with just XRENDER (eg simple 2d acceleration). Unlike compiz and beryl, I must note.
How dose that work? dose it automatically detect if you can support OpenGL acceleration or dose the user turn of the 3d effects?
Last I checked, it was just a matter of having a good sequence of fallback mechanisms... so if openGL was there, it did things in openGL -- if it isn't there, it tries using XRender for those effects that can be supported that way, and disables those that absolutely require openGL... and if XRender isn't available, it drops down into plain old kwin that everyone already knows and loves... :)
So, because HAL wasn't invented by KDE, KDE shouldn't use it as a back end? You're kidding right? KDE should just use the best technology for the job, whether that means making it "inhouse" or using existing technologies from elsewhere. Furthermore, KDE seems to have taken an approach of adding an additional layer of indirection to on the one hand provide KDE applications with a consistent and easy to use API, and on the other hand not become too dependent on any single outside system at any time. I think that is a good approach, even if the "just writing a new back end" may end up being harder than it sounds or never takes place.
HAL is one possible backend, and the only one currently available. There is nothing preventing one from writing a Windows (or other) backend for Solid. Its also possible to port HAL to other OSes. Solid should greatly ease cross platform compatibility, not hinder it.