In this week's KDE Commit-Digest: Plasma applets can now be dragged from the desktop to the panel. More internet data sources for the Picture Frame and Comic Plasmoids. Configuration dialogs are added to many Plasmoids. The in-development "WorldClock" Plasmoid supercedes the KWorldClock standalone application. A new Plasma applet: Conway's Game of Life. KRunner becomes completely plugin-based. Support for editing GPS track lists in Digikam. More work on expanding theming capabilities across KDE games. A variety of enhancements in KOrganizer. Initial work on a web interface to control downloads in KGet. Work on paths and snap guides in Karbon. A HTML part plugin in the scripting application creator, Kommander. Mono (C#) KDE bindings reach a usable state. Python support in KDevelop4. A return to development work on Decibel. KMail gets a new maintainer, with already-noticeable improvements. KBluetooth and KRecipes begin to be ported to KDE 4. The game Kollision moves from playground/games to kdereview. A new game, KDiamond, is imported into KDE SVN. Read the rest of the Digest here.
Comments
Danny, you rock!
Thanks (that was a quick comment!).
Of course, I planned to release the Digest earlier, but various things prevented that :)
I should probably start on the next one now :D
Danny
Thanks for this one. The digest is a good read every week.
Hi Danny,
Just by curiosity: How long does it take you to write a digest?
Grettings,
Hendric
It would be interesting to know the story behind that.
There is no big story behind this.
Ingo Klöcker, the old maintainer, doesn't have the time anymore to work much on KMail, and therefore asked me if I wanted to be the new maintainer, since I've been the person doing most of the work on the KDE4 version that time.
So there's nothing like the old maintainer conflicts back in 2002.
wonderful. thanks for stepping up.
i've tried migrating from thunderbird to kmail several times now, but every time there were some small and not-so-small nuisances that prevented me. i guess i'll try again once i start using kde4 :)
I was forced to migrate from Evolution to Kmail. I say forced because Evolution was one of the few Gnome apps that I really loved but there was a problem with storing my password in openSuse 10.1 I think it was so I switched to Kmail. I had the hell of a time getting Kmail to set up properly which was the contrast to Evolution and it had some issues with fetching and sending mails sometimes but the worst thing about it is that it's one of the slowest e-mail clients that I ever used. I still use Kmail with the hope that it will improve a lot in KDE 4. KDE PIM would be perfect if Kmail would work as good as Evolution or Thunderbird.
I agree, to an extent.
I definitely wouldn't say I "loved" Evolution due to its many bugs but the setup of new accounts was very painless.
I consider myself an intermediate level Linux user but I could not configure Kmail (on Fedora 8) to access my POP accounts without referring to the help. Even this was out of date as some of the screens had been renamed. Dejargonizing and making the configuration of POP accounts much more user friendly will certainly help Kmail adoption.
I am not advocating a "dumbing down" of the program (which I know is anathema to many KDE devs) but simply removing UNNECESSARY complexity. Both Thunderbird and Evolution have this one aspect right, so surely Kmail can be improved to surpass them.
Hi,
Can you tell if there is any plan to add the "reply to html mail" feature.
I (and others) have been waiting for years for this IMHO critical feature.
Indeed, when kmail receives an htnl formatted mail it is impossible to reply without destroying the whole formatting (a first step could be to enhance the html to text processing).
In a business environment, kmail is not a common mail client (guess what is the de facto standart...). Nearly every mail is html formatted (with colored text, bold text, itemize,...).
Using color, bold and itemize *is* useful especially when the mail is address to a group of participants that choose a different color for replying, or use bold to enhance part of a large mail.
It is rather embarrassing to reply to these mails with kmail. You end up screwing the whole thread and you get a reputation: "that stupid linux geek is not even able to answer mail correctly, why on earth does he insist on using this".
Well because, I'm used to *nix like OS, but yes I agree this problem with kmail is unfortunate. I'm pretty sure it will be addressed, at least I've seen some guy saying this a couple of years ago...
>Can you tell if there is any plan to add the "reply to html mail" feature.
Well, I don't plan adding something like this for 4.1 myself.
Not because I am against it (I know that proper HTML support is important), but simply because there are lots of other things to do and time&developers are short. For example fixing the tons of regressions the Qt4 port introduced and working on refactoring to make the Akonadi port easier.
However, maybe someone else will code it, for example Edwin, who already introduced HTML signatures recently.
Not particularly thrilled about Mono bindings... but that's okay as long as you won't start rewriting core desktop modules in C# (gnome anybody?)
> but that's okay as long as you won't start rewriting core desktop modules in C#
Unless I am much mistaken, gnome developers are not doing that and have not announced plans to do so. The only change that I am aware of is the decision to permit applications, which happen to be written in Mono (Tomboy, F-Spot) to be included in the default gnome desktop. Personally I like both applications and having read through some of the code for them I understand the decision to use the C# language. It really is considerably less painful than the combination of plain C and gtk. Contrary to popular misconceptions, Tomboy at least does not appear to use all that much of the .NET framework outside of the runtime and core IO/container classes. The GUI for example is created through C# bindings for GTK.
As far as KDE is concerned, the availability of free software implementations of high level languages gives developers an opportunity to write and publish innovative applications more quickly and with fewer technical pitfalls than they could with C++. Java / Qt Jambi might be the better choice at present since it is supported by Trolltech, although I'm sure Richard has a better informed answer to that. One key thing to note is that there is a completely open and free implementation of C# and enough of .NET. I'm not sure the same can be said of Java at the present moment in time.
http://icedtea.classpath.org
I personally don't know why people don't stop blaming Mono/C#/.NET. Is it because of the original inventor?
GET REAL PEOPLE: C# is ISO certified and patent free, the CIL is ISO certified and patent free, and so Qt, KDE and those bindings are!
There are technical and practical issues where a combination of C# and its framework or Java are superior to C++, more than ever when you forced to not use Qt. Just to mention one: Did one of you blamers ever use (N)Hibernate? I don't know another so flexible object-persistent database framework.
Regards
Erik
Well, there is Hibernate :) (and SQLAlchemy...)
just joking.
I like C# more than Java, but its main problem as I see it is that it is currently even less cross platform than Java. After that, well, that's matter of personal taste. Only that.
We're not forced to not use Qt, which is why C# doesn't have as much to offer us as it does Glib/C programmers.
That's exactly it. I really don't see a lot of point in using C# or Java over C++ when you're using Qt. Sure C#/Java benefit from some nicer syntax and better code completion/refactoring support in IDEs, but aside from that I don't see much difference.
The Qt API is better than the class libraries of those languages, and I barely have to do any memory management at all with Qt, so the garbage collector really doesn't improve things for me. Cross platform is pretty much a wash as well. C++ requires recompilation, while Java/C# need a runtime installed. Security is contentious, but I haven't seen any convincing evidence yet on that front.
I can see that if you're using C/GTK you'd jump at the chance, because C# or Java would be far easier to use, but for C++/Qt I really don't see the argument. The next step easier is a scripting language.
Yes, I pretty much agree with you here, and you are quite correct when you say "next step easier is a scripting language", such as Python or Ruby. What is the value added by using QtJambi or Qyoto instead of the C++ api?
However, from my point of view, getting C# bindings working with Qt/KDE is a very interesting technical challenge. Currently Arno Rehn is doing great stuff with that. He is making the Smoke library that is used by the Ruby/C# and PHP bindings more modular. That will make it much easier to create Smoke libraries to cover various KDE plugin apis such as Plasma or Akonadi.
The Qyoto/Qt C# api is quite a bit different from the QtJambi one, although C# and Java are quite closely related. Slot/signals are done quite differently in Qyoto compared with QtJambi, and in Qyoto Qt properties are mapped directly onto C# ones. So if you are a Free Software hacker, the differences are larger than they first appear.
The is only a GPL version of Qyoto available, whereas QtJambi is dual licensed - the target market is very different.
Qyoto/Kimono should be able to cover important KDE apis be KDE 4.1, but there is no work being done on a KDE version of QtJambi as far as I know.
It's not the point whether you are forced to use Qt, C++, C# or whatever. My point is: Qt/KDE C# bindings offer you a choice. A choice free to be taken, even to develop core modules with it. Why not develop core modules with Jambi?
Regards,
Erik
To cut yet another external dependency?
I'm not sure what a "core module" is, but I know that when I installed Kubuntu, neither Java nor Mono needed to be installed by default. Obviously, depedencies aren't a big deal on laptops and desktops, but when I get around to buying something like an Open Moko and install KDE on it, I'd rather not have Mono and Java taking up space. Also, in my experience (as a user) Java apps tend to be slower.
I think it's awesome that people can write software in Java, C#, Python, or Ruby and tap into kdelibs and Qt goodness! Ideally ANY language could be used to write an app that integrates with the KDE. But preferably, the default install of KDE should not be dependent on all those other languages. (Qt's native implementation is in C++, so naturally KDE has to include support for C++.)
It's the extra dependency, slowdown, and lack of real advantage. In GNOME, I can understand why using those languages would make sense (the syntax), but for KDE (better syntax), there is no advantage. It also slows it down, and adds another dependency (the runtime.) I don't mind making bindings to those languages (for example, lets say your a company making a cross-platform app and you only want to compile once), but the core modules should not need it.
According to http://www.ohloh.net/projects/272/analyses/latest 2% of the KDE code base are already C# but I have to admit that I have absolutely no idea how accurate that number is.
Those measurements include non-official parts as well. I've compiled the 3 base packages kdelibs, kdepimlibs, kdebase. I've never seen it compile any C#.
I was just talking to my friend a few days ago and saying, "I can't wait until they implement dragging plasmoids from the desktop to the panel."
Amazing that its done! I really can't wait for 4.1!
Download this and do it:
http://www.kde-apps.org/content/download.php?content=57117&id=3&tan=8118...
"KDE Four Live" 1.0.61 is a version with KDE 4.0.61 trunk snapshot packages,
KOffice 1.9.95.3 and some extra applications.
It has been actually backported for 4.0.2.
Right now I'm using GNOME, and I like it. Here's when I'll likely switch to KDE4:
- When the new KDE-PIM and KOffice are released.
- When I can get Auto-Scrolling turned on, especially in Konqueror.
- When Konqueror has "Undo Close Tab".
- When Konqueror saves and reopens my tabs, even if all power is suddenly cut off.
- When I can reorganize the plasmoids in the panel through drag-and-drop.
This isn't a complaint list, or a wish list, or anything else of the sort. It's a collection of anecdotal information I think someone out there might find interesting. And I do know that at least 4 of the above are either being worked on anyway, or are already ready.
I think that I'll be switching to KDE4 when 4.2 comes out. The reason is that the stuff that is planned for 4.1 probably won't all be ready on time (after all, stuff that was planned for 4.0 was put off till 4.1), and what will be shipped probably won't be feature complete or 100% polished.
I realize that if I wait till KDE4 is "ready" then I'll only be able to use the last release to ever come out. I think that 4.2 is a good personal goal for me.
I want to use only KDE4 and it's apps, and nothing else. To me the important apps are Krita, Karbon14, Amarok (never even touched it, but from what I've seen, I think I'll like it), Kaffein (never even seen it), Konqueror, KMail, and Kopete. Then in the realm of uselessly wasting time, I also like Konquest (are the AIs working finally?), and would like to use KPatience, especially if it's harder than AisleRiot and doesn't have the weird limitation of only going through the fountain 3 times.
BTW, may I mention that the KDE4 card games look terrifically awesome?
- When the new KDE-PIM and KOffice are released.
--> beeing worked on
- When I can get Auto-Scrolling turned on, especially in Konqueror.
--> possible for a long time (press Shift + up/down)
- When Konqueror has "Undo Close Tab".
--> already available since 4.0.0 ..although I've encountered some crashes :-(
- When Konqueror saves and reopens my tabs, even if all power is suddenly cut off.
--> don't know.. I too really miss this feature.. that's the reason why I still use Opera
- When I can reorganize the plasmoids in the panel through drag-and-drop.
--> beeing worked on
So you've found crashes with undo closed tabs? Please tell me about the details, send a bug report, I will fix those bugs ;-).
I've recently sent a mail about this crash to [email protected] but it was rejected :-( ... I've also tried reporting a bug about this (at bugs.kde.org) .. but I've encountered an sql error ...
I've cc'ed you the mail I've sent originally which describes the bug.
With the best regards
Bernhard
I tried KDE 4.0.1 (openSuse) yesterday. I was impressed by Konqueror. Dolphin is not as much polished as it should be: It does not recognize if your left or right pane is active (and suddenly you delete the wrong files!), I could not figure out how to use the mouse in combination with the keyboard (mouse selection does not work at all, hitting a file always opens it etc.) and a pane with "actions", not only "information" is required (at least as it is hard to get into the context menu for the current directory as now).
Regarding Plasma and Kwin, one should optimize and stabilize the code instead of implementing all KDE3 features. I was simply not able to run KDE longer than 3 hours in one session. Xorg took 100% CPU power all the time, even when doing nothing and when switching all desktop effects off.
I also do not have any clue about all the options for rendering. Using the latest NVIDIA drivers on my 8400 GT, I can turn "Vsync to blank" or "allow flipping" on in the driver settings (what does this mean at all?). In the KWin settings I am able to chose the drawing method without knowing which one is best. There seems to be no documentation available yet. (Are there any help files on KDE4 which are at least partially complete?)
Maybe I was mistaken and did some KDE4 newby mistakes, or the whole software must be regarded as alpha/beta stuff. I am really disappointed. Regressions are okay and understandable, but it is not about stability which MUST be fine on release. If you ask me, the quality management of KDE definitely did fail with 4.0
Off course that's being worked on!
One of the things that caused Plasma performance to drain were the clipping algorithms in QGraphicsView. Trolltech never expected those would be used at all, but then came plasma. Now there is a complete desktop shell using QGraphicsView clipping all the time :P That's one of the things that got greatly improved in Qt 4.4.
You also mention NVidia issues. Try turning compositing off, and see how well it performs then. After all, all painting goes through KWin/compositing. If your xorg.conf or kwin settings are bad, it will degrade performance quickly.
You can improve that though with the settings described at http://dot.kde.org/1200050369/1200126492/:
Your nvidia driver section should contain the following:
Option "AddARGBVisuals" "True"
Option "AddARGBGLXVisuals" "True"
Option "DynamicTwinView" "false"
Option "RenderAccel" "true"
Option "AllowGLXWithComposite" "true"
And the extensions section should look somewhat like:
Section "Extensions"
Option "RENDER" "true"
Option "DAMAGE" "true"
Option "Composite" "Enable"
EndSection
Good luck!
Oh and to improve the performance even more for nvidia drivers, disable the "vsync" and "direct rendering" in kwin settings -> "Desktop effects" -> "advanced options"
The xorg.conf options are not the problem on my machine. Your hint regarding the Qt bug were rather helpful, though. The thing is, that even when all effects were turned off, Xorg took 100% cpu time (even if I just sit in front of a top without user action!). So I turned off all plasma desktop applets except the clock - and now - Xorg is now at constantly 5% which is at least acceptable. The particular applets were the system monitors and cpu frequ. analyzer.
Still, I can't use dolphin. Can I probably turn on the double click somewere again? That would at least help a little. Currently it is just not consequent though through, I think. Don't get used to it and already moved files into the Nirvana...
> Still, I can't use dolphin. Can I probably turn on the
> double click somewere again?
Double click can be turned on already by going into System Settings -> Keyboard & Mouse -> Mouse. If there are still some problems: please use bugs.kde.org to inform us developers about such problems so that we can fix it. I regularly read the dot to collect user feedback, but sometimes it's really frustrating that people complain in forums about the quality of KDE and don't give feedback to the developers directly by using bugs.kde.org...
I am sorry to have left this impression. That was not on my mind. Though, I was really looking forward to the release and spent a whole day, just trying to get used to the new kind of software. A few details behaved different from what I expected.
This may be the wrong place to start a debate on bugs.kde.org, but I feel personally offended: I filed many many bug reports during the last years. They even receive some ratings by public votes. It is the minority where any KDE developer reacted at all. Some were just closed after a few years, because the feature it was referring to was removed, but not because a developer cared. By saying this, I do not want to blame the majority of developers, KDE is doing a great job, else I would not use bugs.kde.org. I just mention it, though I do not care much - KDE is not a company where I bought an expensive product. But please realize, that this is also not encouraging. So, my personal experiences with bugs.kde.org teached me to apply it only to severe bugs and wishes. Maybe this is the reason why I mentioned this here.
> This may be the wrong place to start a debate on bugs.kde.org,
> but I feel personally offended:
Sorry Sebastian, it was not my intention to offend you.
> I filed many many bug reports during the last years.
Thanks for this!
> It is the minority where any KDE developer reacted at all
I understand that this is frustrating and for sure we developers have to be more careful for responding to bug-reports.
> But please realize, that this is also not encouraging.
Yes, I agree and I'm not sure how this can be improved...
Still the tendency to write about things that don't work on forums and blogs has increased a lot during the last years. It is fully OK to write about things that don't work, but I think the balance of writing about cool things vs. writing about things that don't work has shifted a lot to the "writing about things that don't work"-camp. Please note that this is just a general statement and my personal impression, this is not directly related to your comment :-)
"but sometimes it's really frustrating that people complain in forums about the quality of KDE and don't give feedback to the developers directly by using bugs.kde.org..."
I'm working on instant messenger now and if I would count only on 'direct feedback ' for new ideas our IM would die ;)
PS. keep up the good work. I love dolphin
the system monitor plasmoid is in playground, not a production module. there's no guarantee anything in playground owrks properly or well. if your distro is packaging and installing plasma's playground code by default with kde4 they are doing you a disservice, imho.
5% is also ... bizarre though. it should be silent as a mouse (are mice really silent, though? ;)
I can only recommend these settings because they work. I don't even have a modern machine: an ASRock mainboard, 1.8 Ghz AMD Sempron processor with an nVidia GeForce 6600 LE (256 MB RAM) and I recently upgraded to 1.5 gig of memory.
I am now running KDE 4.0.1 which is quite stable and I can't complain about speed. The only problems that I am having are that my KDE 3.5x programmes crash now and then and I can't get Amarok 2 to run (keeps crashing but that's expected with pre-alpha software). Apart from that i am cool and very impressed with the speed at which bugs are being squashed and missing features are added to KDE4.
> Dolphin is not as much polished as it should be: It does not recognize
> if your left or right pane is active (and suddenly you delete
> the wrong files!)
I cannot reproduce this. Could you please submit a bug-report how to reproduce this (or mail me directly)? Thanks!
> I could not figure out how to use the mouse in combination with
> the keyboard (mouse selection does not work at all, hitting a file
> always opens it etc.)
I'd also need more details about what you mean so that we can fix this. We improved already some minor things in Dolphin for KDE 4.1 (selection area of items is optimized to the real size, selection toggle is available for the single click mode etc.), but to solve such issues we first have to be aware about that there is an issue and need feedback from users. It's OK to post things like this on the dot, but it would be more productive having a detailed issue description in bugs.kde.org ;-)
> and a pane with "actions", not only "information" is required
> (at least as it is hard to get into the context menu for the
> current directory as now).
Why is it hard getting a context menu for the current directory? If it is because of the small viewport area: this has been fixed for KDE 4.1.
Most of the issues are probably regarded to the viewport. But two things are not:
(1) Is there a way to select a single way be using the mouse?
(2) When using the keyboard (tab key) to switch panes (I used this after failing using the mouse) I found it 1st a little sad that I had to enter "tab" several times and that the tab key got caught by the QTExtEdit in the information panel. Second, if activating the left pane by using the tab key, the rectangle around the left pane becomes blue. But all actions on the toolbar and in the menu still refer to the other pane.
> (1) Is there a way to select a single way be using the mouse?
Do you mean selecting files in the single-click mode? There is a solution for this in Dolphin for KDE 4.1: a kind of "selection toggle" is blended in "plasma-like" above the item. If you don't have meant this: clicking the mouse on the viewport selects the active view in the split-view mode.
Regarding the tab issue: I was not aware about this and have added this point to my TODO-list.
I am fully satisfied, thanks :)
Something that's bugging me with dolphin in 4.1 is when selecting a group of files and pressing down ctrl to select another group of files, the first group gets deselected ...i can workaround this by selecting only one file holding ctrl and then using the rubberband selection again :)
This is a Qt-issue. I have not verified yet whether it still happens with Qt4.4, but will check it...
Ok, and yes, i'm using Qt 4.4 0214 :)
I've noticed this problem in kubuntu+kde4.0