KDE Commit-Digest for 16th March 2008

Monday, 24 March 2008  |  Dallen

In this week's KDE Commit-Digest: The beginnings of a network management applet in Plasma, work on containments, and improvements in the "RSS" data engine and "Devices" applet. Initial support for saving changes to documents in Okular. A Kross-based scripting plungin in KLinkStatus. "Tip-of-the-day" and "Qt methods to avoid" checkers for the Krazy code quality reporting system. First steps towards a C++ parser in Umbrello. Work on projection independence in Marble. More maintenance and bux fixing in Kooka. Continued work in KHTML. Expanded support for subtitles and audio channel selection in Phonon (prompted by the requirements of Dragon Player). A rewritten "Todo" view in KOrganizer. Further work towards Amarok 2.0. "HTTP webseeding" in KTorrent. Kross-based scripting in KPlato, with support for "find in multiple documents" in KOffice. Caching support extended to all KDE card games. Improvements in KTurtle, KNetwalk, and Kubrick. Initial imports and work on the "Killbots" and "Astrododge" games. Import of "RSSNOW", an alternate RSS feed reader Plasmoid. The Step physics package moves from playground/edu to kdereview so that it can move to the kdeedu module for KDE 4.1. Read the rest of the Digest here.

Comments:

Sleep, anyway? - Antonio - 2008-03-24

Good grief, do any of you sleep? ;) `you', in this case, includes Danny. Thanks for the Digest, and thanks to all the developers for the ridiculously inhuman amount of work you put in!

Re: Sleep, anyway? - anon - 2008-03-26

of course danny sleeps, why do you think commits come out a week after they have been released. Well, in this case, over a week. Pity they don't hire a monkey, which would be a lot more efficient than Danny. It's time dot gets rid of Danny and gets someone decent who can do this job. It's getting worse and worse

Re: Sleep, anyway? - Whatever Noticed - 2008-03-26

Writing articles for The Dot isn't a paid job. It is all done by people who use their free time to contribute to KDE. If you don't like that situation, you could hire a writer who creates articles and gets paid for it.

Re: Sleep, anyway? - jos poortvliet - 2008-03-26

I guess this is supposed to be funny? Sorry, it's not. It sounds a lot like a frustrated Gnome user who is annoyed his community is unable to get such a large stream of quality development news to it's users. Not that there would be much to tell, of course...

New to-do view - The Troy - 2008-03-24

Would someone be willing to post a screenshot of the new to-do view in KOrganizer?

Re: New to-do view - she - 2008-03-24

agreed hopefully someone finds the time to put up a few images of it :)

Re: New to-do view - Martin Fitzpatrick - 2008-03-24

I'm hoping for a To Do plasma applet. I'm horribly easily distracted (look I'm on the dot right now) and it would be great to have something easily accessible and reminding me to "DO THIS NOW" (...other than my girlfriend). Thanks.

Re: New to-do view - DanaKil - 2008-03-24

Hi This is an attached screenshot in bugzilla : http://bugs.kde.org/attachment.cgi?id=23846&action=view (2008-03-10 11:49)

Re: New to-do view - The Troy - 2008-03-24

What did they re-write about it? It looks exactly like the to-do in KDE3 KOrganizer.

Re: New to-do view - b - 2008-03-24

I think, first of all it is rewritten to use Qt4

Are plasmoids expected to be good citizens - Mark - 2008-03-24

I follow the new builds from time to time. I not that some of the plasma apps will kill the window manager, well the screen goes black, and all I can do is a ctrl+alt+delete. I know this is not production code, but was wondering what the design philosophy of Plasma is. Will Plasma be engineered to handle bad plasmoids and not seg fault or go into never land. Or does it expect all plasmoids to be good citizens and not crash. KDE really looks great. by the way

Re: Are plasmoids expected to be good citizens - JP - 2008-03-24

Some plasmoids do have issues as the underlying api is changing a bit. However, when this happens (wont happen once the api has become more stable) you can hit alt-F2 and type plasma to get it back <-- (the reason krunner is separate from plasma).

Re: Are plasmoids expected to be good citizens - illogic-al - 2008-03-24

Yes. But "Will Plasma be engineered to handle bad plasmoids and not seg fault or go into never land. Or does it expect all plasmoids to be good citizens and not crash."

Re: Are plasmoids expected to be good citizens - Anon - 2008-03-24

If a Plasmoid written in native code crashes, it will take down the rest of Plasma (but not the "window manager", as the OP claims - I have no idea what's happening there) - this is unavoidable, and the statement "wont happen once the api has become more stable" is entirely false. Which is why scripted Plasmoids are so desirable: they are easy to write, easy to deploy, download and install, sandboxable if the scripting language allows it (Javascript/ QtScript are favoured here, as e.g. Python and Ruby do not have mature sandbox implementations) so that you can in theory fine-tune what resources each one can and cannot access/ modify, and you can guard against having them crash.

Re: Are plasmoids expected to be good citizens - security guy - 2008-03-24

Have the plasma developers thought of the security implications of running native code? It wouldn't be good to run a plasma applet and have it rootkit the system!

Re: Are plasmoids expected to be good citizens - Anon - 2008-03-24

For a "security guy", you sure don't have a good understanding of common terms. For reference, most apps that you are using right now - including your web browser, e-mail client, etc - are "native code".

Re: Are plasmoids expected to be good citizens - Mark Williamson - 2008-03-24

Yes, but - unlike Plasmoids - the normal method of obtaining that code is not to download them from a random 3rd party on the internet, since they come with your distro. IMO, the different security concerns for Plasmoids arise from the fact that there's a lower "barrier to entry" to getting Plasmoids onto a users' desktop.

Re: Are plasmoids expected to be good citizens - SMB - 2008-03-24

Probably why you're not supposed to download and run apps you don't trust.

Re: Are plasmoids expected to be good citizens - Anon - 2008-03-24

Native code apps will always have to be either compiled from source (a power-user task), obtained from distro packages, etc - in other words, Plasma does *not* lower the barrier to entry of getting native code onto the users desktop. It is precisely as much of an increased security risk as Kicker applets were i.e. "barely at all". Non-native code - which will hopefully form the bulk of 3rd party plasmoids - can, as mentioned elsewhere in this thread, be tightly sandboxed so that it can do no harm.

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-24

> in other words, Plasma does *not* lower the barrier to entry of getting native code onto the users desktop It does. Security is not related here but things like a) the time needed to look at how it should be done and b) the time needed to get it working. Plasma helps with a) by providing good, clean and small interfaces Plasmoids need to implement and helps with b) by providing a fast way to test your code and cause of a) it's also not needed to write tons of code to get just something working. All in all, it does help to lower the barrier to entry. If we look at scripting code aka Plasoids written or extended with scripts, then there is also no connection between security and barrier since it's not the main goal of most scripting languages to provide a secure sandbox but to get a solution out faster (aka without learning pointer-logic, without compiling, without being such static limited, etc.) an that's exactly what they (may) do in plasma as well :)

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-24

> in other words, Plasma does *not* lower the barrier to entry of getting native code onto the users desktop It does. Security is not related here but things like a) the time needed to look at how it should be done and b) the time needed to get it working. Plasma helps with a) by providing good, clean and small interfaces Plasmoids can implement and helps with b) by providing a fast way to test your code and get it working and cause of a) the task shouldn't be that complex => lesser code needed to get the job done. All in all, it does help to lower the barrier to entry. If we look at scripting code aka Plasmoids written or extended with scripts, then there is also no connection between security and entry-barrier since it's not the main goal of most scripting languages to provide a secure sandbox but to get a solution out faster (aka without learning pointer-logic, without compiling, without being such static limited, etc.) an that's exactly what they (may) do in plasma as well. Security, as in Plasmoids coming from untrusted sources, is only related for the deployment.

Re: Are plasmoids expected to be good citizens - Thomas Zander - 2008-03-24

Yes, it has been considered. No plasma apps can not rootkit your system.

Re: Are plasmoids expected to be good citizens - Anon - 2008-03-24

Double negative error.

Re: Are plasmoids expected to be good citizens - sebas - 2008-03-24

... or a missingcomma. :-)

Re: Are plasmoids expected to be good citizens - Anon - 2008-03-24

Are you *sure* it's an error?

Re: Are plasmoids expected to be good citizens - jos poortvliet - 2008-03-26

I suspect it's not...

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-24

re security and sandbox; Ruby comes with security-levels, Python can be extended using the RestrictedPython module (like Kross did in KDE3) or the Zope3 security-framework. But I wouldn't trust all of them to be _the_ solution. All they can do is to rise the time needed till some evil actions are possible. btw, QtScript does not provide any kind of sandbox-model while KjsEmbed does remove the security logic from Kjs by extending it with potential insecure functionality. So, none of them is _the_ solution if it comes to security either. I guess Java or Kjs/WebCoreScript direct are the best / most secure ways to go here but even then I wouldn't trust them ;)

Re: Are plasmoids expected to be good citizens - Richard Moore - 2008-03-25

Actually QtScript provides the exact same sandbox as a browser. It's simply a matter of which objects you choose to expose. Ruby's security levels don't seem particularly well thought out when I looked at them either.

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-25

I was refering to http://labs.trolltech.com/blogs/2008/03/10/bind-aid/ Anon: "Is there any provision for sandboxing" Kent: "Anon: Nothing yet. However, you&#8217;re free to remove e.g. the QFile and QDir constructors from the script engine after importing the bindings. We&#8217;re playing with offering more flexible/fine-grained ways of configuring the bindings though, will keep this in mind." Sandboxing doesn't mean to just don't provide functionality that may insecure (else brainf*ck would be the most secure language followed by xslt :) but to be able to control and limit it. So, to e.g. allow to use QFile but to restrict it to reading from /home/friendly_user/for_my_gov_agency and writting to /home/president_bush/next_wars ;) I guess the Java policy-framework is a very good example imho followed by the Zope3 security-framework. > Ruby's security levels don't seem particularly well thought out when I looked at them either. Cause of the only both vulnerabilities Ruby had in 2005 (CVE-2005-2337 and CVE-2005-1992) while e.g. Safari had 20 times as much?

Re: Are plasmoids expected to be good citizens - Richard Moore - 2008-03-25

>> Ruby's security levels don't seem particularly well thought out when I >> looked at them either. > Cause of the only both vulnerabilities Ruby had in 2005 (CVE-2005-2337 > and CVE-2005-1992) while e.g. Safari had 20 times as much? The problem is one of design rather than implementation. To give an example, at a SAFE level of 2 you are prevented from doing File.chmod, but you're free to do Kernel.system("chmod +x blah").

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-25

> To give an example, at a SAFE level of 2 you are prevented from doing File.chmod, but you're free to do Kernel.system("chmod +x blah"). y, cause T2 is about "Ruby prohibits the loading of program files from globally writable locations." and has nothing to do with chmod+userfiles. Use at least T3 or even better T4. but I agree that those "safe levels" are not really what someone may understand under sandbox too since it would still be needed to provide secure wrappers for things like readfile, chmod, etc. if they should be limited to defined locations :-( Same was the case with Zope2 RestrictedPython and since I still believe it's better to provide no security then false security, I just did removed it in KDE4 - the Zope3 solution really looks very good but is to huge to be adopted :-( Guess my initial point of "none of them is _the_ solution if it comes to security" is still valid even if I wish that wouldn't be the case :-(

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-25

and before I forget it, there is the nice document "Sandboxing of Dynamic Code" around which does provide some good (but in the case of Python outdated) details related to that topic; http://rune.hammersland.net/tekst/sandbox.pdf

Re: Are plasmoids expected to be good citizens - Richard Moore - 2008-03-25

Another thing with the ruby safe levels is that they seem very oriented to web apps operating on untrusted data rather than apps embedding the interpreter operating on untrusted code. eg. only at a safe level of 4 is the script prevented from terminating your application. > Guess my initial point of "none of them is _the_ solution if it comes to > security" is still valid even if I wish that wouldn't be the case :-( I think that's a pretty fair assessment. It's not the answer I'd like either though. :-( The java security manager approach is the only real way I've seen to get truly fine grained control, and that is extremely complex and requires hooks in all your libraries. Even then it has been bypassed on a number of occaisions (possibly because it is too complex to test effectively).

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-25

> eg. only at a safe level of 4 is the script prevented from terminating your application. Does you have a source for this? I ask cause, well, we are using Ruby and I never did note such behavior. What for sure is a bit annoying and probably related is that it's needed to wrap each C-functioncall into a secure-fallback function to catch exceptions explicit. If that isn't done and if the call throws an exception, the application will crash (same with T4 btw). The reason for that design was to maximize the performance by being able to select what C-functions may throw an exception (that needs to be catched) and which one are not. Guess that's very inline with the overall design-goal of Ruby to provide the fastest scripting-environment out there on earth. > The java security manager approach is the only real way I've seen to get truly fine grained control, and that is extremely complex and requires hooks in all your libraries. y, true. That's really one of the best solutions I saw so far but also comes with so much downsides. Very much like something like SE-Linux which if used wrong may provide more trouble then solving any. > Even then it has been bypassed on a number of occaisions (possibly because it is too complex to test effectively). and judging from the 1.6 showstopper-bug I run into (known since more then 2 years btw) I wouldn't wonder if there are no automated tests for such things at all :-/

Re: Are plasmoids expected to be good citizens - Richard Moore - 2008-03-25

> Does you have a source for this? This is the best doc I've found on ruby safe levels (especially the table at the bottom): http://phrogz.net/ProgrammingRuby/taint.html

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-25

> http://phrogz.net/ProgrammingRuby/taint.html Thanks for that link and now I am impressed since at $SAFE>=2 it really says chmod should be prevented. Uh, I've to add. That's really new to me and its even more surprising it's written down in a book while being just not true/valid. Guess that was the last destroyed difference between books and TV :) Re $SAFE>=4 and "Can't invoke exit, exit!, or abort." Neither exit or abort works if embedded, but exit! does and that even with SAFE==4. Hmpf, http://www.math.hokudai.ac.jp/~gotoken/ruby/man/function.html#exit_bang says unlike abort and exit the exit! function ignores any handlers. Fine :-( Anyway, added to my todo and will be fixed asap, thanks for that hint!

Re: Are plasmoids expected to be good citizens - Richard Moore - 2008-03-26

Yes, I checked the ruby source code too and the code matches this reference.

Re: Are plasmoids expected to be good citizens - Grósz Dániel - 2008-03-24

It would be good if KDE restarted Plasma if it crashes, like KDE 3 does with Kicker in some cases. Otherwise we reach the quality of Windows 9x where a poorly written component could crash the whole system - average users have no idea about "Alt+F2 plasma".

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-24

iirc it does auto-restart. Re win95; the whole OS could crash by any app and not only the desktop by it's plugins. So, probably it's more fair to compare with extensions that crash the WinExplorer (which is afaik responsible for the desktop), with a winamp-plugin that crashes whole of winamp or with a driver that oop's'es whole of linux.

Re: Are plasmoids expected to be good citizens - Erunno - 2008-03-25

Technically you are probably right, but from a non-technical user's point of view I presume that a Plasma crash equates to a complete system crash as his main (and probably solely) means of communication with the system are not available any more. If I had to hazzard a guess people who don't know how to launch plasma via krunner or are not familiar with virtual terminals will probably hit the reset button at this point.

Re: Are plasmoids expected to be good citizens - Sebastian Sauer - 2008-03-25

> Technically you are probably right is that different from practical? Sorry, failed to resist :) > that a Plasma crash equates to a complete system crash as his main (and probably solely) means of communication with the system are not available any more That's why it auto-restarts. Though before we move again to the beginning of the circle, I may like to point to 2 examples; 1. SuperKaramba It's a plasmoid that can be run either _in_ process just like most (all?) plasmoids today OR _out_ of process. Right, both is possible and I can imagine that bigger and more complex plasmoids (so, e.g. whole applications rather then a clock or a status-display) can go the same way. Technical (and practical) it just does not make any sense to move e.g. a clock into an own process. See here also the last note at the bottom of http://ktown.kde.org/~seli/memory/desktop_benchmark.html 2. Trayicons The trayion plasmoid does display those handy icons which are provided by an app and then embedded into the trayicon plasmoid. So, if a running app crashes it doesn't crash the trayicon-plasmoid and with it plasma. So, you see. It is technical (and practical *g*) possible already. That the OP does now ask if the crashes he did run into are cause of the "design philosophy of Plasma" is even somewhat funny from the pov of someone who's still running KDE3 on his productive systems like suggested by the release-notes, blogs or even the mainstream-press. The problem is, that an answer like "no, it's cause KDE 4.0.2 isn't as rock stable as e.g. KDE3 kicker+applet are yet, but we are moving rather fast into that direction and once we are there your question will be solved" really does sound so reused, that it's hard to repeat that. Probably an answer like "no, crashes are not a design philosophy but an attitude to life" or "if you don't like that crash we can add a GUI-option to disable it" would offer some more variety of fun?! :)

Re: Are plasmoids expected to be good citizens - sebas - 2008-03-25

Plasma already gets restarted when it crashes. There is some simple logic in there so it doesn't crash in an infinite loop though. It won't restart itself after a second crash.

Re: Are plasmoids expected to be good citizens - christoph - 2008-03-25

If it behaves this way, it should save a "last known working configuration". My experience is that it didn't restart after a crash; I don't know why.

Re: Are plasmoids expected to be good citizens - Aaron Seigo - 2008-03-25

it doesn't restart if a crash happens within 10s of restarting. but then we install the crash handler again after 10s of running. this is usually enough to stop infinite recursions of doom.

Nice work - T - 2008-03-24

The amount of work going into Akonadi & friends was really impressive. The API review will produce great long-term results, I'm sure, even if such cleanups require quite a lot of tedious work. A very exciting read, thanks to all devs.

Well done KHTML developers - Zayed - 2008-03-24

It seem we will get fast and rich features web browser in kde 4.1. Does any one have the score of KHTML (development version) in Acid test version 3 ? what about the javascript benchmark in compare with firefox 3 beta 4?

Re: Well done KHTML developers - djvnklhjefjmwfn - 2008-03-24

Well, if the KHTML developers finally got over their giant ego and already ported WebKit into the KHTML framework, then it's 95/100 points: http://webkit.org/blog/167/webkit-gets-an-a-on-acid3/

Re: Well done KHTML developers - xian - 2008-03-24

While I too would like to see webkit used by kde and one common web platform, the khtml developers deserve better treatment. They seem to be helping out all over: http://webkit.org/blog/158/the-acid-3-test/

Re: Well done KHTML developers - Anon - 2008-03-24

Yea, took the WebKit crew quite some time to finally include the CSS3 selectors patches by the KHTML developers (they were available for ages, but only with this ACID3 test there was interest from WebKit side to actually incorporate them). I'm sure once it's easier to compare output of KHTML and WebKit within KDE the stream of merge patches between the two will increase. I just hope the WebKit side will be more forwardcoming in incorporating KHTML improvements then.

Re: Well done KHTML developers - eds - 2008-03-24

Agreed, the KHTML developers really deserve better treatment. Without them, Konqueror in KDE 4.0.x would be unusable as web browser (KHTML crashed too often and rendered pages like ancient browser before they started fixing bugs for KDE 4, and now it is pretty solid). And I'm also sad that some people never appreciate what the KHTML developers have done, especially those who can only yell: "dump KHTML, use Webkit!" I hope KHTML can remain alive, so that we have an alternative engine inside our own tree. I would also like WebKit to be used by KDE, but I guess having an engine that we have total control would be advantageous.

Re: Well done KHTML developers - rdttgukk,fzjkuggh - 2008-03-25

WebKit is free software and can be forked at any time if WebKit's SVN becomes "hostile" towards KDE. But since some KDE and Trolltech developers got SVN write accress hostility is unlikely.

Re: Well done KHTML developers - Anon - 2008-03-30

A fork is no good if you've lost all of your developers.

Re: Well done KHTML developers - eds - 2008-03-24

Well, do you think merging two source code trees that have been diverged for years is that simple? KHTML developers always do merging whatever can be merged from Webkit tree but I guess not all are as straightforward as you think. You can always check the websvn to see what have been merged ;)

Re: Well done KHTML developers - digital.alterego - 2008-03-24

I got 65/100 points with todays svn version.

Re: Well done KHTML developers - fred - 2008-03-24

JavaScript performance also has been improved, I, and will be improved further if kjs-frostbyte branch has been merged to trunk. Nice, kudos to KHTML team!

network manager - Thomas - 2008-03-24

I'm especially interested in the network manager thingy. Is this going to replace knetworkmanager as a kind of "reincarnation" as a Plasma-applet? Will it be based on Solid? Does it provide a Plasma engine which can be used by other applets? Or is it directly based on natworkmanager/dbus/HAL ?

Re: network manager - sebas - 2008-03-24

possibly, yes, yes, no :-)

Re: network manager - kde - 2008-03-24

So it will be Plasmoid --> Plasma engine -> Solid --> NetworkManager ? Very nice indeed. You'll get like a thousand places to feed the bugs. Happy hunting.

Re: network manager - Anon - 2008-03-24

4 <<< "a thousand". Also, most of these places are very thin wrappers and unlikely to introduce many bugs - NetworkManager will do the "heavy-lifting".

Re: network manager - sebas - 2008-03-25

But you'll have less bugs since you have less duplicated code and more of that well-tested. It's also easy to use networky features on other platforms without rewriting your plasmoid. Using networkmanager is right now the backend for 'networky' stuff used on Linux, though the plasmoid doesn't need to care about that, thanks to Solid. With solidshell, it's easy to find out where it's going wrong. Of course no one keeps you from just porting knetworkmanager, if that works better for you.

Re: network manager - Vide - 2008-03-25

Sure, if your wifi chipset cannot connect to WPA network you'll have to hunt the bug in Plasma, sure. Be realistic, troll.

Re: network manager - Christopher Blauvelt - 2008-03-24

It could be a replacement for knetworkmanager but it doesn't have to be. The dataengine is based on Solid. Use cases for other apps include verification of network status and network usage stats.

Plasmoids in apps - Emil Sedgh - 2008-03-24

Hi as time goes, we are getting more and more stanalone plasmoids.i dont think that having 3 (and counting!) rss reader plasmoids or a standalone 'todo list' plasmoid is good idea. I think plasmoids should be provided by apps, like KGet that includes a plasmoid. so rss readers should go into Akregator.with a datanengine that gets data from Akregator... this way 3 rss readers should go into akregator and notes applet should go into knotes.TODO list viewer should be provided by KOrganizer and... (btw, the RSSNOW applet is so cool)

Re: Plasmoids in apps - Jonathan Thomas - 2008-03-24

I never use akregator. Why should I have to download (Or, keep it installed since its a KDE application) a whole new application just to get a desktop widget? As long as the widget doesn't depend on the application (such as those provided by Amarok, for example) they shouldn't be bundled with the application.

Re: Plasmoids in apps - Rob Scheepmaker - 2008-03-24

I agree, that all those rss reader's should share their data with akgregator, but making those applets part of akgregator isn't the way to go. Since KDE4 has got akonadi for exactly these kinds of purposes. When there's a akonadi dataengine for plasma, all RSS data could be shared by all RSS applets/akgregator. And this way, nobody is forced to install akgregator if they just want one of those applets. Glad to see you like RSSNOW btw. :)

Re: Plasmoids in apps - Martin Fitzpatrick - 2008-03-24

If the 'TODO list viewer' is a reply to my comment above asking for one then I should clarify I wanted a plasma applet that was integrated with Kontact/KOrganizer. I use that for managing all my time and would prefer to have it available on the desktop rather than buried in the app. Definitely don't want more standalone tools!

Re: Plasmoids in apps - sebas - 2008-03-25

Akonadi is supposed to provide the data to both applications or applets. Till Adam has shown during the talk at last Summer's aKademy that it's relatively easy to have Plasma and Akonadi interact with each other. I'm pretty sure once Akonadi is in use, Plasmoids using that will pop up quickly. That's probably 4.2 timeframe, though.

Re: Plasmoids in apps - Aaron Seigo - 2008-03-25

i dunno ... the fact that we have three rss readers sort of goes to show how easy it is to write these sorts of things now. the rss lib in kdepimlibs and plasma make it really trivial. and part of the idea of plasma is that no one person knows exactly how you want to do it. so ... we make it as easy as possible to create your own things. magically, people are doing just that. that said, i think it is great to see kalzium, kget and akonadi (to name three) shipping plasmoids and engines of their own. that kind of integration can only get us even further. and thankfully, those two things (proliferation of MyPlasmoids and nicely integrated default plasmoids) are not mutually exclusive. we can do both.

Re: Plasmoids in apps - Kerr Avon - 2008-03-26

Aaron, I have only had a little play with a live CD of 4.0.0 so maybe I am missing some of the vision here but are these standalone plasmoids simply going to sit on the desktop? If I have a lot in use, won't they just clutter up the screen real estate and make it unusable? I know we can resize applets but I don't want to be doing that every time I need a function. That would mean: 1. Minimise running applications in order to see the desktop 2. Locate and highlight the running plasmoid so that the border appears 3. Drag to resize so that I can read it 4. Use the applet 5. Resize it back down 6. Go back to using whichever application I want This is quite a few steps and seems a little clumsy. Could we call applets to the forefront of the screen with shortcuts so that they appear "layered" over the top of running applications? That way, we wouldn't need to return to the desktop all the time. Alternatively, is that zoom feature going to be used to simply zoom in on the plasmoid we need on the desktop? Please explain as I am probably missing some of the "vision" for the KDE4 series here! Thanks, mate.

Re: Plasmoids in apps - Fool - 2008-03-26

You already can do this (from day 1), I believe you have to press ctrl-f8 or 9 or something like that. I don't use it that often cos I don't use plasmoids (yet...no must have plasmoids for me yet).

Re: Plasmoids in apps - Rob Scheepmaker - 2008-03-26

You can allready do this. Just press ctrl+f12, and your desktop with all it's applets will magically appear in front of your applications (which looks really cool with compositing enabled btw). And stuff where you allways want to keep an eye one, you can just put in the panel.

Re: Plasmoids in apps - jos poortvliet - 2008-03-26

1 won't be necessary, see other comments. 2, 3 - zoom might help there. 4 - of course you need that ;-) 5 - zoom 6 just click on a window which is still visible behind the applets and you go back.

Re: Plasmoids in apps - Kerr Avon - 2008-03-26

Thanks for all of your prompt replies, Gents. I'll have another play with KDE 4.0 very soon (when Fedora 9 is released!) Cheers.

Re: Plasmoids in apps - Emil Sedgh - 2008-03-26

Hi having standalone plasmoids has a few problems: 1)every standalone plasmoid needs a maintainer.so we will have the problem of 'unmaintained' plasmoids in future. 2)The process of playgground->kdereview->kdebase-workspace will be there just for little plasmoids.really, plasmoids are little, they are not full applications... 3)hunderds of bugzilla entries just for little plasmoids? reporting those bugs would be confusing... im not saying all plasmoids 'should' be included in an application.sure, some of them should be standalone.for example minimize/show desktop or analog clocks...but look at current status: the new plasmoids for konqueror/kate/konsole profiles should be included in konqueror, kate and konsole.not kdebase or anywhere else. about the fact that a little rss reader shouldnt depend on akregator, i must say that third party plasmoids will come for that.but plasmoids that are included in KDE should be intergrated.

Re: Plasmoids in apps - jos poortvliet - 2008-03-26

Most plasmoids will be available from kde-look, just like styles, superkaramba applets etcetera...

Another C++ Parser? - Anon - 2008-03-24

Generally I'm in favour of making competing implementations of a thing, but a CPP parser (a proper, full one) is a very large and difficult task, and KDevelop's one seems to be quite far along and sounds like it will be top-notch, from what I hear. May I ask what is the rationale for the Umbrello devs to write their own one from scratch?

Re: Another C++ Parser? - David Nolden - 2008-03-24

I Agree. I don't know what level of completeless they need, so maybe a simple parser will do for them, but if they want "real" code-flow understanding, they should better think about interfacing umbrello with KDevelop through a KDevelop-plugin.

Re: Another C++ Parser? - Ian Monroe - 2008-03-24

All they need is to be able to parse .h headers for class, method and property names. Doxygen comments if they are feeling fancy. Nothing like KDevelop's parser.

Re: Another C++ Parser? - Anon - 2008-03-24

Aha, that makes perfect sense - thanks, Ian!

Re: Another C++ Parser? - Robert Knight - 2008-03-24

> Nothing like KDevelop's parser. Presumably they would like to be able to read project files as well though - which is necessary to figure out how all the code fits together. KDevelop 4 has a lot of useful code for this.

Re: Another C++ Parser? - Ian Monroe - 2008-03-25

What project files keep track of interdependencies? Anyways... that's not C++.

KNetworkManager - User - 2008-03-24

Does anyone know the status of KNetworkManager in KDE4 ? I see work is being done on knetworkmanager in the work branch, but afaik this has nothing to do with KDE4(trunk). I depend on this program every day with lots of different wlans and vpn connections, so if it is going to TRUNK I'm more than willing to contribute with some fixes where needed.

Re: KNetworkManager - djvnklhjefjmwfn - 2008-03-24

Isn't KNetworkManager replaced by Solid?

Re: KNetworkManager - Erunno - 2008-03-24

Well, kinda. Solid will use NetworkManager as the default backend on Linux but as far as I know it's not ready yet. Still, someone will have to write a Plasmoid which offers KNetworkManager's functionality via GUI.

Re: KNetworkManager - Pascal - 2008-03-24

oh no! My impression of the NetworkManager guys is not very good after they have refused to implement the "Refresh wireless networks-list". Come'on! This is an invaluable functionality. I took my laptop in the bus. When I arrived I had 200 networks in the knetworkmanager and the one I wanted to use wasn't discovered yet. That is just plain dumb!!!!!!

Re: KNetworkManager - hias - 2008-03-25

I also hate it. There is a solution to work around it. It's not perfect, but it works. For Kubuntu it's the following /etc/dbus-1/event.d/25NetworkManager stop /etc/dbus-1/event.d/25NetworkManager start

Re: KNetworkManager - Erunno - 2008-03-25

Is this actually a functionality missing in NetworkManager itself or is it just not exposed via a GUI in nm-applet/KNetworkManager?

Re: KNetworkManager - Pascal - 2008-03-25

It's with NetworkManager itself. The knetworkmanager guys would like to fix it. There is a bugreport for it somewhere in bugs.kde.org where they explained it. Danm those gnomers ;-)

Re: KNetworkManager - User - 2008-03-24

I build KDE trunk today and tested. KNetworkManager 0.2 runs without a glitch in the systemtray, so I guess its really not a problem.. Still wonder if it will be ported to KDE4 though

Re: KNetworkManager - Christopher Blauvelt - 2008-03-24

The networkmanager applet will be a functional replacement for knetworkmanager. However, rather than AP based it will be profile based. So you'll be able to click on the applet, and select a profile such as "Work", "Home" or "Connect to any wireless network" Profile creation will be wizard or systemsettings based. The network management portion of Solid is being re-worked by Will Stephenson to better accomodate changes in NM 0.7 and be more extensible in the future.

the constant - Francesco R. - 2008-03-24

the velocity of development in kde 4.{0,1} make me wonder if there is something like the C constant 10^8 m/sec for speed, 10^8 LOCs per release or whatever ... keep going the good works heroes

Re: the constant - Martin Fitzpatrick - 2008-03-24

:) Is 4.0.3 still on for tag/release around the beginning of next month? http://techbase.kde.org/Schedules/KDE4/4.0_Release_Schedule#26_March_2008:_Tagging_4.0.3 I tried out the 4.0.2 and although it fell apart to the point of unusability (some self inflicted) I'm looking forward to having another go at it. As soon as it's useable I'll be over full time and helping bugsquash :) Any know if there's any chance of multiple panels soon? Thanks for all the hard work & Danny for the digest.

Re: the constant - sebas - 2008-03-25

Trunk has multiple panels. I'm not sure if that's been backported last weekend, so have a look at the commits by Riccardo. If it has been backported, it'll be part of 4.0.2 on April 2nd.

Wow - Jakob Petsovits - 2008-03-24

The commit digest on Easter Sunday. Now if anyone complains once more about delayed publication and alleges Danny of lazyness, I'll hunt them down and break their legs. That's just awesome Danny! Major coolness.

Re: Wow - Pascal - 2008-03-24

well, actually it is a week late. But I appreciate reading it as much as the next guy! Thanks Danny

Re: Wow - anonymous coward - 2008-03-25

pascal, you better watch out for jakob now! :)

Re: Wow - anon - 2008-03-26

10 days late, retarded. Time Danny got the boot, and someone else given the chance to get these out timely.

Re: Wow - jos poortvliet - 2008-03-26

Aaah, I guess you volunteer? I hope you understand the Commit Digest will stop coming if Danny stops writing them, right? Nobody wants to do it because it is a huge amount of work... So if you consider 'never' timely, just keep on saying these things. Maybe Danny will quit and you can be happy cuz by then we won't have any news left (he's also a very important editor for the DOT).

Re: Wow - Anon - 2008-03-26

They already "have the chance" (all information needed to prepare a Commit Digest is freely available) and yet, there is a curious absence of people stepping up. This is probably because you are the only person in the world who considers the Commit Digest running a few days late to be even worth commenting on, let alone spamming every edition about.

Re: Wow - Bobby - 2008-03-26

"This is probably because you are the only person in the world who considers the Commit Digest running a few days late to be even worth commenting on, let alone spamming every edition about.". And the worst thing is that he uses a name similar to yours, only with a small "a". Can't you kick his ass?

Re: Wow - Anon - 2008-03-26

"And the worst thing is that he uses a name similar to yours, only with a small "a". Can't you kick his ass?" If only it were that simple :(

Re: Wow - Fool - 2008-03-26

everyone should stop replying to these idiots...they're just trolling

Re: Wow - Bobby - 2008-03-25

Don't understand all that you wrote as my maths isn't that good :D But I too would like to commend the dream KDE team for the remarkable job that they are doing up there, down there - wherever. I just did a Suse update (KDE 4.0.66) and I can tell you, I got a pleasant surprise! Improvements, bugs squashing and polish all over the place, from Amarok 2 which I am now using to listen my mp3 collection as I type (I never had luck before) to Dolphin (preview now works like it does in Konqueror), Kickoff, which is starting to even look visually attractive ;), Oxygen, which is starting to feel like it's name implies and Plasma. Yes the Plasma quys would make Asafa Powell look like a tortoise at the speed they are going these days :) I like the slim-glow theme btw. There is also quite a bit of improvement in speed, the present devel-version that i am using feels a lot faster, smoother and more stable that the stable 4.0.2. I am just wondering what it will be like by 4.1? In any case I am sure it will be a hit!

What about KDE Linux MCE? - Poldark - 2008-03-25

First of all, congratulations for the good job done with KDE. KDE4 has a huge potential, as we can see with every release and every commit-digest! On the other hand... Does anyone know anything about Linux MCE integrated into KDE? The last news I can find about it are from at least 6 months ago, and they tell us that Linux MCE will be integrated into KDE4. Thanks in advance for your reply and thanks for this great desktop! Poldark

Re: What about KDE Linux MCE? - Dog - 2008-03-25

Ask on their mailinglist or read it http://www.charonmedia.org/mailman/listinfo

Re: What about KDE Linux MCE? - Bernhard - 2008-03-25

yeah.. i'm wondering about this fact too. I've also found nothing neither in the linuxmce forum nor on any mailing list I'm subscribed (and those are many ^^)

digikam and raw 16 bits color depth auto gamma... - Gandalf - 2008-03-25

In commit log we can see: "RAW image loader : backport 8 bits color depth auto-gamma and auto-white balance adjustements from dcraw with 16 bits color depth. These auto adjustments are performed only if Color Management is not used with image editor. The color rendering in 16 bits is exactly the same than in 8 bits. This is want mean than you can process speedly your RAW exactly as JPEG. Just set your usual settings in RAW dedoding and open your RAW pictures as well in editor. This is the same way used by LightZone pro software to process RAW file without color management! This way simplify the task in Raw workflow... and will be suitable in 90% of case. Color Management must be used in others cases..." Anybody has tried this feature? There is a comparison somewhere between LightZone and digikam about raw files import ? Sound like a major improvement because current raw file import always give a black image with 16 bits color depth.

Re: digikam and raw 16 bits color depth auto gamma... - digiKam <-> LightZone comparisons... - 2008-03-26

Here: http://digikam3rdparty.free.fr/Screenshots/RAW16bitsAutogamma ... there are few screenshots. All are divided in 3 parts: - on the left: RAW converted to PNG using dcraw with 8 bits color depth. - on the midle: RAW loaded in digiKam Image editor with 16 bits color depth. - on the right: RAW loaded in LightZone. Like you can see, it's not exactly the same between digiKam and LightZone, but digiKam auto-gamma is not too bad and give a fast way to handle a suitable image with the best color quality. Gilles Caulier

Bennefit of Plasmoids ? - Mark - 2008-03-25

So Plasmoids can kill the whole window system, at least from the user's perspective. Is this a step forward in desktop computing ? I mean the beauty of X applications and the X desktop was that applications were isolated and the window manager was king. And very very stable. So we have more eye candy, but how functional is this. Is it even necessary. For instance I can launch knotes application or a note plasmoid, very little difference in how they look. Granted I can rotate the plasmoid, but what value is that. Who really even cares about eye candy. I mean Vista and Mac have their own plasmoids but who ever uses them, except for maybe a clock placed on the corner of the screen. Please somebody explain the value of Plasmoids. Maybe they are easier to write via a scripting language. I know KDE has spent a lot of resources on doing usability studies, and it has paid off as things are are more consistent and better laid out. Has there been a need's study for Plasma, if not maybe there should be one. And if found to be important it stays in as is, if not the KDE Window manager gets redesigned and Plasma gets taken out. Sounds like heresy I know,as a lot of hard work went into it. but what is best for KDE, and the KDE users How about putting a simple poll on the KDE website. One question "How do you value the use of Plasma (1 no vaule, 10, grat value) I give it a 3

Re: Bennefit of Plasmoids ? - blubb__ - 2008-03-25

Plasma is not only the Desktop Widgets. Plasma is about the Display and Behaviour of your whole Desktop. This for example includes the Desktop surface itself and the Bar that was formerly Kicker and is now more generally called the Panel, including its typical features like the taskbar and the start menu. I see it like this: The developers noticed that there is a lot of shared properties in the different parts of our desktop, and they need to cooperate so tightly, that it makes sense to integrate them. So they designed an architecture which generalizes some of the common capabilities, which are now shared between these parts through libplasma. Formerly, there was code to display icons in kdesktop, code to display desktop widgets in superkaramba and code to display icons in kicker. Now this is all done with (nearly) the same code in plasma. This alone makes perfect sense to me and justifies the use of Plasma. And there is a lot of additional value, like the option to write Plasmoids in Scripting Languages and share data sources across all Plasmoids. > And if found to be important it stays in as is, if not the KDE Window manager > gets redesigned and Plasma gets taken out Plasma is not implemented in the Window Manager, and neither was the desktop in KDE 3. It was also a dedicated process.

Re: Bennefit of Plasmoids ? - Aaron Seigo - 2008-03-25

first, no, vista and mac do not have their own plasmoids. they have widgets. there are some pretty fundamental design differences between how these things are done. and yes, if you pick the right use cases (e.g. notes vs knotes) and ignore everything else you can construct an argument for your case, just don't expect me or anyone else with any insight into the matter to take it seriously. you're concentrating on widgets in isolation and completely ignoring the componentization, cooperation, grouping and portability of them. now, to get to your opening: > Plasmoids can kill the whole window system no they can't, no more than any other window in your session can. your rant here starts out on a completely incorrect assumption. way to go. > if not the KDE Window manager gets redesigned and Plasma gets taken out. the window manager has nothing to do with plasma. this sentence is just .. well .. nonsense =) > I give it a 3 then don't use it. it's that simple. whoe needs launchers, a pager, a system tray or a taskbar, right?

Re: Bennefit of Plasmoids ? - Iuri Fiedoruk - 2008-03-26

My take: - from the user perspective, until now plasma is just a fancy superkaramba that kills your desktop when one plasmoid crashes (duh, very nice one!) - from developers it's heaven to code and shall lead to better to faster/easier development of the whole desktop Now if we could get rid of *ALL* plasmoid written in C++, the plasmoid crashing and taking away the whole desktop won't happen, but I don't see much script plasmoids so far, only C++ ones :-P

Boring news? - Iuri Fiedoruk - 2008-03-26

It is just me or the exiting news in KDE4 are diminishing? I would love to see news about k3b, panel (lots and lots of missing features there), kmail, kopete, etc. To me, this looks actually like a good thing, probally things are starting to get more mature in kde4 code. Anyway, in this edition I found good news about amarok, ktorrent, phonon supporting subtitles and multiple audio/text/video tracks is very good, I hope they do support font rendering options (font face, size and color). Meanwhile until KDE 4.1 arrives I wait for 4.0.3 that will come with fixes for my most hated bugs (gray desktop instead of wallpaper and no double click).

Re: Boring news? - Koko - 2008-03-29

Boring? "David Faure committed changes in /trunk/KDE/kdebase/apps/konqueror/settings/konqhtml: GUI: checkbox for the "Middle click on a tab closes it" option (which has existed for a long time, but didn't have a GUI)." !!!!!!!!!! :DDDDD