In this week's KDE Commit-Digest: The start of the Google Summer of Code with 47 KDE projects. Initial version of a kxsldbg plugin for Quanta. Kross-based scripting in KDevelop. Tabs return to the kdevplatform (KDevelop, etc) interface framework. A database plugin for Kommander, with Kommander widgets becoming accessible within Designer. Support for file attachment and sound annotations in Okular. Work on support for JavaScript runners, and an enhanced visual appearance for KRunner in Plasma. Desktop search returns to KRunner. An improved implementation of "Send Input to All" in Konsole. "Close buttons on the right side of tabs" in kdelibs. A search KIOSlave for virtual search folders across KDE. Get Hot New Stuff support for KDE splash themes and chat window styles in Kopete. A "wobbly windows" effect and non-linear timelines in KWin. The start of a WMI (Windows Management Instrumentation) backend for Solid. Rewrite of connection management in Konversation. Work on playlist modes and tooltips in Amarok 2. A media player plugin to play audio and video files in KTorrent. Initial work on charting/graphing and spreadsheets for Kexi reports. Work starts on a Kexi Web Forms Daemon. Initial imports of KLesson, SuperPong, and a KDE 4 version of KNetworkManager. KBreakout and KSirk move from playground/games to kdereview. KSanePlugin moves from playground/graphics to kdereview. printer-applet moves from kdereview to kdebase. Okteta moves from kdereview to kdeutils. Read the rest of the Digest here.
Comments
Good job, as always.
Danny already knows that he's my hero, but I'll respond here anyway just so that the rest of the world knows that he's my hero :)
Good digest, as always, Mr. Allen.
Thanks a lot for another great Digest!
Thanks Dany!
Thanks for this really big one diggest. Even if I currently follow the trunk, it's nice to read what's actually new :)
Thanks, Danny. Right in time for the weekend. :-)
Made my friday! The week feels incomplete without those...
and thanks to Danny too :)
Good job danny...
openwengo *is* multi-protocol though it is now known as Qutecom.
once we see 4.1 released will there be any new chat thingies added to kopete, sorry, don't know the word. I was using gaim or what ever they call it when kopete wouldn't work on KDE 4, and they have a large amount that kopete doesn't have, like myspace, xfire, etc. And also will we get yahoo msn compatibility?
Thanks :) I can't wait for the final release as someone who came from windows and has a lot of friends on it, I think 4.1 will be the tool I can use to convince more people over to linux
Chat protocols is the term you are looking for, I believe. :)
Instant messaging protocols.
Didn't AOL/AIM go Jabber?
I would really, really love if all the major players switched to one format. Back in the day, email was a series of separate networks without one standard.
I don't care of MSN, Yahoo, etc. want to keep having their own clients with additional features for 5D chibi-avatars, but I should be able to find anyone on any network via their email or username, and converse with them on one standard for sending basic messages.
I believe that is exactly what Telepathy is meant for - sharing protocol support between clients like Kopete and Pidgin.
I have to agree that Kopete could definitely benefit from supporting more protocols. Unfortunately, I'm stuck using Pidgin right now only because it supports MySpaceIM.
Awesome to hear about the KDE4 port of KNetworkManager. It's pretty much the last KDE3 app that I depend on all the time. Konversation is the other..
Thanks for the digest Danny!
About Knetworkmanager
i have seen in the feature list that somebody work on a networkmanager plasmoid
an other people on a network-manager backend for solid.
What is the difference with this 3 apps.
Is the idea to have an api provided by solid, usable by knetworkmanager or either the plasmoid (does not will make a lot of "bricks") ?
Or something else ?
Thanks !!
Hi
yeah, i think its like:
KNetworkManager
/
/
NetworkManager <---> Solid
\
\
Network Manager Plasmoid
oh! it ignored all whitespaces...
sorry for messing up.
Solid is the hardware abstraction layer for KDE and is meant to ease the development of cross-plattform KDE application (together with other KDE frameworks like Phonon and, of course, Qt).
It is planned that Solid will get a NetworkManager Backend which will handle all networking functions transparently so developers won't have to work with NetworkManager directly anymore but can rely on Solid to do it via different backends on different platforms.
My uneducated guess about KNetworkMangager:
It will work directly on top of NetworkManager. KNetworkManager is developed by openSUSE guys and since they'll release openSUSE 11.0 with a heavily modified KDE 4.0 they aren't able to use (and develop against) Solid as long as the backend is not in place.
About the plasmoid:
The plasmoid *might* make use of Solid as both backend and plasmoid will probably be released with KDE 4.1 but I truely don't. One of the developers would have to comment on this.
Don't want to flame here but I really don't understand Novell and Opensuse folk here... why Danny Kukawa (knetworkmanager maintainer, hal developer) simply ignores Solid? KNM, as a KDE4 app, should only rely on Solid, and if something is missing in Solid to make this possible, development should be driven towards this goal. As far as I can tell reading Danny's blog, KDE news etc etc, this is not happening right now. Am I wrong? (I hope I am)
Maybe it's just an issue of time... They might get this into solid for KDE 4.1 or 4.2?
"why Danny Kukawa (knetworkmanager maintainer, hal developer) simply ignores Solid?"
I don't think he is. It's probably just a case of Solid being in a working state where KNM can use that instead of NM directly.
that has been answered. Solid is not at a point where OpenSUSE can use it for their upcoming release
So why OpenSuse doesn't put some of its employees working on Solid? (well, they could have started months ago, actually). IMO, Solid is something distro should just fall in love with, cause it can make system management integration much simpler.
I agree, but seriously since Novell took over there was even more coding support for Novell-specific stuff. Fragmenting a community even more.
With KDE this would be so much better, because KDE is distro-agnostic - if it works on KDE, it will work on distros (with a little bit of tweaking sometimes)
comments?
http://www.linuxjournal.com/article/10065
I'm glad Amarok won of course, and by a lot. :)
Though I'm not sure why we were in competition against Audacity...
I think it's surprising that even given that Ubuntu is the most popular, and widely more advertised than Kubuntu, KDE still got just a couple less votes than Gnome. Clearly a lot of people are making the concious choice to use KDE.
Good for digikam to be highly used. It's a great app. Surprising that picasa got so many votes. Perhaps that included the web site as well as the app.
The fact that vi won the text editor category really shows that the users filling this survey out have nothing in common with the average non-technical user. Same with tar as a backup utility. Seriously?? I'm a developer and pretty geeky, but I can't be bothered to learn those tools when much easier GUI tools exist.
In the package management category, things like rpm are mixed with synaptic even though they're not even remotely the same thing.
I have seen references around to Canonical own numbers, indicating that over 30% of Ubuntu users run KDE.
Hi
i think Gnome's usage is increased because KDE3 is not developed actively and meanwhile Gnome just got new features and polishes.
give some time to KDE 4, maybe about 2-3 years and you see how KDE will get more and more attention and users (just on Linux, not Win/OS X).
btw it looks like that (recently) Gnome is not getting new features and stuff in releases.look at the changelogs...very minor stuff are in announcement and there is nothing exciting added in these 6-months periods, except bugfixes.
vi blows, greasy newbies love to tell me how they use it and it somehow increases their productivity... yadda yadda..
means nothing. All it is, is their readers voting. I don't know anyone that reads that website or even knew it existed.
It's more of a magazine then a website. :)
It is nice to see constant improvements to KHTML: this one is especially good -
"Preloading of network resources via a side-tokenizer."
Konq very often "hangs" on big pages waiting for some element to load. Thanks to that is should be much quicker. I hope this is recursive and will skip not only first but second, third, ... to get them later. On most sites when those scripts are just icing on the cake and can get all necessary info when it still tries download missing bites (that is, browsing on Windows with IE or FF).
Indeed. Page loading does feel somewhat faster in recent builds which is much appreciated. Thanks KHTML hackers :)
I also notice that. Thanks KHTML devs!
And much more stable, except for the flash plugin.
I'm happy to come back to Konqueror from QtBrowser.
(is it worth bothering to post this?)
Using an older version of flash may help. Complaining to Adobe may also help (as to why you're complaining, see Seli's blog, apparently their newest linux version works only in gecko, can you say "browser lock-in"?). With a slightly older version you should be fine unless you're on trunk. Flash 9.0.119 works for me on 4.0 svn branch. So I suspect it would work fine in 4.0.1-4.0.3.
Typing about:plugins in your urlbar will tell you what version you have.
For reporting bugs, please specify if it's repeatable (those are the interesting ones, I'm told), and be detailed in what you did to cause it. There's a lot of duplicate flash bug reports. Feel free to join bugsquad and test various pathological flash websites if you are bored. Be patient, developers know about it.
And remember, you can always kill nspluginviewer.
4.1 is now in feature freeze, right? So does that mean it's been branched, and new stuff going in (such as KNetworkManager) are for 4.2?
It's in soft feature freeze. Only features that were announced before can be added now. No, it won't be branched before the release, because then too few would work on polishing the code.
And standalone stuff like KNetworkManager can easily be released independant of KDE releases, thats what extragear are for afterall.
IIUC, then we use a broken development method because if we used a correct method the developers wouldn't follow it.
Correct method: 4.1 should have been branched pre-Alpha. Then it should be determined which features would be included in the release. Any features (and other changes) not ready for the release -- that wouldn't be completed before the release -- would be removed from the branch then 4.1 Alpha 1 would be released.
Note that with a correct development model that there are never any feature freezes on TRUNK (there is no need for them); instead of a feature freeze, a new branch is tagged. As the branch is developed towards release there will be freezes on the branch, but not a feature freeze because features would not be added after the first Alpha is released.
I have to say that I don't offer any solution if developers will only work on TRUNK. All I can say is the obvious: that this simply will not work. Developers must work on the branch. If they won't do this, then it is hopeless.
And why do you think your method (or probably some textbook's method) is more correct than the KDE developers do now? After all, they've been working like this for many years and it never has posed any serious problems that I know of.
The problem is that KDE releases never reach a high level of stability because new stuff is added that does not reach a high level of stability before the release.
IIUC, this standard method would avoid that problem, which is probably why it is a text book method.
There are other methods that also achieve this such as having a stable branch and an unstable branch. New stuff is always added to the unstable branch and then copied to the stable branch when it is sufficiently stable.
Any method that avoids including new and unstable code in what is supposed to be a stable release will work. Experience has shown that the current KDE method doesn't avoid that. Releases include code that isn't ready for prime time yet and the result has been that KDE does not become more stable with each release.
you realy have to stop spreading fud....
there is no standard "textbook" way of doing softwaredevelopment. and in the days of dvcses your proposal is long deprecated. if kde wants to use more branching, every new feature should get its own branch, which are merged back to trunk when the new code is stable.
though svn isn't meant to be used like that, so heavily using branches in the main repository is actually no option for kde today.
having more than one main-branch like you propose is a maintenence nightmare for big projects...
but thats not the point. kde already does what you want. its called the feature freeze, and like its name suggests, it doesn't allow new features in the repository when a new release is stabilizing.
It is not my intent to spread FUD. I am asking for higher quality. Or, stating that higher stability in releases is needed.
You are correct that there is NOT one standard textbook method of doing software development (one dead Straw Man) -- there are many. However, there objectives which they must meet.
I do not see that the idea is long deprecated since other OSS projects use other models which I believe are better.
Next Straw Man. I made no suggestion about using many multiple branches. That is something which you brought up.
I am suggesting EITHER earlier branching for release branches or (not my first choice) having a stable and an unstable release branch. Such an extra branch might actually make thing easier. Do you have a citation that would support your unsupported statement (is this just your opinion) that having another branch would be "a maintenence [sic] nightmare for big projects". Quite the opposite is, in general, true.
Small projects can use most any development method. It is large projects that need something more structured. The KDE project has grown and it now needs more structured methods. The proof of this is what I stated: lack of stability and regressions along with new features that were in releases before they were ready for prime time.
You seem to have missed what I said about a "feature freeze". I said that pre-alpha branching can replace a feature freeze. Obviously, I don't think that the feature freeze accomplishes what I think is necessary or I wouldn't have suggested that change was needed. Some of the new features added to KDE 3.x.y didn't stabilize enough before they were released.
So, your argument reduces to 'no you are wrong'. Do you have any suggestions? Or, are you just going to use rhetoric and logical fallacies to defend the status quo?
How do we know whether something is stable or not. It is tested. Why is it tested? It is released. The challenge is to devise some means of broad testing of software. So far the best answer is to release it.
And pray tell, who is going to merge the unstable to the stable branches? That hurdle alone dooms the idea.
Free software isn't a product. It's a process. Methods that work (some of the time) in well funded turnkey solutions usually end up harming free projects.
Why do I say that? Write 10 rules, enforce them vigorously, and see how many developers you have after a year.
Derek
It is axiomatic that stable releases should not contain unstable code.
I believe that I have made two suggestions about how software can be released for testing without releasing a 'stable' release that isn't.
So, the Linux Kernel project is doomed? I think not. Who merges new features? Obviously, the person that wrote them and wants them included in the release.
Free software may be a process, but ultimately, it must deliver a product. If it doesn't ever deliver a stable product, then it is only entertainment for the developers.
NO! I would never try to rigidly impose rules. Commercial software companies have already found out that this is a bad idea. Having a good process and maintaining standards are different.
We have rules in the KDE project. Some of them are even written. I was told that I couldn't fix KView to conform to the KDE GUI standards because it would violate the rules to do so. But, most of our rules are unwritten. They seem to be enforced vigorously and we do loose developers because of them. Then we have the unwritten OSS rules that don't seem to be enforced and need to be.