In this week's KDE Commit-Digest: Taskbar and KMenu functionality from KDE 3.5 returns to the Plasma panel, and work on clocks in Plasma, with the move of the binary-clock Plasmoid to kdereview. Improvements in annotation handling in Okular (which has been officially capitalised). Essential support for viewing bug contents in the rewrite of KBugBuster. More data export options (CSV, HTML, etc) in Kalzium. The CVS implementation in KDevelop moves to the Model/View framework. The start of JavaScript functionality in Kst plugins. Usability refinements in Konsole. Mailody begins to be ported to the Akonadi service. A "mirror search" plugin for KGet. IPv6 work in KTorrent. Colour docker improvements across KOffice. Optimisations in KDevelop and NEPOMUK. Various work in KJS and KHTML. Support for the MPRIS multimedia player interaction specification in Dragon Player, with Dragon Player moving from playground/multimedia into kdemultimedia for KDE 4.1. The Kopete Bonjour protocol moves to kdereview. The copy of Qt within KDE SVN is updated to be GPL version 3 compatible. Read the rest of the Digest here.
Comments
It's fantastic to read news already talking about KDE 4.1. Gotta love it.
My only question, is that in a few of these digests I read that certain things just missed the 4.0 cut, and are being shelved for 4.1
If these things just missed the cut, couldn't they be released with 4.0.1 or 4.0.2?
Not impatient, just curious. (Fragments good. Sentences bad.)
Hi
No usually, because x.y.z releases are in feature freeze i think.
but in some special cases, some features get into the releases.For example there are some plans to add Customization options to Plasma in 4.0.1 or some features are going to be added in 3.5.9.but they shouldnt break the string freeze (no change in strings).
If there's something in particular you'd like backported, you can always try contacting your friendly distribution packager(s). :-) I can't speak for the other distributions, but here in Fedora, we'll evaluate such requests on a case by case basis.
is there any plan to reactive the IRC plugin for Kopete?
or porting konversation?
im just runing Kopete from KDE 3.Amarok pre-2 'plays' music, KMail is almost usable and stable (but its not using Akonadi, right?)
KDE 4 is becoming more and more usable...
Everybody raise his hand that still
a) has an icq account
b) has friends that also have an icq account, but have no jabber account.
If the amount of hands is low; thats the reason why nobody has stepped up to fix the ICQ plugin :)
*rises hand*
The parent post was talking about IRC, not ICQ.
and just before anyone starts worrying about the state of icq: I was using icq with kopete's kde4 code back in *2006*, when having a chat window open without crashing was a big thing. ;)
The ICQ-plugin probably receives the most attention at the moment - Roman Jarosz is simply amazing. His work will be one of my main reasons to switch to KDE4 once it's ready for my needs.
By the way, don't judge a protocol's popularity by the popularity in your own country... It varies a lot. From my experience here in southern Germany, nearly everybody uses ICQ, a few lost souls are still on MSN or AIM, and almost nobody uses Yahoo or (alas!) Jabber.
He was talking about IRC, anyway it's recent news that AOL recently started an experiment integrating AIM/ICQ in Jabber (so you can login with your AIM account using the XMPP protocol)
well personally i use IRC with xchat these days
but when i was on windows, i was using icq a lot
i still hope something like licq, but maybe smaller, or "embeddable", can show up ... i want a tiny tiny tray icon without any popups on default
/me raises hand
> or porting konversation?
Konversation will definitely be ported. The usual mix of real life distractions have put us a bit behind our desired schedule on this one, but it's coming.
Good News! Thanks in advance.
I'd like to see an IRC plugin for kopete more than konversation. However, current IRC implementations in all IM clients seem to suck. They need to (in order of importance)
* stay logged in to channels without opening windows, as if THEY were the account, and the server connection was just a meta-connection.
* show history from a channel when you open it to chat, just like popping up konversation would, if it had been logged in to a channel.
* auto-identify with nickservs
* be able to ignore specific messages from the server, and bots, so there aren't endless annoying new messages when just logging in.
I don't think there's anything else I'd need actually. With those few things, I could forget that IRC is "special" and use it like any other IM account.
I remember reading in the developer blogs that there's some new IRC client for Qt4. I can't remember it's name, but someone mentioned that since Konversation wasn't ported it would be a good "excuse" to try this new one. (It had the unique feature of keeping the IRC connection open even when you closed all the windows, or something like that.) I simply cannot remember it's name. Anyway, since IRC is an essential means of communicating among developers, I'm sure some sweet IRC solutions will be available for KDE 4.1, whether it's Konversation, Kopete, or something else.
And I suggest the guy who replied about ICQ get some sleep, or a new pair of glasses, lol. :-)
This new IRC client is Quassel, developed by a friend of mine:
http://quassel-irc.org/
This one looks really nice, at least until konversation is ported. Thanks! :)
This is something I really miss in Kopete-kde4 ...
"The post-KDE 4.0 commit surge continues this week, with 3043 commits. (...) . There is a real buzz to KDE development right now, an extra edge to what is already a vibrant atmosphere, and it is evident everywhere, from IRC to SVN."
This proves the naysayers (especially the idiotic OSNews.com crew) wrong who complain that the 4.0 release should have been delayed. If 4.0 wasn't released like this, the commit surge wouldn't have happened.
Wrong, it's the opposite. It's proof for a truth behind the critics.
You can't prove the opposite.
The reality is: 4.0 released => development activity increases.
This is a benefit for the project overall.
Your claim is just pure speculation.
Correlation does not imply causation.
Your claim is also pure speculation.
His claim is indeed also speculation, but it is a fact that the amount of commits has increased after 4.0 for WHATEVER reason.
And this is good insofar as most commits IMPROVE a situation.
Right and Wrong.
Yes, after KDE 4.0 release a ton of commits went to subversion tree.
But the reason isn't only because 4.0 brought more developers or made people write faster. Don't forget there was a API/ABI freeze and much of newer feature where developed in branchs or even in the author machine without any commit.
It's kind of natural to see a surge of commits after a freeze is dropped :)
I think they correctly delayed from what would have been a disastrous October release to a promising (if frustrating) January release.
And how many of those commits are to TRUNK and how many are to the 4.0 BRANCH?
This seems to prove nothing except that, as usual, there is more interest in doing new features than in fixing bugs. For example, since the release was tagged ( 758631) there have been more than twice as many Plasma commits to TRUNK as to the 4.0 BRANCH.
IMHO, the critics (which are NOT naysayers but, rather, realists) are correct that KDE-4 wasn't ready for the 4.0.0 release. The release proves it. The desktop lacks significant functions and there are many serious bugs (e.g. 154595).
Now I hope that these bugs are promptly fixed but I fear that KDE will return to the seriously defective development model where bugs reported in the current release BRANCH are considered to be fixed if they work in TRUNK. Bugs in the release BRANCH need to be fixed in the BRANCH. The reason for this should be obvious, but it is also advantageous because the BRANCH is more stable and the bug can be properly fixed. Note that if the current code base is going to last for years, that bugs need to be properly fixed, not just hacked.
"We have already been deriving Pluto from the KSAsteroid class for practical reasons. With this change, Pluto is now labeled an "asteroid" in the details dialog."
But Pluto is not an asteroid, is a dwarf planet: http://en.wikipedia.org/wiki/Dwarf_planet
For me Pluto stays a true planet
I thought Pluto was the Dog Star.
Spaceballs ftw! :-D
We Love Pluto!!!!! =)
I thought it was a kuiper belt object.
But as far as I'm concerned there is no standard definition of a planet at the moment, which is pretty silly.
There is a standard definition of a planet:
(1) A planet is a celestial body that (a) is in orbit around the Sun, (b) has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape, and (c) has cleared the neighbourhood around its orbit.
(2) A dwarf planet is a celestial body that (a) is in orbit around the Sun, (b) has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape, (c) has not cleared the neighbourhood around its orbit, and (d) is not a satellite.
(3) All other objects orbiting the Sun shall be referred to collectively as Small Solar System Bodies.
More info: http://www.answers.com/planet&r=67
While I prefer feedback through bugs.kde.org or on our mailing list, you're absolutely right about this. I'll fix it soon...
Ok, thanks! Next time I'll use the proper method to notify bugs.
FYI, fixed in trunk (can't backport due to new string, "Dwarf planet"):
http://websvn.kde.org/?view=rev&revision=767475
A great read as usual. Thanks Danny!
So, is Akondi working in 4.0.x now, or is it going to be in 4.1? I seem to remember it and PIM being scheduled for 4.1.
Also, I love all these backends. It should be great for developers and users alike.
Thats planned for 4.1
4.0 has no pim
I imagined that having a contact/pim backend would be crucial to making good use of nepomuk.
Uhm. Over the years people developed a plethora of KDE-based media players (KPlayer, KMPlayer, Kaffeine, Noatun, and soon even Amarok will have video support), but in KDE 4.1 the "official" video player (as it's the only one on kdemultimedia, everything else is in extragear or elsewhere) is going to be a ultra-basic thing that (I quote from the homepage) "has not yet made a stable release, but it is getting there"...? What a curious decision :/
(Note: this is not a flame. I just think is curious, there's probably a technical reason for this but I can't see it and I'd like that somebody would tell me).
Dragon Player is actually the KDE 4 incarnation of a player that existed in the KDE 3 days as well, namely Codeine, written by one of the Amarok developers. Dragon Player is the KDE 4 rewrite, designed to use Phonon from the outset.
I like none of the players you mention, except KMPlayer for playing in Konqi. Codeine/Dragonplayer rules them all in terms of just playing movies.
+1
another +1
+1
moreover, the default KDE multimedia player should be straight, simple, quick to load, and Dragon Player has everything
+1
Absolutely. I have no need for any of the features in the other video players. Codeine/Dragon Player does what I need it to do without getting in the way. Once in a blue moon I fire up VLC for a stubborn video file that xine has issues with or to get at the slow motion feature.