KDE Commit-Digest for 17th June 2007

In this week's KDE Commit-Digest: Work on engine configurability, data management, a packaging system for Plasmoids and themes, and new refinements in desktop icon interaction in Plasma. The Oxygen window decoration and widget are both moved into kdebase. Further work in the Icon Cache, Kopete Messenger update, KRDC and Context Help Summer of Code projects. Improved highscore handling and network management across kdegames. New keyboard engine becomes live in KTouch, whilst the Step physics simulation package receives support for annotations. Support for many new text styling options in KOffice. Further work towards Amarok 2.0, including work on the context view and the display of lyrics. More recent and precise elevation data added to Marble. KColorScheme colour roles are added to aid usability. User documentation is started for Dolphin. More work in Strigi and NEPOMUK. Work on vector selections and a smoothing algorithm for drawing implemented in Krita. Many improvements in the KMix sound management utility. Digikam begins to be ported to KDE 4. Large scale reorganisation in the kdegraphics module: KColorEdit, KIconEdit, KPovModeller, Kuickshow and Ligature move to extragear/graphics, whilst Kooka and kmrml are removed completely.

Dot Categories: 

Comments

by Martin Koller (not verified)

You can also simply start typing after you selected a timerange, and automatically the "new Event" dialog appears. Alternatively, you can press the ENTER key after selecting a timerange, which also brings up the dialog.
So it's not really complicated.

by Schalken (not verified)

I would just like to say that Plasma's icons look fantastic!

The faint white rounded border improves visibility/viewability/readability (?) greatly as icons now have a distinct border and 'area' that is that icon.

And the quick buttons that appear in the corners of icons is both ORIGINAL and USEFUL.

Well done Plasma team! :)

by Aaron Seigo (not verified)

thanks for kinds words of encouragement; we've got a lot more coming, too, so fasten those seat belts. =)

by Leo S (not verified)

While they certainly appear very cool and useful, I'm going to reserve judgement on those quick actions until I've seen some less experienced users interacting with them. Sometimes making something too easy to access (a single click on an area of the icon) is setting up users for a lot of mistakes (performing an action when they just wanted to select). Just like click to rename in Windows is a disaster for new users, or drag and drop in menus.

by Aaron J. Seigo (not verified)

why reserve judgement? test now.

goddess help us all if we just sit back and throw ui ideas into a pot. there has been some testing of the hover interface concept, and you'll find them increasingly appearing elsewhere in the software world as well.

that said, the version that was committed to svn was somewhat of a draft and not the version of these things that i had tested on people.

there's an easy way to fix that, but it doesn't involve reserving things =)

by Leo S (not verified)

Ah, but the best test is on real users. I fully support putting this into KDE4, and in a few months it will be much clearer whether it is good or not, based on user feedback.

I'm running a full blown usability study on some of my software right now (20 non-disabled subjects, and 5-10 people with various disabilities), and it's not an experience I necessarily want to get into again without some serious consideration.

While it can teach you a lot, it is also extremely difficult to get any sort of generalizable results from usability testing in a lab setting. Either you control your environment so much that the results are very specific to your task, or you make the task more open and end up with confounds. It's a delicate balance, and usually you are better off just creating the feature and trying it out on real people.

by Aaron Seigo (not verified)

agreed. here's what i've been doing for the last while:

- the "coffe house method". take my laptop to a coffee shop or other relaxed and open environment. invite people to try out application X and accomplish a few tasks. this way real people are using real software in a real environment as they might if the machine was theirs and they were doing some work/play in a coffee shop. the results tend to be pretty accurate and revealing because of this, ime.

- the "jane goodall method". i invade my friend's offices and sit behind them and observe them using their current computing system to see what fails them and what works. every so often i'll ask a quick question about what they are doing or why they did it that way. when doing toolbar research i actually managed to get people to log their toolbar icon usage for me.

both approaches involve real people in real settings and don't take up a lot of there or my time. it's amazing what people will do for you if it is for an ethical, not for profit global project.

it's also a cool way to spread the word about kde, especially in the coffee house approach.

i've also blown a few minds when something fails for the person in the coffee house method and i take the laptop back, type madly for 10 minutes or so then give them the laptop again to try with the changes. very few people have had a chance to see the software development practice up close so it's pretty neat to see the look on their face when you bring them changes for testing based on their experience and feedback from a bit earlier.

i'm not a huge fan of lab based research, partly because it feels so boring but mostly because, as you pointed out, it's both labour intensive and of questional utility.

by Martin Stubenschrott (not verified)

Wow, that post was really useful to see how you do testing of new features, thanks for the info.

by me (not verified)

"The Oxygen window decoration and widget are both moved into kdebase"

Is there any screenshots or video? just to take a look

Bye

by DITC (not verified)

Can anyone tell me when there will be a new alpha build for KDE4. I would like to try it out with all the new eyecandy. Will there also be some packages for Kubuntu oder do I need to compile KDE on my own?

by makosol (not verified)

Beta is planned for 25/06/07.

by Anonymous (not verified)

The SUSE KDE 4 packages are updated weekly from SVN. Also there is a new Live CD with snapshot of last week available.

by makosol (not verified)

Where can we grab those updated live-CD ?

by Simon (not verified)

http://home.kde.org/~binner/kde-four-live/ - or you could hove googled kde4 live cd ;-)

by dario (not verified)

First of all, cheers for the entire KDE4 team: the developments are astounding!

Now, I have a couple of questions concerning the plasmoid packages:

a) Have you discussed with distros about the integration with their own packaging solutions?

b) Do plasmoids run in a sandbox of sorts? I realise that the plasmoid packaging system will probably only cover scripts for which the source code is available (JavaScript, Python, Ruby, etc), but nevertheless, there are security implications if some malicious website lures users into "download our awesome dancing hippos plasmoid!"...

by Emil Sedgh (not verified)

Hi

"a) Have you discussed with distros about the integration with their own packaging solutions?"

I think KDE has KHotNewStuff(2) to avoid that.these are Distro Independent, User Level stuff.
for example a user wants to add Cool plasmoids to his Desktop, should he have Root Password to install the Plasmoids Deb Packages?not really...

by Diederik van de... (not verified)

I think you should compare this with Firefox extensions. Users won't and shouldn't look for the 'firefox-webdeveloper' or 'firefox-firebug' extension in their package browser. Or a "kdelook-wallpaper-N" package. Each user has different preferences for their extensions, so this is a user-level thing, not system-wide.

by dario (not verified)

True, but bear in mind that Firefox extensions *are* available as packages in at least some distros (like Debian et al). It does make some sense to have a system-wide manner of updating them because of bugs, for example.

In any case, Firefox extensions provide a good reference point from which Plasma developers can design their packaging system. I am thinking in particular of the problems related to security (will plasmoids be authenticated somehow?).

by Aaron J. Seigo (not verified)

> but bear in mind that Firefox extensions *are* available as packages

just as kicker applets are and, in the future, plasmoids will be. the concepts are parallel and don't really interact in the way you seem to be implying.

> have a system-wide manner of updating them

for ones that are installed system-wide, sure. for things that the user installs themself, maybe not so much.

we do support versioning of the packages, however, so we could offer update notifications.

> Firefox extensions provide a good reference point

what would you suggest are the strong points to learn from?

note that plasmagik packages are already quite flexible (runtime definition of expected package structure), integrate with kde's plugin metadata system and there is a GUI to step one through the creation of a package so you don't have to do it by hand. plasmoid packages themselves may also come in a few different scripting languages.

> will plasmoids be authenticated somehow?

see my other reply in this thread.

by dario (not verified)

> just as kicker applets are and, in the future, plasmoids will be.

Excellent!

> what would you suggest are the strong points to learn from?

I was thinking of a) a trusted repository like the Mozilla Addons site (which Plasma will also have, as you mentioned in the other thread), b) a notification of when updates are available (which again Plasma will also have), and c) a straightforward way of installing/removing plasmoids (which I am sure is also in your plans). In fact, you seem to have everything already covered! Moving on...

> we do support versioning of the packages, however,
> so we could offer update notifications

Yeap, that would be very useful, particularly for those plasmoids that the user has privately installed, ie, those that are not system-wide.

But consider that the update mechanism will have to distinguish between packages that are installed system-wide and those that are privately installed. Just imagine the following situation:

There is a "Foo 1.0" system-wide plasmoid installed, and the user has a private installation of "Bar 1.0" (there are no dependencies between the packages). Now, a new version 2.0 is released for both Foo and Bar. The plasmoid updater will of course notify the user that the new versions are available. In the case of Bar, upgrading is straightforward, but what to do with Foo? One option would be for the plasmoid updater *not* to upgrade and instead to inform the user that they should use whatever mechanism is available in their distro to perform a system-wide upgrade. This has the disadvantage that the distro's update for the Foo plasmoid could take a while before it is available from their repositories. Another option would be for the plasmoid updater to upgrade anyway, installing version 2.0 of Foo as a private installation (which supersedes the system-wide package). But then you have the question of what happens when the system-wide package is also upgraded: will you end up with two copies of the same package, or will the plasmoid updater be smart enough to remove it when no longer needed?

by Aaron Seigo (not verified)

i've actually thought about the issues you bring up in your last paragraph. for now, i'm punting on it but will revisit it for 4.1. it is a non-trivial problem, but we do have all the pieces we need to create a proper solution so i'm not worried. it's just doing the rather detailed work.

right now i'm concentrating on getting the Big Basics together for 4.0... the cuter stuff, like managing differences between local and system wide installs of plasmagik updatable packages, will come after that

by dario (not verified)

> it is a non-trivial problem

Indeed. And it gets all the more non-trivial once you start taking package dependencies into account... But anyway, you are right that it is perhaps a bit too soon to be worrying too much about it.

But when that time does come, be sure to have a chat with the Debian guys about this issue; I wouldn't be surprised if they had already encountered it and given it a lot of thought...

by Aaron J. Seigo (not verified)

dependencies are pretty much a non-issue. we're talking about leaf-node add-ons here.

by Jack H (not verified)

I also have security concerns here. Aaron said in an interview that the user would be able to download and run plasmoids with just one click. That would be awesome in an ideal world, but in the real world it actually frightens me a bit!

by Aaron J. Seigo (not verified)

ghns allows one to authenticate packages using gpg signing and we will control the main repository.

i don't see people freaking out about grabbing rpm's or deb's from central repos for these very reasons.

heck, i didn't see gentoo people freaking out when they didn't even have gpg signed packages. (has that even been fixed yet?)

by dario (not verified)

Concerning the security of plasmoids, having a main KDE repository will go a long way towards allaying security concerns. As you mentioned, users already install binaries from distro repositories without second thoughts because they explicitly trust their distribution maintainers. And ditto for Firefox extensions available from the Mozilla site.

I am sure the same will happen with plasmoids coming from a KDE repository: after all, we already trust you guys with our entire desktops!

In any case, are plasmoids plenipotent? Even if the code is trusted, it would still make sense to have some degree of sandboxing to protect from potential exploits.

And yes, I realise the same argument could be used for any application in the system, but bear in mind that plasmoids will use languages such as Javascript, which are far more brittle.

by Vide (not verified)

Sorry Dario, IMO the difference is simply "executed embedded in a remote page" or "executed locally after being downloaded". Plasmoids AFAIK fall in the 2nd category

by dario (not verified)

I agree with you, but that was not the reason why I suggested that some sort of sandbox would be a welcome feature for plasmoids. Yes, you could make the traditional assumption that "if the user has willingly downloaded it, then they must accept the consequences". However, the fact is that many plasmoids will be built using loosely-typed languages with no compile-time checks (Javascript springs immediately to mind). This means they will be far more prone to bugs and exploits. To compound it, many plasmoids are likely to be network aware, and will therefore receive data from outside sources. That alone is an exploit waiting to happen. Are you willing to trust the integrity of your system to a Javascript programme running outside a sandbox? Personally, I would have my doubts.

I know that some might still argue that once you trust an outside programme, it shouldn't matter if it's made in C++, Javascript, or whatever. But it does matter: due to language and compilation constraints, a C++ programme is far more solid than a Javascript one. (And for those that still insist that all programming languages are equally error-prone, then you must have been using all the wrong ones!)

by mabinogi (not verified)

Dynamically typed languages are less prone to certain classes of security related bugs than certain statically typed languages.

I'd be far more willing to trust a Javascript program than a C or C++ one.

The idea that dynamically typed languages are automatically buggier than statically typed languages is absurd.
In something like Javascript, if you pass the wrong type, you'll get a well defined runtime error when the receiving code tries to execute a method or access a property that doesn't exist.

In C, if you pass the wrong type, sure the complier may warn you (in the simplest case, but in a large number of cases you'll never notice because you've probably cast it, or are using void * as a polymorphism mechanism), but it will often still compile, and then at run time rather than throw an error, it'll attempt to execute some random code - which will _probably_ just cause a crash, but which also may expose a security problem.

C++ is a little better on that front, but mostly because there's less cause to cast and use void pointers, not because such things are impossible.

In practice, passing the wrong type just doesn't happen very often - not anywhere near as often as off-by-one errors, and going off the end of arrays, neither of which are catchable at compile time, even in the strictest of statically typed languages.

by dario (not verified)

> Dynamically typed languages are less prone to certain classes
> of security related bugs than certain statically typed languages.

I agree. But you do realise that your "certain" qualifiers weaken your entire argument? You said it yourself: "less prone to *certain* classes of security bugs". Because there are *other* classes of bugs far more common in dynamically typed languages. Likewise, "than *certain* statically typed languages" betrays another weakness: C is hardly a good example of strong, statically typed language. Even C++ is a borderline case!

> The idea that dynamically typed languages are automatically
> buggier than statically typed languages is absurd.

I didn't say "automatically". I said they are far more bug-prone, which is hardly controversial.

> In something like Javascript, if you pass the wrong type,
> you'll get a well defined runtime error

Dude, there lies the crux of the matter: I would rather have bugs being caught at compile-time than at runtime! If your language allows a programme to even start running when there are such gross type inconsistencies, then that language is prone to being abused by lazy programmers.

> In C, if you pass the wrong type, sure the complier may warn you

Well, C is a straw-man, isn't it? It has such a weak type system that it doesn't deserve to be lumped together with the strong, statically typed languages.

In any case, having a compiler warn the programmer at compile time is far better than getting runtime errors!

> In practice, passing the wrong type just doesn't happen very often

Yes it does. You can have type inconsistencies even in a C++ programme that compiles with no warnings. You never realise those type inconsistencies because the compiler is not smart enough to spot them, and the syntax of language is not expressive enough in the first place. But if you tried the same algorithm in a *really* strongly typed language such as Haskell or Ocaml, you would see just how many type inconsistencies go unchecked in more conventional languages.

by Jack H (not verified)

"...we will control the main repository."

Alright, good enough for me. I wasn't freaking out, I was just worrying if it would be too easy to download and run malware by accident. :-S

by Emil Sedgh (not verified)

Hi
Where will Filenames go, and will they support Thumbnails?
Thanks.

by Anon (not verified)

On top of this: I know that Aaron has put a lot of emphasis on making sure all Plasma elements are scaleable (in terms of physical size, that is). Will icons be resizable, and will the thumbnails adapt to the new size if the user resizes them, even to very large sizes?

by Emil Sedgh (not verified)

Hi
and as I know, SVG is resizable.are the Preview's SVG graphics?
If yes, that could be easy, if no, Im thinking about Mime icon, which Thumbnail Preview is placed on Top of it, if we resize Plasmoid, Mime Icon became bigger (and visible) but Thumbnail Preview stays small.
Maybe Im wrong, but Thumbnail Previews are one of the biggest helps while finding Files between lots if others.
and...Another question, what happens when you create an Icon in the Desktop? the file copies in the ~/Desktop Folder?do we have suck folder with Plasma??

by Aaron J. Seigo (not verified)

> are the Preview's SVG graphics?

no work has yet been done on this. we'll find out when someone does something ;)

> the file copies in the ~/Desktop Folder?

right now you just get a link to the file or resource. we don't actually store copies of the file right now. this will likely become an option in the future, but i really find "~/Desktop" to be one of the most clumsy ideas around. why can't i have multiple folders that show? why treat the desktop layer as a dumbed down file manager? etc...

> do we have suck folder with Plasma??

i hope to allow easy access to 0, 1 or many.

by boemer (not verified)

Apple had a nice idea with 'stacks' in there WWDC Keynotes video.

It could go like this: if you download something to you're desktop, there would be one stack-icon, with the last thing you downloaded in front. When you move over it it would show in historical order everything that is downloaded.

This would make the desktop a little less cluthered... And ofcourse this idea could be used in other cases also.

by Aaron J. Seigo (not verified)

"stacks", you mean the thing we discussed and documented openly at the first appeal meeting some 2 years ago?

yes, they beat us to the implementation, but i'm seeing more and more of our openly discussed ideas find perch in industry. which is great.

of course, it jobs&co. decide to start patenting some of this stuff, i'll be the first to show up at his house with my pitchfork and torch.

personally, i've had enough of their "we can invent cool stuff" when really they've invented very, very little combined with their "we can patent it too!" position. oh wait, i just described most proprietary software shops!

by Ted (not verified)

The rate of progress is really astounding. I'm sure to an insider it was also fast back in the "rewrite the library" days, but now it's much more visible to the rest of us. At this rate, I bet Danny's having a hard time keeping up with it all! Good work all round.

by m. (not verified)

Yes, it is really great to see how all small steps
in the past are accumulating to wonderful effect.

KOrganizer styling isn't maybe the most important thing
but undeniably improves personal feeling of application.
I wonder if it would be possibly to get "Quote of the Day"?

by David (not verified)

True! Sometimes one tends to forget how much work it must be to plan, program and maintain such a big project like KDE and its applications is. Software Projects tend to fail at some point, but the good projects always evolve. KDE is among them and has a very cood code base as far as I can judge.

Thanks to all the involved folks that do all the documentation, developing and translations!!

Special thanks to the writers of the techbase tutorials, that make it so easy to get a KDE 4 development environment up and running. This also attracts new contributors and is very important I think!

Keep it up!!

by Joergen Ramskov (not verified)

Agreed, but I would like to add that I think KDE4 has been progressing fast for a long time, all the work until recently have just been "under the hood" and you haven't really been able to see all the work that has been done there. Now the ground work has been done and the developers are able to work on all the nice visible stuff like plasma.

by Emmanuel Lepage (not verified)

Hi, i just updated my kde4 desktop to the lastest svn and i deleted the .kde from my testing account but the default style and windeco is plastic. How can i set oxygen? (kcontrol is not working so please dont answer this).

And an other question, last years i read that plasma was ready to support apple dashboad widget, but i cant not load them, is it still planed to support those widget?

by Anonymous (not verified)

Just open a Konsole and enter

kcmshell style

And don't forget to post screenshots ;-)

by Emmanuel Leoage (not verified)

Thanks!

Here are the screenshot

As you can see, the windeco dotn really work and crash after few sec and the style load only for the style windows (it is not the demo, the style is loaded, but not on other windows, that strange)

by Emmanuel Leoage (not verified)

The screenshot did not upload...

here it is:
http://img361.imageshack.us/img361/319/capture24iv2.png

i will add that today windows efects dont work

by Aaron Seigo (not verified)

> last years i read that plasma was ready to support apple dashboad widget

no, zack said it -would- support such widgets. this is among my 4.1 targets and relies on a few things happening first, including the completion of the kde/webkit part.

remember that some dashboard widgets include coacoa bundles which we will have no way of supporting, so it is only http+css ones that can work.

also, by 4.1 we may find we have equal or better replacements for all the dashboard widgets and so this support would be unnecessary.

by Jonathan (not verified)

Is there still development going on with sonnet (spellchecker)? There hasn't been any news about it for months...

by Aaron Seigo (not verified)

it's stalled at the moment, but that happens fairly regularly with open source components so it's not a reason to get overly concerned. i'm sure it'll pick up again at some point. =)