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.
Honestly this is a core misconception of the Linux Desktop. You cannot leave low level stuff to distributors or set your desktop environment on it in an abstract manner.
It is time for the desktop environments to get into the dirty low-level stuff because only desktop environments can unify the mess the distributors diversity created.
The plan for Solid appears to be addressing all the weaknesses of media:/. KDE4 is going to freakin' rock.
yes, it's certainly the "natural" evolution of the media:/ concept. massive kudos to ervin.
there's also "alpha" code already in svn for solid =)
I dream of a day when all distributions will disappear. Thanks to Solid, we won't even a hardware control center, everything will work perfectly with zero configuration. For example, as I plugged in my Speedtouch USB Modem, KDE tried to copy my configuration from Windows, username, password and provider, but I won't have Windows, so from my local settings, KDE will pick my country by default and ask me to fill in two fields, username and password, also in a list, there is the list of all countries, but because KDE knows where this modem is generally used, it put those countries before any ( Yeah, If I press Ctrl and click on any region of the windows I can have access to very detailled settings ) finally because KDE knows I am not paranoiac and that I use BSD, It will select the right firewall security level.
Thanks to Gas, KDE can guess my artistic preferences from my English style in KMail, the way I type, the applications I use and how often I use my desktop, Gas will select a theme that I would have never tought of !
Solidification is a distro-generator, it will open one text field where I will write "Complete LAMP Server KMines slick theme", Solidification will ask me to confirm the new packages list and configuration and will ask me to add personal files. After 10 minutes, Solidification will have downloaded the packages from a web server and build and installable live-cd ! I will also try for fun "office internet multimedia hobby programming on 512Mb usb key", "My desktop", "Enlightenment desktop", "Media center with all ogg of ", wonderful !
Thanks to Fluid, my KDE Linux will run as fast as turning on the TV.
Fire is my virtual tutor, it makes me creative and efficient: it helps me to logout when I am tired, to take my medicins, to avoid Slashdot, to organize my self, to uninstall Fortune and to advise me.
Ice will be a programs repository it helps me choose and install the right program for my works.
Happy will be me. KDE is fantastic !
Somebody has to package software and distribute base packages, updates and bug fixes. That's the (literal) job of a distributor, aka distro. There's plenty of room for competition. They are the "open administrators" versus the "open developers" of KDE (or Linux, or BSD, or whatever)... they are complementary and do all the work so, for the user, it just works.
Very good post! Not only ideas are good, bit it even avoid taking drugs to think as higher as you can! :-)
I even like all the names: Plasma, Solid, Gas, Fluid, Fire, Ice.
How about the subprojects? Like Solid/Iron, Solid/Chromium, Gas/Steam, Fire/Flame, Fire/Pyro, Ice/Freeze [kalzium comes handy in naming!].
Anyone willing to start implementing Fire? The idea isn't that bad.
How about 'Korundum' as a mineral name then?
> Anyone willing to start implementing Fire? The idea isn't that bad.
It's already implemented by Microsoft... it's called Clippy.
So called "intelligent" agents just don't work out very well in real life.
> I dream of a day when all distributions will disappear. Thanks to Solid, we won't even a hardware control center, everything will work perfectly with zero configuration. For example, as I plugged in my Speedtouch USB Modem, KDE tried to copy my configuration from Windows, username, password and provider, but I won't have Windows, so from my local settings, KDE will pick my country by default and ask me to fill in two fields, username and password, also in a list, there is the list of all countries, but because KDE knows where this modem is generally used, it put those countries before any ( Yeah, If I press Ctrl and click on any region of the windows I can have access to very detailled settings ) finally because KDE knows I am not paranoiac and that I use BSD, It will select the right firewall security level.
The main problem is DB. If we had data about your modem we could do something. For example, look at the kppp internet providers' list. It's nearly empty. Look at templates for KOffice applications. It's the same problem. Nobody want to contribute data, because it's harder than configure every new installation (it's not to often).
> Thanks to Gas, KDE can guess my artistic preferences from my English style in KMail, the way I type, the applications I use and how often I use my desktop, Gas will select a theme that I would have never tought of !
Not all people write in English :). A lot of research should be done for this program, it's academic project.
> Solidification is a distro-generator, it will open one text field where I will write "Complete LAMP Server KMines slick theme", Solidification will ask me to confirm the new packages list and configuration and will ask me to add personal files. After 10 minutes, Solidification will have downloaded the packages from a web server and build and installable live-cd ! I will also try for fun "office internet multimedia hobby programming on 512Mb usb key", "My desktop", "Enlightenment desktop", "Media center with all ogg of ", wonderful !
It could be done. Some LiveCD master for Kubuntu, for example. Debian tags can help. Select skeleton(server, client console, client X, client KDE). Add packages according to tags and package names. Select data to add to CDs or DVDs (documents, music, photos, ...). After all of this run script (that already exists) to build your custom distro. It's need Express Installer (in the terms of Kubuntu) in the skeleton. It could need visual choose of installer options (don't ask them during install of custom distro).
> Thanks to Fluid, my KDE Linux will run as fast as turning on the TV.
After some years new generation TV turning on about 2 minutes... :)
> Fire is my virtual tutor, it makes me creative and efficient: it helps me to logout when I am tired, to take my medicins, to avoid Slashdot, to organize my self, to uninstall Fortune and to advise me.
For me, it's should be passive popup. Just information: "time to rest", "too many blog reading", "day summary: kdevelop 7h, konqueror web 20min, kopete 20min, amarok 10min, konsole 10min"...
It could be done some way in KDE3.
> Ice will be a programs repository it helps me choose and install the right program for my works.
The same: visual program with debian tags. Adept, if I remember name correctly, but it's need tag autocomplection.
> Happy will be me. KDE is fantastic !
There will always be distributions to make packages that will definitely behave well with each other.
Solid seems to me to be promising. But the first thing I noticed about the web site is that the text is not as clear or as grammatical as it could be. Perhaps it was written by a speaker of English as a second language. Maybe it would be a good idea for a native speaker of English to volunteer to edit the text.
Could somebody who knows about both SuSEplugger and Solid explain to me the difference in functionality between the two? Also, what is the licensing for SuSEplugger? Could SuSEplugger code be used to speed the development of Solid?
I used SUSEplugger with kde 3.4 and earlier, but since kde 3.5 I use kio_media instead.
I understand that the Solid libs needs to be KDE libs and that's great.
But how about sharing the knowledge base with other projects, I think the best way to do this would be to host it on freedesktop or make it available to other projects that use a different backend than Solid. That way more people will be able to send feedback, the knowledge base will grow bigger and so faster. I guess that this will be possible as Solid will be opensource every other projects will be able to implement the Knowledge base API part. But maybe it would be better to organize something about it now with gnome and other freedesktop projects.
What do you think?
I don't think this is really necessary. Solid will use HAL servies etc. (depending what's available) and offer a KDEfied API for it. freedesktop.org so far is very Linux centric, while the purpose of Solid is to offer an abtracted API for accessing lower level information which can only be received in different way on different systems/platforms. The info of course is beeing shared since the code for that all is and will be in KDE's open SVN.
Is it possible for things like the Qt-DBUS bindings, poppler-qt etc to be moved into kdesupport or equivalent? I really hate having to download svn code from another server just to try out things that are necessary, not optional ;)
Any other suggestions welcome, I'm currently using kdesvn-build to do all the hard work.
I don't think that the dot is the right place to discuss such things.
Well, the whole poppler (or dbus, whatever) project isn't going to move into kdesupport (any more than they would move into a Gnome archive, or an enlightenment archive), and the bindings are closely tied the underlying project. Also note that there are no KDE dependencies in the poppler-qt bindings, so why should it be tied to KDE? Sure, it will be used by KDE, but also by other, non-KDE, projects.
It is much easier to maintain the bindings in conjunction with the underlying code, and freedesktop.org is a good place to work on such projects.
kdesupport started out as a repository for dependency libs as a convenience to developers so that people didn't have to hunt down packages across the internet.
Actual development always took place elsewhere, kdesupport just acted as mirror that got updated once in a while.
What about making it easy for KDE developers to use the bindings as well? Why should I have to check-out some svn code from a non-KDE repository just to get a working development KDE? Sure, I can do it. Do I want to? No.
Look, if kpdf relies on poppler-qt and I have to check it out of freedesktop.org, I just wont bother. I'll live without and use xpdf or something else. It's not going to affect the little bugfixes and enhancements I want to do in other parts of KDE.
But when it comes to Qt-dbus, that's a different matter and I hope that it's integrated into the KDE svn.
> But when it comes to Qt-dbus, that's a different matter and I hope that it's
> integrated into the KDE svn.
I'm working on that. It'll take time, so volunteers are welcome.
Currently it's being hosted on the KDE Subversion server pending freedesktop.org bureaucracy.
Heh, well with SVN you can stick external SVN sources into the tree. That would be a clean way to do it. Having stuff in SVN that requires manually syncing seems kind of in defiance of the point of downloading from SVN... to get the most-up-to-date.
> Having stuff in SVN that requires manually syncing seems kind of in defiance of the point of downloading from SVN
Actually not for those external libs. Our stuff often doesn't work with the in-development versions of those libs (e.g. HAL/DBUS and media kioslave).
So having a snapshot of those libs in our SVN that is known to work is IMHO a good idea.
Does this mean kde4's kmail will not try to download my e-mail anymore when I unplug the cable (And WILL download it again when I plug it in)? Same for akregator, ... ?
Yes I believe that this is the general idea. Any cable which you can poll for connection status would encourage this type behavior.
Eg. if you connect a beamer to your laptop Solid would detect this. As you usualy give presentations on beamers KDE might directly open up KPresenter on that screen or Impress. KOffice would be a sane default but OO.o might be selected by quite a few people. And when you disconnect the beamer then your Kpresenter would minimize on the standard screen. Of course if you enjoy watching movies on large screens on of the kde movie players might open full screen. Sane defaults unlimited customization.
This is something that would capture the bussiness scene by storm. The amount of time that people look stupid on any desktop os trying to get a beamer to work for presentations is huge!
the kmail developers could of course offer this functionallity NOW, but they would have to do lots of work to support the various distributions and other unixes. with solid, it would be easy. so it is much more likely they will do it...
it is already now possible to have kmail network-aware. All you need is a working hotplug/ifplugd installation, then you can put in /etc/network/interfaces:
iface eth0 inet dhcp
down dcop --all-users --all-sessions kmail KMailIface stopNetworkJobs
up sleep 5; dcop --all-users --all-sessions kmail KMailIface resumeNetworkJobs
Of course, you need Debian to have this comfort ;)
That is all :)
Hope Suse also will contribute code.
I would like to see a real YaSt integration into KDE, so other distributions can benefit from the great progress Suse provided us.
Please, do keep in mind that not everybody likes SuSE's YaST.
I always prefer plain vi for editing my config files, and don't like graphical configuration utilities for things more serious than desktop theme or favorite screensaver selection. KControl provides that and only that and that is sufficient. Also, I don't believe that I am the only one who thinks that way.
Btw, YaST is open-source and it is written in Qt (or has Qt backend if you prefer to say that way). I don't see any problem in integrating YaST into any distribution that wants it.
I do agree, YaST to me is somewhat of a pain. What I dislike most about it is that it reads the config files rather than checking the actual status of say a device. What good is a tool, which is nothing more than a graphical frontend to configuration? KControl in that case is sufficient, most distros offer their own config tools which are way better, no YaST for me please. But hey, we're all using open operating systems, some Suse Linux, some FreeBSD, some might even be using something more exotic. So there, please yourself. As for solid, sure it sounds cool. Let's see what it turns out to be when we're there.
Integrating YaST more into KDE does not make it distribution independent.
The underlying technology of YaST is the key here: can it be easily used on other platforms, or is it tied to the structure of SUSE?
mostly tied to suse, i'm sure. some debian devs are trying to port it to debian, but it seems to be a lot of work...
suse DOES contribute to KDE, a lot, but not really with yast. KDE shouldn't even think about integrating something like Yast in KDE, imho (and they're smart: they don't). if Solid is here, there might be some work based on it to configure stuff, and that's great. but until then - the distro's are responsible for configuration of hardware and the underlying system. Suse does it great, with Yast, and most other distro's like mandriva have excelent tools, too.
..And we have Guidance for platform independent configurations :)
This would be perfect for exposing all of the sound cards installed in a computer!
Like (I'm sure) lots of other KDE users, I have more than one sound card installed. So everytime I install a new multimedia application, I have to spend loads of time configuring apps to use the right sound card (which also involves working out the device name of the second soundcard).
With Solid, one could just select the sound card from a nice pulldown list. And there's already code in kmix in kdemultimedia for detecting sound cards on a variety of different systems - which could be moved to Solid.
Jep , Many people have onboard sound , and one (good) normal soundcard
I've got to hand it to you all. This is exactly what's needed, and you're 'making it happen'.
I would like to see NON-KDE apps be able to automatically be redirected "hijack the audio stream) to artsd or jackd without having to use a artsdsp program: Arts and Jackit are great programs, but are often overlooked because people do not like the concept of abstraction. The great thing about them is the redirection of audio input/output which I use for recording all the time. Infact, when both daemons are working well it seems to be more effective than ASIO streams in windows.
Artsd also needs to have some sort of automatic buffer/latency optimization built in, because most of the problem with Arts has to do with system load vs. buffer size.
Phonon will replace aRts and use whatever sound daemon you want.
I was wondering about device API's.. Right now, the Kopete webcam functions use the Video4Linux API of the kernel directly. Will Solid also provide abstraction to handle such devices with a nice KDE-style API?