KDE 4 Set to Make Device Interaction Solid
Wednesday, 4 January 2006 | Steam
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.
Comments:
Good Title - Troy Unrau - 2006-01-04
Heh, first thing I noticed was the title play between Plasma and Solid. Neat. Only problem is that we can't use Liquid as a title for anything... silly apple.
Re: Good Title - Ryan - 2006-01-04
But they could use Fluid if they wanted.
Re: Good Title - superstoned - 2006-01-04
good idea!!! now lets try to come up with a project that fits the name :D
Re: Good Title - Niels - 2006-01-04
I suggest we call the new audio framework Ksteamer!
Re: Good Title - David Walser - 2006-01-05
Given the connotation of steamer (at least in some uses) that would be a really horrible name. Hmm, maybe we could retroactively give that name to arts :P Anyway, I suppose you mean Kstreamer, and probably as somewhat of a joke, but check it out. Stream, fluid...kind of a relationship there. Interesting :o)
Re: Good Title - Imous Anon - 2006-01-05
Naa, but considering Plasma, Solid, and the proposed Fluid, I strongly propose Gas!
Re: Good Title - SadEagle - 2006-01-05
That's taken... By the GNU Assembler.
Re: Good Title - Imous Anon - 2006-01-05
Damn, I wanted to ask everybody if they had gas, now everybody dose already.
Re: Good Title - Jason - 2006-01-05
How about just dropping the confusing K and calling it Steamer?
Re: Good Title - Ryan - 2006-01-04
Remember that GLOcean windec? How about helpful, but not distracting fluid like animation hints for style/windec/menus/desktop/etc. Just a thought.
Re: Good Title - riddle - 2007-06-29
The audio component is called "Phonon", and can be found at http://phonon.kde.org .
Re: Good Title - cm - 2006-01-04
We could still use Bose-Einstein condensate. http://bose-einstein-condensate.kde.org/, how's that for a project URL? ;-)
Re: Good Title - reihal - 2006-01-04
Gas is not a good idea.
Re: Good Title - David Walser - 2006-01-05
What, you don't want servers to pass Gas everytime someone downloads KDE?
Re: Good Title - Ian Monroe - 2006-01-06
Its not gas, its another state of matter entirely. :)
Re: Good Title - Rob - 2006-01-05
But there is a database named Solid database (http://www.solidtech.com/). Might run into some trademark issues.
Re: Good Title - rinse - 2006-01-05
Solid is a plain English word, so I don't expect trademark issues :o)
Re: Good Title - Ryan Winter - 2006-01-05
Just like "windows" :D
Re: Good Title - Ian Monroe - 2006-01-06
Hehe good point. In this case its not really an issue since Solid isn't a seperate product.
Re: Good Title - David Pastern - 2006-01-05
Why not use "air" or "aerate"? Dave
Re: Good Title - bob dagit - 2006-01-05
nike has air, but in case aerate has been taken, try air8
Re: Good Title - bob dagit - 2006-01-05
but let's forget about ice9, it has been taken
Sweet - Gerd - 2006-01-05
What about a project "Sweet" for Suse Yast integration. At least parts which are not SuSe specific could get merged. I think of stuff like the partitioning tool.
Re: Sweet - rinse - 2006-01-05
The partition tool is nothing more than a frontend for GNU Parted. So, i guess it makes more sense to write a KDE-gui for Parted then to port the YaST-module..
Re: Sweet - Anonymous - 2006-01-06
Mandrake has by far the best Linux partitioner that I'm aware of If only it was easier to get QTParted to support reiserfs..
Re: Good Title - Jonathan Patrick Davies - 2006-01-05
You forgot Oxygen.
Re: Good Title - Duncan - 2006-01-06
I know the "K-naming" has gone into disrepute, but I like it, and "liKuid" should work. Duncan
Re: Good Title - Jonathan Weaver - 2006-01-27
We could also announce an innovative, exciting, revolutionary new project called 'Vapour', and then never release anything at all ...
Portability? - Brandybuck - 2006-01-04
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. I'm hoping they just have their definition wrong.
Re: Portability? - Corbin - 2006-01-04
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.
Re: Portability? - superstoned - 2006-01-04
indeed. there is already a HAL backend, and i don't think its written by HAL developers...
Re: Portability? - Aaron J. Seigo - 2006-01-04
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. =)
Re: Portability? - Brandybuck - 2006-01-05
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.
Re: Portability? - Christian Loose - 2006-01-05
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. e) Solid features have *nothing* to do with proprietary video drivers
Re: Portability? - Brandybuck - 2006-01-05
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.
Re: Portability? - Greg - 2006-01-06
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.
Re: Portability? - Gerd - 2006-01-05
Do you have any doubts that all relevant plattforms will support it?
Re: Portability? - Segedunum - 2006-01-05
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 ;-).
Re: Portability? - I think you mis-understand platforms.... - 2006-01-06
What they mean is, that in Linux Solid can use the HAL backend, but it can't in FreeBSD or NetBSD or Solaris. So, on each of those *platforms*, a different Solid backend would need to be implimented. It has nothing to do with drivers or hardware.
Re: Portability? - Anonymous - 2006-01-07
> 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.
yet another layer ? - polux - 2006-01-04
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.
Re: yet another layer ? - Ian Monroe - 2006-01-04
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. And yea, Solid is a KDE library...
Re: yet another layer ? - Brandybuck - 2006-01-05
"Really I would consider the DE to be part of the operating system" 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.
Re: yet another layer ? - Tobias König - 2006-01-05
"KDE can run on *ANY* Unix..." Right, but not any Unix provides HAL or D-Bus, for this reason we need yet another abstraction layer.
Re: yet another layer ? - Ian Monroe - 2006-01-06
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.
Re: yet another layer ? - FreddyTheTeddy - 2006-01-09
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 :-)
Re: yet another layer ? - superstoned - 2006-01-04
if there would be no solid, every application has to support several different ways of getting hardware information. it would mean a lot duplication of effort...
Re: yet another layer ? - Aaron J. Seigo - 2006-01-04
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.
Re: yet another layer ? - Evan "JabberWokky" E. - 2006-01-04
HAL is Linux specific. KDE isn't, and thus Solid isn't.
Re: yet another layer ? - Reply - 2006-01-05
Correction: HAL is portable software with only a Linux backend available at the time. Sun is working on porting it to Solaris, and there are people working on a FreeBSD port too.
Re: yet another layer ? - Malte - 2006-01-05
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.
fantastic - Ian Monroe - 2006-01-04
The plan for Solid appears to be addressing all the weaknesses of media:/. KDE4 is going to freakin' rock.
Re: fantastic - Aaron J. Seigo - 2006-01-04
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 =)
Distributions Extinction - Youcha - 2006-01-04
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 <my preferred artist>", 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 !
Re: Distributions Extinction - Evan "JabberWokky" E. - 2006-01-04
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.
Re: Distributions Extinction - nemeca - 2006-01-05
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.
Re: Distributions Extinction - Richard Dale - 2006-01-05
How about 'Korundum' as a mineral name then?
Re: Distributions Extinction - another nickname - 2006-01-07
> 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.
Re: Distributions Extinction - anonymous - 2006-01-05
> 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 <my preferred artist>", 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 !
Re: Distributions Extinction - Robert - 2006-01-05
There will always be distributions to make packages that will definitely behave well with each other.
Editing; SuSEplugger - Paul Leopardi - 2006-01-04
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?
Re: Editing; SuSEplugger - rinse - 2006-01-05
I used SUSEplugger with kde 3.4 and earlier, but since kde 3.5 I use kio_media instead.
the knowledge base - Patcito - 2006-01-04
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?
Re: the knowledge base - ac - 2006-01-05
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.
Qt bindings - ac - 2006-01-05
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.
Re: Qt bindings - Christian Loose - 2006-01-05
I don't think that the dot is the right place to discuss such things.
Re: Qt bindings - Brad Hards - 2006-01-05
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.
Re: Qt bindings - Waldo Bastian - 2006-01-05
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.
Re: Qt bindings - ac - 2006-01-06
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.
Re: Qt bindings - Thiago Macieira - 2006-01-06
> 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.
Re: Qt bindings - Ian Monroe - 2006-01-06
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.
Re: Qt bindings - Christian Loose - 2006-01-06
> 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.
KMail - Bruno - 2006-01-05
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, ... ?
Re: KMail - jerven - 2006-01-05
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!
Re: KMail - superstoned - 2006-01-05
yes. 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...
KMail network-aware - Ineiti - 2006-01-05
Hi, 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 ;) Ineiti
I love you guys - Janne - 2006-01-05
That is all :)
Suse plugger - Gerd - 2006-01-05
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.
Re: Suse plugger - Filip Brcic - 2006-01-05
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. Brcha
Re: Suse plugger - Ron - 2006-01-05
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.
Re: Suse plugger - rinse - 2006-01-05
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?
Re: Suse plugger - superstoned - 2006-01-05
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.
Re: Suse plugger - rinse - 2006-01-05
..And we have Guidance for platform independent configurations :)
Sounds Cards - David Saxton - 2006-01-05
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.
Re: Sounds Cards - chri - 2006-01-05
Jep , Many people have onboard sound , and one (good) normal soundcard
Exactly What's Needed - Segedunum - 2006-01-05
I've got to hand it to you all. This is exactly what's needed, and you're 'making it happen'.
I love Jackit, arts, and other sound daemons. - paperclip - 2006-01-11
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. -Ron
Re: I love Jackit, arts, and other sound daemons. - riddle - 2007-06-29
Phonon will replace aRts and use whatever sound daemon you want.
Device driver API? - Diederik van der Boor - 2006-01-12
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?
fewe - fef - 2007-01-03
fewfwe http://www.google.com/search?hl=en&q=cat&lr=
Re: fewe - fef - 2007-01-03
<a href="">dfgdg</a>