KDE Commit-Digest for 17th June 2007

Monday, 18 June 2007 | Dallen

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.

Comments:

"Kooka and kmrml are removed completely." - Evil Eddie - 2007-06-18

Is a replacement planned for Kooka? Otherwise I'm curious how one should scan under KDE 4.

Re: "Kooka and kmrml are removed completely." - Aaron J. Seigo - 2007-06-18

all the important bits are in libkscan which is still in kdegraphics. various applications use this already, such as kword and krita. the idea is to scan from the app you will be using the results in. if someone writes a new app that acts as a shell around libkscan, much as kwrite is around katepart, that could be cool. but we already have scanning available without kooka in both kde3 and 4.

Re: "Kooka and kmrml are removed completely." - Kyle Williams - 2007-06-18

I agree, an app which wraps around libkscan would be nice. It's nice to have an app just for scanning, when all you want to do is scan images and save them.

Re: "Kooka and kmrml are removed completely." - Aaron Seigo - 2007-06-18

then again, i'm not sure why krita wouldn't fit that bill pretty well?

Re: "Kooka and kmrml are removed completely." - Diederik van der Boor - 2007-06-18

> then again, i'm not sure why krita wouldn't fit that bill pretty well? For the same reason I don't open want to open Digicam to just copy pictures from my camera to /mnt/data-dump/pictures/ I just want to get the job done, not open a fully fledged painting application. Following your logic, KSnapshot can be removed too in favor of krita, but this doesn't make sense to me either. IMHO, it's newbie friendly to have a simple wizard with (1) scan preview > (2) select bounds, rotate > (3) scan > (4) save as, send by e-mail or post to flickr. Windows XP has a nice type of application for this, and it seams to be used a lot because it's simple.

Re: "Kooka and kmrml are removed completely." - Aaron J. Seigo - 2007-06-18

for everyone commenting about how badly this is needed, please read the whole thread. note that i first say that a little scanner shell would be cool. then i say that we have something good enough for now. put the two together and you get: it would be nice to have a little scanner shell, but we are ok for now even if we don't.

Re: "Kooka and kmrml are removed completely." - Achim Bohnet - 2007-06-19

All your required functionalities (and much more) are already available as kipi-plugins (and therefore in gwenview showimg, kphotoalbum, digikam and ksquirrelmail) As gwenview will be part of KDE4 maybe an new option gwenview --plugins scan that start the plugin on gwenview startup ,wrapped in a scan-images.desktop is all you want ;) Achim

Re: "Kooka and kmrml are removed completely." - whatever noticed - 2007-06-19

~> gwenview QGDict::hashAsciiKey: Invalid null key KCrash: Application 'gwenview' crashing... ~> gwenview libkscan: WARNING: Trying to copy a not healthy option (no name nor desc) libkscan: WARNING: Trying to copy a not healthy option (no name nor desc) KCrash: Application 'gwenview' crashing... Still needs some work i guess :o) If it is reproducable, i'll post a bug report about it

Re: "Kooka and kmrml are removed completely." - Martin Koller - 2007-06-22

For all who are not aware of it: I recently added support for scanning into kolourpaint (in KDE3 and KDE4 of it) kolourpaint is a nice, compact application which every normal user should be able to deal with.

Re: "Kooka and kmrml are removed completely." - MamiyaOtaru - 2007-06-29

It is a nice app, but it isn't a scanning app. It's a doodling app, and not the first place someone will look for to scan something, and it contains a lot of functionality unneeded by someone who wants to scan something. Don't get me wrong, I think it's nice that kolourpaint can scan, but it's hardly a replacement for a simple scanning app. For all the talk of making things easier and simpler for newbies, lumping functionality many people consider unrelated into now larger and more complex apps is precisely what one doesn't want to do.

Re: "Kooka and kmrml are removed completely." - Schalken - 2007-06-18

Well maybe you don't want to open a large and powerful graphics application just to scan a picture. I would rather open up digiKam, since it has the basic functions you're likely to do on the image before you save it, i.e. rotate, crop, fix colours, but not do complex painting. On the topic of scanning, any word on a KDE4 frontend for performing OCR? I hear tesseract-OCR is a fantastic library.

Re: "Kooka and kmrml are removed completely." - MamiyaOtaru - 2007-06-18

Wonderful. In the same way Windows users open up Photoshop to scan things. That's the first place I'd look. Luckily everyone has koffice (with krita) installed instead of OOo and Gimp.

Re: "Kooka and kmrml are removed completely." - matte - 2007-06-21

That's *****! Almost nobody uses Koffice cause it's barely compatible with ODF and not compatible at all with MS files (and most of us need to communicate even with non-linux users). Krita sadly isn't still 50% as useful as gimp. So most (90%?) people uses OOo and gimp, and will continue to. These apps are not really mature, and you know. Givin scanning functionality only to Koffice users will not force users to use koffice, most of them will just move to other scanning solution, or will to others DE if they badly need integration.

Re: "Kooka and kmrml are removed completely." - whatever noticed - 2007-06-23

>>So most (90%?) people uses OOo and gimp, and will continue to. You can also scan images with OOo and Gimp.

Re: "Kooka and kmrml are removed completely." - MamiyaOtaru - 2007-06-29

I'd heard there were still a few people around who had no concept of sarcasm. What a wonderful sighting this has been.. like visiting primitive tribes in the rainforest. Thank you for this.

Re: "Kooka and kmrml are removed completely." - MK - 2007-06-29

Text messages are not an ideal medium for transporting sarcasm and/or irony. There are two reasons why sarcasm messages can fail: the reader and the writer...

Re: "Kooka and kmrml are removed completely." - whatever noticed - 2007-06-18

>then again, i'm not sure why krita wouldn't fit that bill pretty well? Krita isn't a scanning application, and it is not part of KDE itself. Novice users that just want to scan a document will be looking for a scanning application, not for an image editor to do the job. A simplified digikam could do the job, as it has the necessary abilities to order scanned images and editing features to scale, crop and rotate images and to change the file format.

Re: "Kooka and kmrml are removed completely." - Adrian Baugh - 2007-06-18

I'd be very keen to see good scanning functionality built into digikam anyway - not all my photos are taken using a digital camera and it would be nice to be able to scan slides / negs / prints and bring them straight into my digikam workflow.

Re: "Kooka and kmrml are removed completely." - Achim Bohnet - 2007-06-19

install kipi-plugins and you'll find in digikam: Album -> import -> scan images

Re: "Kooka and kmrml are removed completely." - David Joyce - 2007-06-18

I agree with the others on this one - having a separate scanning application is immensely preferable. Kooka has served KDE very well for a number of years, and I have found it particarly useful. Inserting scanning into an application such as Krita makes a simple task rather complicated for a number of users. This seems especially to go against the grain of the Unix philosophy of providing simple utilities, and also decisions such as to separate off file management into Dolphin. Please retain Kooka!

Re: "Kooka and kmrml are removed completely." - Diederik van der Boor - 2007-06-18

> Please retain Kooka! I'd go for a alternative with much more friendly UI... (the wizard I described somewhere above). for the remaining, you've complemented the other arguments nicely.. :-)

Re: "Kooka and kmrml are removed completely." - Boudewijn - 2007-06-18

Actually, I don't use Krita to scan images myself. I haven't even tried it -- not even now that I have a scanner again. I actually had forgotten that Krita was supposed to be capable of directly scanning images in. And I'm the maintainer... But I tried Kooka and went to using XSane myself, because it does 16 bits. I'm not sure whether libkscan supports 16 (or rather 12) bits per channel at all. But it should be easy enough to write a standalone scan application using libkscan -- you can probably do it yourself, in Python or Ruby or C++. There's just one thing I'm certain of: nobody actually working on KDE4 has time to start or restart a dedicated scanning application. Kooka has been seriously unmaintained for ages. So -- if you want a scanning application, if you think it's important that there is a scanning application, then you need to act. Stop pleading. Stop hoping. Follow the instructions on techbase and start a development environment. Start developing. Become a widely-admired hero!

Re: "Kooka and kmrml are removed completely." - Aaron J. Seigo - 2007-06-18

> I'm not sure whether libkscan supports ... i'd be surprised if it doesn't as it uses sane, so should follow what xsane can do. > nobody actually working on KDE4 has time to start or restart which is exactly what i was thinking when suggesting krita is good enough for now. due to having ways to scan there's no big impending doom cloud hanging above if there isn't a little scanner shell in 4.0. > Kooka has been seriously unmaintained for ages. it would need a pretty big rethink/rewrite in any case as the UI really needs to be completely rethought. given that most of the logic (except the ocr stuff) is in libkscan, it makes the choice even more obvious. > Start developing. Become a widely-admired hero! indeed.

Re: "Kooka and kmrml are removed completely." - forrest - 2007-06-18

it would need a pretty big rethink/rewrite in any case as the UI really needs to be completely rethought. I'll second that :)

Re: "Kooka and kmrml are removed completely." - ac - 2007-06-19

I'll second that :) Could you please elaborate? What do you not like about the current user interface, and what ideas do you have to make it better? It would be great if we could collect some ideas here, so that the soon-to-be-widely-admired hero knows what to do...

Re: "Kooka and kmrml are removed completely." - whatever noticed - 2007-06-19

my main problem with the current interface is that you can close the views in the main screen, but cant get them back in the same fashion. Most novice users i work with come to me with an empty kooka screen and the only way to restore it to its default layout is by removing ~/.kde/share/config/kookarc.

Re: "Kooka and kmrml are removed completely." - Aaron Seigo - 2007-06-19

more than anything else, keep it simple. it doesn't need docks, it doesn't need galleries, it doesn't need a separate image viewer space ... simplicity. if the user wants all of those things, they can use gweview or krita. preview, crop/select, rotate and save: that's all that's needed. second, do it fast. there were a number of things kooka tried to automate or handle "smartly" that made the app a bit slow. third, don't try and manage the image results automagically. kooka tried quite bravely to keep automated galleries around. imho the scanner app should treat the scans as documents (think kate, kwrite, kword, etc) and not try and auomatically mange them. that's just mho though, and to be fair i've used kooka for years and have got a lot of utility out of it. so it's a good app. but we can probably do even better by learning from it.

Re: "Kooka and kmrml are removed completely." - MamiyaOtaru - 2007-06-29

OK, I'll happily admit this is better than whining about kooka disappearing. If a better scanning app comes out of this it's a win.

Re: "Kooka and kmrml are removed completely." - Odysseus - 2007-06-19

We've been over this ground a few times now, haven't we??? :-) >> I'm not sure whether libkscan supports >... i'd be surprised if it doesn't as it uses sane, so should follow what > xsane can do. Having trawled through libkscan in the past, I can say there's a lot of stubs in there where the author intended to support all the features in SANE, but didn't in the end. It's also very messy. I'm of the opinion that libkscan needs a full re-write for the post-Solid & Windows/Mac world that finally does support all my scanners features :-) I have some code that speaks to my scanner OK, but I'm a bit like the artilleryman in War of the Worlds... Everything else is a +1 from me. Kooka tries to do too much, we already have great image management apps. Instead its widely agreed that a beefed up libkscan in kdegraphics and a couple of new smaller apps outside libs is the way to go. John.

Re: "Kooka and kmrml are removed completely." - David Joyce - 2007-06-19

Aaron & Boudewijn, Start developing - perhaps this is an invite I can't resist. With the amount of spare time I have, it will have be a _slow_ process! I'll try and get in touch with you to see what I can do. The UI suggestions posted seem very sensible - I've always thought the gallery pane, and that sort of stuff, added undue complexity to the whole scanning process. - David ps. best leave the hero bit out, I think... :-)

Re: "Kooka and kmrml are removed completely." - Boudewijn Rempt - 2007-06-20

Sure. Feel free to contact me, either by email or on #koffice.

Caches - a.c. - 2007-06-18

I hope that KDE will at least create a cache API and make it possible to slip in caches via a quick configure. In particular, I see the icon cache and of course there is the html cache. It would be nice to skip all that, and have something like squid serve the needs. Yes, I know that icon cache is meant for local caching, but it seems that a small generic cache that interacts with squid (or other network cache) would be great for schools, departmental servers, businesses, etc. KDE can use more networking.

Re: Caches - Aaron Seigo - 2007-06-18

the point of the icon cache is to speed things up. throwing them on a machine somewhere on the network seems ... counter productive. squid helps with web browsing because it caches remote content on a system that is closer to the destination (you). integrating the icon cache with something like squid would be doing exactly the opposite, and therefore have exactly the opposite effect (e.g. slow things down). additionally, the sort of on-disk strategies used by web cache apps are not necessarily the greatest for other work loads such as icons due to differences in access patterns. so even if squid was running locally it probably wouldn't be the best idea. direct access to a shared local file that is tuned for icon access patterns is going to be hard to beat. and i'm really not sure what benefits a network cache would have. i can see sharing cache files on a system serving x clients over the network (e.g. thin client setups) could be nice for disk space and disk cache friendliness ... but that's also local (to the app) and not on the network.

rounded selction - terran - 2007-06-18

Finally dolphin has rounded selected item. I thought this features was abounded.

KDE4 porting progress - cossidhon - 2007-06-18

Danny, thanks for again delevering on my monday morning habit of reading the commit-digest. Would it be possible to somehow get statistics on de progress of the porting effort to KDE4? It would give a good feeling where we are right now.

Re: KDE4 porting progress - superstoned - 2007-06-18

well, porting is done, as is improving the libraries (mostly). They're working on features now.

Re: KDE4 porting progress - Danny Allen - 2007-06-18

Well, it would be pretty hard to get definitive statistics on the porting effort, as it is not something that is easily quantified - really, many files may be in different stages of porting, etc. And it is not as if there is some register of ported files :) I really wouldn't know where to start in getting such a statistic. However, you might be able to form an impression through the Krazy code quality checker at http://www.englishbreakfastnetwork.org/krazy/ (where a reduction in issues over time would somewhat indicate progress in porting). Danny

plasma icons - anon - 2007-06-18

Hello, will those special icon actions also be available from dolphin and konqueror ? or only on the desktop ?

Re: plasma icons - superstoned - 2007-06-18

let's hope they won't be plasma-specific ;-)

Re: plasma icons - Schalken - 2007-06-18

The quick icon actions yes I do think should be available in Dolphin under icon view. However, other parts of Plasma such as icons having the nice rounded border and the ability to move icons around should probably remain Plasma's expertise. It is useful to distinct the use of icons on the desktop (fewer large icons, move them around) from icons in the file manager (large number of icons, must reduce clutter).

Re: plasma icons - Adrian Baugh - 2007-06-18

I disagree. I think that an icon should behave exactly the same everywhere - anything else is confusing to users as they have to figure out where the different behaviours apply and why, when they drag an icon from a dolphin window onto the desktop, it begins to behave completely differently.

Re: plasma icons - Aaron J. Seigo - 2007-06-18

which is why icons on toolbars behave exactly like icons in sidebars, the file dialog and the file manager? ;) icons are context sensitive. i agree that things should generally work similarly, i also think (and have done various bits of user testing and observation to base this on) that the "desktop is just a file manager view" concept is completely and utterly broken. one of my stated goals is to break this errant connection by 4.1 so we can get on with using the desktop and panels as something that is actually useful in the general case.

KOrganizer layout - Diederik van der Boor - 2007-06-18

I like the new layout of KOrganizer a lot :-) (http://commit-digest.org/issues/2007-06-17/files/korganizer_themed_decorations.png) The "details of selected event" makes it much friendlier to use too. Not sure about the background stuff, but well I don't expect it will be mandatory to use a background. :-p

Re: KOrganizer layout - Loïc Corbasson - 2007-06-18

Well, the layout in http://commit-digest.org/issues/2007-06-17/files/korganizer_themed_decorations.png is more of a mockup. But the "details of selected event" part is available in KOrganizer 3.5 (in fact, it's a quick cut-and-paste). The only difference that may appear in KOrganizer 4 is that the position of the panel may become configurable (left or right), and the to-do view is being changed a little. Here's a screenshot of today's KOrganizer (still a work-in-progress):

Re: KOrganizer layout - Iñaki Baz - 2007-06-18

What are these not-useful pictures at the bottom of each day? Are they the "new" features? Korganizer is a pain in usability temrs, and the solution isn't adding "cool" pictures for each day. Please, use Google Calendar for a while and understand how simply to use it can be. For example: - Google Calendar: After selecting a time range INMEDIATELY does appear a ball to create the new task/event. - Korganizer: After selecting a time range you must press right buttom for context menu to appear. Hope Korganizer will be improved in real terms.

Re: KOrganizer layout - Loïc Corbasson - 2007-06-18

Hi! I'm the creator of the not-useful feature you just saw :) I'm a student working this summer (Summer of Code) to add some theming support to KOrganizer, to make it more appealing to users that think computer-based calendars are too "unhuman" and boring, so mainly home users still using paper-based calendars instead of KOrganizer and also companies which may want to customize the calendar layouts for the employees/customers/... The "cool" pictures are Wikipedia's Pictures of the Day, and while this may seem unuseful, this is commonly found on paper calendars which are very successful, so maybe it's not that unuseful after all? (You sure have noticed that the goal is not to improve usability with this feature, but attracting new use(r)s.) Now, concerning the GUI in general, I won't say KOrganizer's GUI is perfect, and I think that your example is good at showing this, but please notice two things: - my Summer of Code project is about KOrganizer theming, so I won't be able to revolutionize the GUI in terms of buttons/actions/etc.; I'll work on themes and decorations to allow customization of the calendar views; - we lack developers for KDE-PIM (KOrganizer being one of the components of the PIM suite) so of course you would be very welcome to join us make it better: just email kde-pim@kde.org if you'd like to (this would be greatly appreciated!). Changing the GUI requires time = people = new developers, and you'd be very welcome to help us on this! Now, on the usability front, I personally do not think KOrganizer is a pain, and I think it is comparable to most (ok, not all) other calendar apps out there, free or not. This of course does not mean it could not be improved, and I for sure understand that some apps' functions are easier to use. If you want to help, please feel free to do a usability study or code new ideas, this again would be very appreciated. Anyway, thanks for the feedback :) Feel free to contact me / post on my blog (http://blog.loic.corbasson.fr/) if you'd like to add something on the theming possibilities themselves -- thanks in advance! Loïc

Re: KOrganizer layout - Iñaki Baz - 2007-06-19

Ok, I understand the goal of your project. Just let me explain that when I saw these images I though there were more important things to fix about Korganizer, most of them about usability, and because I expected to see a new and cool designed Korganizer I just saw the same as now but with some pictures. Just it, I've nothing against you project, it could be cool, but I hope more improvements for a better calendar app. Anyway I'll try to compare various calendar program to test Korganizer "bugs". Regards.

Re: KOrganizer layout - Loïc Corbasson - 2007-06-20

> I've nothing against you project No problem, I didn't take it personally :) > Anyway I'll try to compare various calendar program to test Korganizer "bugs". Thanks for having a look at this -- if you need some info or anything else, feel free to post to kde-pim@kde.org. This is appreciated! Best regards, Loïc

Re: KOrganizer layout - Harald Henkel - 2007-06-19

Hi. Above those Image-of-the-day pics there are two numbers. They are supposed to be the number of days in the year before THIS day and after THIS day? Well the sum is allways 362 + THIS day would be 363, but the year 2007 has 365 days as most years. The first number includes THIS day (31+28+31+16=106 for Apr.16), while the second number is 3 days less then the remaining days of the year. Just wanted to mention it, in case you didn't already realize.

Re: KOrganizer layout - Loïc Corbasson - 2007-06-20

Hi, Thanks for the feedback! In fact, the images in the digest are mockups. I didn't notice when I created them that the numbers I added manually did not fit. But in the real KOrganizer, they do :) Thanks! Loïc

Re: KOrganizer layout - Martin Koller - 2007-06-22

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.

Plasma icons! - Schalken - 2007-06-18

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! :)

Re: Plasma icons! - Aaron Seigo - 2007-06-18

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

Re: Plasma icons! - Leo S - 2007-06-18

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.

Re: Plasma icons! - Aaron J. Seigo - 2007-06-18

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 =)

Re: Plasma icons! - Leo S - 2007-06-19

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.

Re: Plasma icons! - Aaron Seigo - 2007-06-19

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.

Re: Plasma icons! - Martin Stubenschrott - 2007-06-20

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

Screenshots? - me - 2007-06-18

"The Oxygen window decoration and widget are both moved into kdebase" Is there any screenshots or video? just to take a look Bye

Next Alpha Build? - DITC - 2007-06-18

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?

Re: Next Alpha Build? - makosol - 2007-06-18

Beta is planned for 25/06/07.

Re: Next Alpha Build? - Anonymous - 2007-06-18

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

Re: Next Alpha Build? - makosol - 2007-06-18

Where can we grab those updated live-CD ?

Re: Next Alpha Build? - Simon - 2007-06-18

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

Plasmoid packages - dario - 2007-06-18

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!"...

Re: Plasmoid packages - Emil Sedgh - 2007-06-18

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...

Re: Plasmoid packages - Diederik van der Boor - 2007-06-18

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.

Re: Plasmoid packages - dario - 2007-06-18

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?).

Re: Plasmoid packages - Aaron J. Seigo - 2007-06-18

> 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.

Re: Plasmoid packages - dario - 2007-06-18

> 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?

Re: Plasmoid packages - Aaron Seigo - 2007-06-19

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

Re: Plasmoid packages - dario - 2007-06-19

> 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...

Re: Plasmoid packages - Aaron J. Seigo - 2007-06-21

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

Re: Plasmoid packages - Jack H - 2007-06-18

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!

Re: Plasmoid packages - Aaron J. Seigo - 2007-06-18

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?)

Re: Plasmoid packages - dario - 2007-06-18

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.

Re: Plasmoid packages - Vide - 2007-06-18

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

Re: Plasmoid packages - dario - 2007-06-19

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!)

Re: Plasmoid packages - mabinogi - 2007-06-19

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.

Re: Plasmoid packages - dario - 2007-06-19

> 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.

Re: Plasmoid packages - Jack H - 2007-06-19

"...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

Filenames and Thumbnails - Emil Sedgh - 2007-06-18

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

Re: Filenames and Thumbnails - Anon - 2007-06-18

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?

Re: Filenames and Thumbnails - Emil Sedgh - 2007-06-18

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??

Re: Filenames and Thumbnails - Aaron J. Seigo - 2007-06-18

> 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.

Re: Filenames and Thumbnails - boemer - 2007-06-20

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.

Re: Filenames and Thumbnails - Aaron J. Seigo - 2007-06-21

"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!

Wow - Ted - 2007-06-18

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.

Re: Wow - m. - 2007-06-18

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"?

Re: Wow - David - 2007-06-19

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!!

Re: Wow - Joergen Ramskov - 2007-06-20

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.

Oxygen windeco and widget - Emmanuel Lepage - 2007-06-18

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?

Re: Oxygen windeco and widget - Anonymous - 2007-06-18

Just open a Konsole and enter kcmshell style And don't forget to post screenshots ;-)

Re: Oxygen windeco and widget - Emmanuel Leoage - 2007-06-19

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)

Re: Oxygen windeco and widget - Emmanuel Leoage - 2007-06-19

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

Re: Oxygen windeco and widget - Aaron Seigo - 2007-06-19

> 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.

Sonnet - Jonathan - 2007-06-19

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

Re: Sonnet - Aaron Seigo - 2007-06-19

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. =)