In this week's KDE Commit-Digest: General improvements in Kickoff, KRunner, and assorted Plasma applets. Integration of Marble into Digikam for geolocation of photos. Configuration of fullscreen mode in Gwenview. KHTML fully passes "selector" test. An automation GUI for KLinkStatus. A database connection plugin for the Kommander scripting framework. Tutorials and examples added to Step, which moves from kdereview to kdeedu. More maps for KGeography. Various enhancements in the new KBlocks game, which moves to from playground/games to kdereview. Get Hot New Stuff becomes functional in the now-feature-complete KDiamond game. Various work in Kate. Improved file tagging mechanics in Dolphin. Improvements in context menu sharing between Konqueror and Dolphin. Beginnings of a Windows/WMI backend for Solid. Work to integrate PcmIO into Phonon. Improved hyperlink creation support in composition across KDE-PIM. Work on user data/statistics migration issues between Amarok 1.x and the upcoming version 2.0. Group policies in KTorrent. The Glimpse scanning application is renamed "Skanlite". Redesigns and refactoring in NEPOMUK. Okteta moves to kdereview. Read the rest of the Digest here.
Comments
Yeah, that's not clear from the digest. Presumably though, it's a way to supply a buffer of sound to read/write to the soundcard, instead of just asking it to play a file etc. Slightly more low-level, or possibly very low-level. I remember the Phonon guys saying that it WOULDN'T support the kind of very low-level stuff that, say, pro audio apps need, though.
please any further explanations ?
This could help:
http://en.wikipedia.org/wiki/Windows_Management_Instrumentation
"Integration of Marble into Digikam for geolocation" - awesome! I've been waiting for this :-)
Huge thanks for the digest Danny; I don't usually post here but I am pleased to see it every time.
Impressive, like usual !!! Thanks a lot, Danny. It's always a pleasure to read the digest
In the last days, I've been using the Qt 4.4 demo browser, which is WebKit based, and I really liked it.
In Debian it is very easy to install, all you have to do is install the qt4-demos packages and execute /usr/lib/qt4/demos/browser/browser
This browser has a really fast startup and also it's HTML engine is fast also.
Unfortunatelly for me Konqueror 4.0.x and 4.0.68 never worked properlly in my setup, so I can't compare directlly, but QtBrowser interface it's really simple and very easy to use, although it's very Safari inspired.
This browser has it's limitations, it doesn't support plugins, so no Flash, etc., but all the others things that it's supposed on a modern browser are there, except password management.
Gmail and Google apps are working really fine, the only site which doesn't work for me it's netvibes.com.
I'm starting to like better the combination of Dolphin and QtBrowser+KDE integration (plugins, kwallet, kget) than Konqueror in it's actual state.
Don't get me wrong I'm always have been a huge Konqueror fan, but it's user interface hasn't really touched in years and in some ways it feels too complex.
But let's see what hapens, Konqueror has a faithful userbase and I can see it still appearing in future releases, even with it's actual incarnation.
Although that I can understand that for some users Dolphin can be a regression, my perception it's that it is really a leap forward and I hope that a new web browser or a renewed Konqueror can do the same in the KDE web browser arena.
Agreed 100%.
Sorry khtml devs, but webkit is the future. I don't know why khtml developers see this as bad, webkit is basically the enterprise version of khtml and plataform independent.
Also, I like dolphin more than konqueror as file manager, it is just plain, simple and good.
I was referreing more about on it's user interface than on it's HTML engine.
Although combining file management and web browsing in Konqueror has some valuable advantages, in it's current form it creates more confusion and complexity which are reflected in it's user interface.
Disclaimer: I'm not a KHTML developer
I think KHTML devs never see Webkit in KDE as bad, but they still want to develop their very own rendering engine, what's wrong with that? Having alternatives is always good, moreover you can't force people what to do in their free time.
I support Webkit in KDE, but disposing KHTML now is just a plain stupid idea comes from people who does not know how open source works. I'm sorry, but seems you do not really understand how open source works. Saying: dump this because we have better alternative maybe will work in proprietary world. (I also hate when people say that KOffice is a waste of effort because we already have OpenOffice.org)
As long as KHTML still have developers behind them and still have users, it will *not* die. If finally KDE project has decided to ditch KHTML but the developers still exist, KHTML can be continued outside KDE.
Well, yes and no.
You see, a lot of users did not wanted the dying of kicker, but it happened for better (at least we hope so). :)
But yes, I'm not saying khtml must die now, but webkit is the future, soon or later it will be one of the dominant engines.
Look at maemo, qt, safari, iPhone, android and you see a bright future for it.
"You see, a lot of users did not wanted the dying of kicker, but it happened for better (at least we hope so). :)"
I'm sure you're well intentioned and aren't doing this in bad faith, but why, *every* time you post about Plasma, you take shots at it?
He is a well known strong supporter of old good kicker and Webkit. He doesn't really like plasma (KDE 4.0.x version of plasma to be more precise) and really likes to discredit KHTML ;)
Yes and no :)
Plasma 4.0 = trash, crash, poor, less than alfa-quality.
Plasma 4.1+ = gold, awesome, impressive, shiny.
I was not being sarcastic, I've already asked forgiveness to Aaron Seigo (and can ask how many time it is needed, he can ask me to do so as many times he wish, I don't mind), because I think his *vision* of plasma as substitute to the old desktop is right and plasmoids development will be more easy than creating a cake.
The problem is that plasma is far from ready now, and I won't even talk about way back when 4.0 was released.
The main idea of plasma was having a stable base where developers could create widgets without changes in the code each new kde version and that plasma updates could be distributed indepentent of KDE release cycles. I've asked Aaron, and he said this will happen on 4.1 and afterwards.
So, long history short: After KDE 4.1 plasma is the king, if they had released kde 4.0 as kde4-developer-edition I would have nothing to complain.
I just have strong opinions, as Aaron does.
Our last struggle was about removing those crappy mini-icons on plasmoids. He did not liked my (and other opinions) and we kind of crashed, but that does not mean I don't respect and admire him, I just won't help get his ego bigger because a big ego leads to bad decisions ;)
Well, kicker died because all the developers have agreed that it must die, and porting all those kicker applets would be just waste of time. In the case of KHTML, none of KDE developers say KHTML shall die ;)
Well, we just see, whether KHTML will die as what you wish or it will still strive as an alternative rendering engine. With the introduction of KHTML in Windows, I'm sure KHTML will get more market share.
(And safari in Windows is not as good as Safari on Mac, I prefer Firefox over Safari in Windows, and if Konqueror has been stabilize on Windows, surely I'll use Konqueror)
Alternative is good, do you know even there are more smaller open source rendering engines which have smaller market share - even maybe less than 0.001% market share? Like Netsurf for RiscOS, which is quite capable despite it is still very young and ultra-lightweightness.
> I support Webkit in KDE, but disposing KHTML now is just a plain stupid idea comes from people who does not know how open source works. I'm sorry, but seems you do not really understand how open source works. Saying: dump this because we have better alternative maybe will work in proprietary world. (I also hate when people say that KOffice is a waste of effort because we already have OpenOffice.org)
This is complete nonsense. There's nothing wrong or anti-open-source about dropping a branch when a fork is a better option. It's exactly what happened with GCC/EGCS. Do you think that the GCC developers don't know how open source works?
Nonsense, they are not the same. For the case of EGCS, the FSF themselves who officially announced that they officially terminated old branch of GCC and made EGCS the new GCC. For KHTML vs WebKit case, the (current) KHTML devs still do not want to drop KHTML until several issues have been addressed. Note that they are not opposed in this idea, they just want some issues to be addressed first. So in this case, there is no agreement yet.
And even in the case of KDE really wants to kick KHTML from official KDE (KDE 5 maybe?), everybody is free to maintain KHTML outside KDE.
Really, nothing wrong with dropping a branch or a fork, but you cannot force your opinion to some people who are willing to maintain it. And why the heck we need to drop a stable and actively developed rendering engine?
> For the case of EGCS, the FSF themselves who officially announced that they officially terminated old branch of GCC and made EGCS the new GCC. For KHTML vs WebKit case, the (current) KHTML devs still do not want to drop KHTML until several issues have been addressed. Note that they are not opposed in this idea, they just want some issues to be addressed first.
So why are you accusing luri of not understanding how open source works when he says that "webkit is the future"? He didn't demand that they drop it immediately or anything like that.
> And even in the case of KDE really wants to kick KHTML from official KDE (KDE 5 maybe?), everybody is free to maintain KHTML outside KDE.
Yes, just like anybody is free to maintain the old pre-EGCS GCC. What's your point?
> Really, nothing wrong with dropping a branch or a fork, but you cannot force your opinion to some people who are willing to maintain it.
Who is trying to force anything?
And if there's nothing wrong with dropping a branch, then why are you saying that doing so is anti-open source?
> And why the heck we need to drop a stable and actively developed rendering engine?
Josep already posted some good reasons why.
By definition, you can't drop something that isn't actively developed, so using the fact that it is actively developed as a reason to not drop something is circular logic.
> He didn't demand that they drop it immediately or anything like that.
He sure implies they might as well.
> Josep already posted some good reasons why.
He didn't post good reasons. He posted poor reasons, and he didn't even bother trying the most recent version of Konqueror to compare. Instead he implies it is so buggy he couldn't even get it to work. It works just fine for me, so if he's having problems, he should be filing bugs.
> By definition, you can't drop something that isn't actively developed, so using the fact that it is actively developed as a reason to not drop something is circular logic.
I'd like to point out that khtml is still under active development. Look at the changelogs for the 4.0.x releases. It's also pretty stable: in all the time I've played with 4, I've only crashed Konq once, and once I reported it, it was fixed within the day.
> > He didn't demand that they drop it immediately or anything like that.
> He sure implies they might as well.
No, he didn't. Saying something "is the future" is *explicitly* making a statement not about the present, but the future.
> > Josep already posted some good reasons why.
> He didn't post good reasons.
Fast startup, fast rendering, really simple, very easy to use... they sound like decent reasons to me.
> he didn't even bother trying the most recent version of Konqueror to compare.
Would that be the version of Konqueror tied to the version of KDE that end-users have been told *time and time again* to stay away from because it isn't finished yet? Are you surprised that people are actually taking this advice?
> if he's having problems, he should be filing bugs.
No, if he's having problems, then that justifies his preference for another browser. You can't blame users for choosing a more stable competitor instead of helping you track down bugs.
> I'd like to point out that khtml is still under active development.
I wasn't saying otherwise. I was pointing out that isn't a reason not to drop it.
disagree 100%
I remember a few years ago the exact same comments being made about khtml with regard to gecko. If the khtml developers had just said 'gecko is the future' would there even be a webkit today?
so I for one am glad developers continue to provide alternatives and don't take the easy way out and just say 'why bother there is already program XYZ that does that?'
dr.
khtml developers didn't go for gecko because it was too messy to make it work with KDE although they tried to integrate it so they could get rid of KHTML. Now that webkit is there, most KHTML original developers have switched to it because it is more supported than khtml and easy to integrate in KDE.
They switched because they are paid to work on webkit.
You're assuming that khtml developers are actually opposed to to webcore. It ends up being a lot more complicated than that, and it doesn't help that they don't tend to say much, preferring instead to code.
But I think you'd want a proper solution where we don't lose KDE features, such as the kwallet integration, spell checking in form widgets, and our public DOM api (without which applications such as Kopete cannot function).
Developers want to be able to make new releases, with features and bugfixes at the same time as the rest of KDE, and not wait for Apple to make a release first, then wait 6 - 9 months for Trolltech to release a new version of QtWebKit based on Apple's latest version (and then you wait longer for a KDE release that uses it).
While we're at it, QtWebkit is a port of Apple's WebKit. It isn't bug-for-bug compatible. Webkit doesn't come with any graphics or networking or rendering code, all of that is written in the port. Currently QtWebKit implements only a subset of Safari's features. So you lose various features that currently exist in khtml.
If you change the user agent, you too can make konqueror work with gmail. That is what QtBrowser is currently doing; it lies and says it is Safari. If we did this for all websites by default, then nobody would know that anyone was using Konqueror. It wouldn't show up in their webserver statistics. Which is better? To work with sites that assume there is no browser other than Firefox or perhaps Explorer? Or to prove that we exist?
Disclaimer: I'm not a khtml developer, but I'm also not telling lies. And if I am, I'm sure the actual developers will correct me.
+1.
... no, make it +100000000000000
Thank you for this post. I am so tired of hearing that webkit is a panacea. It's controlled by an outside entity, and to get to KDE has to go through another outside entity. There will be lead time for each new version.
There will be issues integrating it into KDE. Anyone who thinks webkit can just be dropped into Qt, much less KDE should read this: http://zecke.blogspot.com/2008/01/joys-of-debugging-webkit.html
I don't link to that to somehow try to prove that webkit in KDE won't work, it's just to show that there are issues getting webkit to work on any platform where it isn't native (pretty much anything but OSX). It's a lot of work getting it working in Qt, never mind KDE.
And yeah, in so many cases it seems like people want the browser string. Thing is, those people don't need a new rendering engine to get the browser string they want. I wish they'd just change it in their copy of Konqueror and stop agitating for webkit. If webkit proves to be superior (including how easy it is to get working and current in KDE) then it will happen, with or without boosterism on the dot.
"like Dolphin better"
That's fine, but I don't appreciate calls to remove Konqueror's file browsing functionality as long as Dolphin's dirtree sidepanel isn't up to snuff. Running the latest Dolphin now I see I can now copy and paste and stuff using the dirtree (yay) but it still doesn't show the root directory, and there's no way to change the dirtree's root. Konqueror's much maligned vertical tabs provide a way to switch between / as dirtree root and ~ as dirtree root.
I can live without that of course, but not showing the current root at all still irks me greatly. Combine that with edit mode (instead of navigate) in the address bar and lack of an 'up' button (which people wanted removed from konqueror for years for some reason) and there's no easy way to get to the dirtree's root.
It's coming along nicely though, a lot of stuff I had to complain about regarding Dolphin's dirtree implementation are no longer applicable, as I saw when I installed it from debian experimental. So that's nice.
At any rate, I quite like Nautilus' dirtree. Showing multiple roots (/, ~, /mnt/X, /mnt/Y, etc) at once is quite nice. Something like that would be grand for Dolphin.
At any rate, the changes I'm seeing are making me feel a lot better about KDE4.
Aaand I see I can add the up button back. yay. Would still love to see the root in the dirtree, but hey. That's what I get for using edit mode instead of the breadcrumb :-/
I was using KDE4 (4.0.3) on Ubuntu, but recently came back to KDE3 because Plasma was sooooooooo instable I could not live with it.
Simply put, as a desktop 4.0 is not there yet (by far) but I have big hopes for 4.1. On the other side, KDE4 apps in general are really great, so in the end I'm running a mix of KDE3 and KDE4, here goes my impressions:
- kopete: really bad bugs (can't use google talk with transports without crashing), but some neat improvements
- krdc: this app in KDE3 was really not good, in 4 it went into a overhalt and now it's almost better than windows remote desktop client (it still wins some points because of unit drivers and clipboard integration)
- dolphin: the one in kde4 have more options, seems faster and more responsive than the kde3 version
- gwenview: too unstable yet, crashes more often than the kde3 version, both need some bug-hunting, I'll try to help where I can next time it crashes on me
- general-style: even that I use the same style in both kde 3 and 4, the last one seems to be nicer and uses less spacing. But if you have a small screen/resolution avoid oxygen. I recommend Polyester.
- fonts: in both cases to get the look I like, it's better to download microsoft core fonts and user verdana-9 everywhere.
- kcontrol/systemsettings: systerm settings is really great, but most of kcmshell modules where designed to fit kde3 overall look (like the left-side tabs/buttons). I think they could be changed in on extra level in the systemsettings, but overall a great improvement over kcontrol.
- konqueror: I still like webkit most (not only because I think is technaly better, but because it's more used and have big-players support), but khtml improvements are really nice and visible. But nspluginviewer crashes all times, so youtube is a no-go for me.
So if you are avoiding KDE4 because it's unstable, my suggestion is to run it's apps inside kde3 or gnome to have a glimpse of the improvements that where made into out favorite apps.
This is off-topic, but could a site admin. please delete the massive amount of spam in the KDE forums? The forums have been literally drowning in spam for several weeks now! It's not the impression KDE should give to new users or those seeking assistance.
Thanks.
agree, the forums really are not worth using at present, but then again, they were never that active anyway, so perhaps they are just letting the forums die. It's a shame because as the KDE user base grows with a release to windows, there will be many people looking for support that they can't get at a distro forum
Is it bad that help requests for spam deleting were the first I've heard of a KDE board? :S
Haha yeah me too. I had no idea there were any KDE forums, and I read all the KDE related news pretty much every day.
i already posted in the last commit about the invasion of spammers but no result, even i sent a message to Seb, ' i think he thought my email is a spam
It's a mystery why the Forum isn't linked directly from the Dot.
It's linked from http://www.kde.org/
There was a dot story on it way back when the forums re-launched, but they never got much attention.
The forums never grew very large -- they're built and run outside the "normal" KDE community and developer attention to forums is very low. I'm one of the forum admins, which means I look at it every six months or so -- there's just not much incentive for me.
What the forum could really use is an injection of (a) energetic forum moderators (b) some clueful people to help out in all those threads.
Not sure if it was you, but a big thanks to whoever cleaned the forums!
I agree the forums are slow and underutilized at present. Part of the problem is the partial redundancy in function between posts on the dot and the KDE forums. The whole point of the forum is to share and comment on KDE ideas or news. The dot subverts this purpose to a certain extent by allowing unregistered people to post directly to the story. This is not to say the dot causes the slow forum, but it does contribute to it.
We (KDE) could mitigate this problem by changing the way users post to the dot. Imagine if you wanted to comment on a dot story that you'd have to go to the forums and use your registered account. Each dot article could easily have a link with something like "discuss this article in the KDE forums." A lot of devs, users, and potential users follow and comment on the dot and there is no reason to think they'd stop posting just because they'd have to go to a forum. That alone would increase traffic and it might encourage devs/users to wander around while they're in the forum. It'd also cut down on the morons who post unsupported, inflammatory comments about the KDE project.