Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
KDE 4 Set to Make Device Interaction Solid (KDE.News)
KDE.News introduces the Solid project, which aims to make hardware - especially mobile, wireless, and hot-pluggable hardware - "just work" with KDE. It will be part of KDE4.
"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."
The Solid web site has more information.
(Log in to post comments)
Duplication of hotplug frameworks?! Posted Jan 4, 2006 19:18 UTC (Wed) by cantsin (subscriber, #4420) [Link] I wonder to which extent the Solid framework will be a duplication ofhardware hotplug infrastructures that already exist on lower OS level in Linux, i.e. HAL, hotplug, udev. Most of what Solid aims to achieve (according to the project description on the web site) could as well be achieved with hotplug scripts.
Yet, Solid can't use hotplug, HAL, udev and related infrastructure because
Duplication of hotplug frameworks?! Posted Jan 4, 2006 20:32 UTC (Wed) by cventers (subscriber, #31465) [Link] Actually, according to the blog post from Kevin Ottens announcing Solid,it seems it won't replicate HAL at all: > And, what will this all mean to the developer? It means that the > features provided by different platform will be streamlined while > portability is kept by implementing Solid backends (currently only two > backends are provided a HAL one, and a fake one allowing unit tests). > It also means that all the building blocks to deal with the hardware > will be at hand, they just need to be used. http://ervin.ipsquad.net/index.php/2006/01/04/44-solid
Duplication of hotplug frameworks?! Posted Jan 4, 2006 21:01 UTC (Wed) by cantsin (subscriber, #4420) [Link] Which I guess means that Solid will be an abstraction layer on top of thevarious hardware probing mechanisms of Unix-ish operating systems (in the case of Linux, it would be an abstraction layer on top of another abstraction layer, i.e. HAL), plus code that depends on the abstraction layer. So it is designed to do for hardware probing what, for example, gstreamer does for sound and media playback. But with its design as both the abstraction layer _and_ KDE-specific desktop code, I'm afraid Solid will end up in a similar way as the Arts demon, i.e. an early proof-of-concept implementation that later gets replaced by a more universal, desktop-agnostic solution. Regardless my mixed feelings about abstraction layers upon abstraction layers, I would be more convinced if one development project would design and code a clean, cross-desktop, cross-toolkit hardware recognition infrastructure and a separate one would build the KDE desktop scripts on top of it.
Duplication of hotplug frameworks?! Posted Jan 4, 2006 21:10 UTC (Wed) by cloose (subscriber, #5066) [Link] desktop-agnostic solution HAL is the desktop-agnostic solution for hardware probing on Linux. To stay with your example, KDE4 won't use gstreamer directly either. There will also be an abstraction layer (codename kdemm) over the well-known multimedia systems (MAS, gstreamer, NMM, xine). This is actually the lesson we learned from aRts. So gstreamer = HAL and kdemm = Solid. :)
Duplication of hotplug frameworks?! Posted Jan 6, 2006 17:14 UTC (Fri) by hathawsh (guest, #11289) [Link] gstreamer = HAL and kdemm = SolidThose are curious equalities. I think you mean Solid is to HAL as kdemm is to gstreamer, or: Solid:HAL::kdemm:gstreamer
Duplication of hotplug frameworks?! Posted Jan 4, 2006 22:29 UTC (Wed) by Per_Bothner (subscriber, #7375) [Link] Which I guess means that Solid will be an abstraction layer on top of [HAL or some alternative].I hope they considered the obvious alternative: a HAL emulation library for other platforms. Or are the HAL APIs too unsuitable for non-Linux systems?
Duplication of hotplug frameworks?! Posted Jan 4, 2006 23:39 UTC (Wed) by elanthis (guest, #6227) [Link] HAL is itself supposedly OS neutral. It's just that nobody has bothered to write any other backends for it. Some Linuxisms have crept into its public interface, likely to the lack of alternative supported backends, but a BSD or Solaris backend should still be quite possible... assuming those OSes support all the necessary features for dynamic device probing.
Duplication of hotplug frameworks?! Posted Jan 5, 2006 5:57 UTC (Thu) by cventers (subscriber, #31465) [Link] The trouble is that you can't really ask these projects (KDE, GNOME) withvery different spoken goals and obviously unfortunate feuds to agree on entire implementations. There is a place for groups like FreeDesktop to make sure that the basic desktop functionalities are compatible. But when it comes to breaking new ground in far more advanced ways, we'd be poorly served as users if the projects had to first agree on everything. How stifling that would be! The best approach in specific instances like these, I believe, is natural selection. It's all free software - if KDE does a bang-up job with Solid, GNOME has the option of adopting it. Or they can roll their own. Or, perhaps, they'll decide that hardware abstraction isn't currently important. You see? There is a reason to let projects make their own specific systems after all :)
Duplication of hotplug frameworks?! Posted Jan 4, 2006 21:03 UTC (Wed) by cloose (subscriber, #5066) [Link] No duplication at all.(the following is of course "as far as I understand it") Solid will be an API/framework that offers features, like e.g. hardware detection and information, to KDE application developers. On Linux, it will use HAL as backend to provide those features. For other OSs, someone will have to write a specific backend. This actually increases portability because in KDE3 we use HAL directly.
Too much of a good thing Posted Jan 4, 2006 19:19 UTC (Wed) by scottt (subscriber, #5028) [Link] Different libraries for enumerating devices in Gnome and KDE plus the traditional way of storing device names in config files makes me want to cry ...
Too much of a good thing Posted Jan 7, 2006 20:29 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link] well, KDE and GNOME could use hal directly, but then they would be tied tolinux, and if HAL would change its ABI, trouble would arise - KDE insists heavilly on a stable ABI througout major releases (eg a KDE 3.0 app should work on KDE 3.5 without any trouble, and even on KDE 4.5 if the KDE3.xcompat lib is installed. gnome isn't that strict, but a changing ABI gives them headaches, too, i guess. so something between HAL and the apps would be needed. Solid is an library that provides a very Qt-like c++ API for KDE applications, and it'll keep the same ABI througout the whole KDE4 release. if Gnome would want to use Solid, they would have to rely on Qt, they would have to use c++ and they would be tied to KDE's release schedule. unlikely and useless... so - solid is a good thing, and shouldn't be used for anything more than it is meant to be used for :D
|
|
||||||||||||