KDE Commit-Digest for 21st September 2008

In this week's KDE Commit-Digest: Various work across Plasma, including improved applet handles with monochrome icons, work on the Weather Plasmoid and the start of an extender-based notification applet. Continued development in PowerDevil, including support for suspend. Long-standing "slow deletion of many files" bug is finally fixed. A System Settings module for choosing the default file manager. Basic implementation of red eye reduction in Gwenview. A generator for G3/G4 fax documents in Okular. Support for filter plugins in Kst. More work on code completion in KDevelop 4. Start of a D-Bus interface in Lokalize. First working implementation of KMenuEdit global shortcuts. Work on supporting different resources in the Akonadi OpenSync plugin. The return of Ark context-menu actions. Liechtenstein, Oman, and San-Marino maps in KGeography. Previews of slide transition effects in KPresenter now happen directly on the affected slide. A KFormula widget is extracted from KOffice and moved into kdelibs for use in other KDE applications. Work on porting Keep, a backup utility, to KDE 4. NEPOMUK query libraries move from kdereview to kdebase/workspace, with the search KIO slave moving into kdereview. A KDE 4 port of KnowIt, a note taking application, is imported into KDE SVN. Eigen 2.0 Beta 1 is tagged for release. Read the rest of the Digest here.

Dot Categories: 

Comments

by T. J. Brumfield (not verified)

Firefox 3 runs considerably faster than Konqueror on my box. For one, it doesn't take ages to start.

It uses quite a bit of memory by default, but I turn off the page caching features and disable all that memory usage.

There are KDE 4 themes for Firefox 3, but frankly I'm more concerned with the file dialog. There is a QT branch of Firefox 3 being developed which will take care of that.

by Luca Beltrame (not verified)

A Firefox built with Qt will improve the integration slightly. When using Konqueror I also have access to ioslaves and friends. I doubt that will happen with Firefox.
Oh, and I started using Konqueror when I got fed up with the slugginess of Firefox on my Eee 900 (especially temporary freezes with high SSD access after loading a page). Konqui is noticeably faster there.
Considering I only needed Adblock (easily fixed), making the switch was rather easy.

by Michael "Konque... (not verified)

On my install, Konqueror always started faster than Firefox.... Do you have any Gtk+ applications starting on login?

by T. J. Brumfield (not verified)

Firefox is usually the only GTK app on my box.

If you don't mind using the KDE 3 file requester, Firefox works quite well with KGTK's LD_PRELOAD runtime patching.

by Michael "Maybe ... (not verified)

Correct me if I'm wrong, but I'm pretty sure that the version on KDE-Apps.org is based on KDE4. I know I have a version on my disk that is.

Well it actually has both a KDE3 and KDE4 version.

Does other KDE4 apps take so long to start as well? Because there could be a problem with your scim installation (It caused such delays in my Ubuntu box as well, removing scim and now almost every KDE4 app starts in ~1sec

Do other KDE4 apps take so long to start as well? Because there could be a problem with your scim installation (It caused such delays in my Ubuntu box as well, removing scim and now almost every KDE4 app starts in ~1sec

by Dread Knight (not verified)

I did the switch myself to the ugly looking Firefox long time ago. Konqueror is a joke because of KHTML. People need to stop making tests showing KHTML is so uber great and fast, because that's all bogus. And are you serious about filing bugs that are so damn obvious that anyone encounters in the first 10 seconds? KHTML it's really deprecated, don't see the point of duplicated effort rather than just going with Webkit asap. I know this sounds pretty harsh, but it's how many of us KDE4 users see things. But i can only brag about it since I'm an artist, not a coder.

I don't see the need to bitch on KHTML if you want to use WebKit instead. If you like WebKit, just use that. If you can't, build your own webkit based browser or plugin for Konqueror, of pay someone else to do it for you. I'm not bitching on you if I don't like your artistic designs either, I'll just not use and ignore them.

So what is your solution? Konqueror is the worst browser. Both Opera and Firefox are better.

This is a fact. Pages render incorrectly in Konqueror since a long time and the fixes are a joke so far.

I dont care much because I am using 99% Firefox. But if you compare konqueror to things like k3b ktorrent konsole then konqueror really is a bad example for SUCH a critical mission. (Cuz k3b ktorrent konsole yakuake etc... all rock, while konqueror does NOT)

"So what is your solution?"

"If you can't, build your own webkit based browser or plugin for Konqueror, of pay someone else to do it for you"

by Michael "Konque... (not verified)

Funny. It was recently (with the addition of contentEditable) that one of my most used web applications (GMail) became usable for me again (sending mail). I guess it's just a matter of what pages you use.

It might also be diminishing because of more complex web pages, perhaps?

by Anon Coward (not verified)

"I guess it's just a matter of what pages you use."

Yeah, you're obviously right ;). However, I don't want to make the pages I visit dependant on the browser I use. Nowadays most pages on the net can be rendered well enough with IE, Firefox, Opera and Safari, and I don't have to switch browsers when using one of those. With Konqui in its current stage, I have to do that.

The fact that popular sites are not rendered in an usable way, and the fact that this status might change (not only, as it would be good, for the better, but often enough for the worse) with every new Konqi release makes the web experience shaky.

With the importance the web has nowadays, a reliable browser is for me an abolute must. Konqueror sadly enough isn't reliable :(.

by Michael "I don'... (not verified)

I agree that more work should be put into making KHTML render everyday pages and have noticed some pages getting broken. I'm saying that not _all_ changes are for the worse in terms of rendering everyday pages. Right now, most of KDE is in flux (plasma is being improved at an astonishing rate, most applications are getting spit polished, old applications are being ported, etc). KHTML is no exception, and due to it's fragile nature some pages will break.

I know I am really harping on this bug report thing, but this is the case where it definitely matters --- we strive to make things improve every single day, so while regressions happen (despite a giant testsuite), them happening is not in any sense the "expected" behavior, and quick accurate feedback on things can definitely lead to improvement... And if it's done by people running branch or trunk, it may mean that the regression never sees a tagged release. Also, please don't assume developers use the same websites you do. I see people mentioning digg --- well, I don't use digg, so I won't know when problems show up on it.
Now, it sounds like I may want to start using that just for testing, but there is no way I can do this for every single website people like; and things that need accounts are in particular hard to keep track of (especially for a scatterbrain like me, who can't keep track of his TODO list half the time)

> Now, it sounds like I may want to start using that just for testing,

No, please don't do that... seing digg.com really takes a huge toll on one'faith in humanity.

Besides I just noticed I fixed the bug some days ago as a side effect of another fix.

(in my repository)

"No, please don't do that... seing digg.com really takes a huge toll on one'faith in humanity."

Well, he's already reading the comments on dot.kde.org.

Arguably the fact that comments on digg don't work could be seen as doing me a favour ;)

but it still is a bug.

by Sebastian Sauer (not verified)

> many of the rendering problems are even gone
> when using the experimental WebKit-part

So, why you don't use the experimental WebKit-part then (switch the view and/or assign that part as fileextension for *.html)? Be free to choose what matches best to you :)

by Anon Coward (not verified)

Because WebKitPart renders better, but has numerous some flaws. It's very beta, you know?

by MamiyaOtaru (not verified)

But I thought the answer was to start using webkit :( Now you're saying it will take time and effort to get it running smoothly? Now what do we do?

Are you sure that rendering errors are really errors? May be web pages uses hacks and tricks that are not completely standard or are tested against other browsers (FF, IE, Safari, etc).

That is probably 95% the case. And, if you are a KDE fan and make site/blogs/whatever, check that it works and looks good with KHTML. I've made all my sites do this. From a web dev point of view, KHTML and Gecko render and respond much more similar that IE. So I don't know if it's 100% a KHTML issue. I'd say it's more of a market share issue. Not many devs test for KHTML. It's also a javascripting issue. Lots of the things that "Don't work" are javascript related - menus and the like. Perhaps promoting Konqi and decent platform may help.

by Stefan Majewsky (not verified)

I'm using KHTML to test my webpages, because its implementation is very near to the standard. My pages are valid XHTML 1.0 Strict, and render flawlessly in KHTML. And when it works in KHTML, I do not have to test it in FF and Opera, because I know they work.

The only thing I'm using FF for in webdesign is to check layouts with Firebug.

by Anon Coward (not verified)

And that's the answer you always get when reporting those Konquror rendering errors :(((.

But I repeat: IE, Firefox, Safari, Opera, i.e. 99,x % of the web browsers used today, DO NOT HAVE THESE PROBLEMS. I repeat, any other browser - free and non-free alike - on the market does not have these problema.

The argument that the rendering errors are because of faulty web pages is valid. But considering that we are living und www surfing in the real world the statement that the rendering of KHTML won't get more tolerant but the web devs should rather change their pages is slightly arrogant and completely unrealistic.

Statements like this are which are really putting me even more off. As any problem of KHTML is attributed to faulty web pages, I as a user get the impression that there is simply no interest in fixing this problems.

However, as a user I'm interested in surfing the web and not in being part of a holy (but pointless) crusade concerning web standards.

Your last sentence tells everything. I'm interested on stantards, because I think is the best way to surf the web.

And remember, how can a KHTML dev fix a problem on a web if the web developer uses no standard hacks? Making KHTML behaviour like an other web browser? I don't think that's the way.

May be switching to webkit, because wevdelepers have webkit on mind when they make their webs.

It doesn't work even right on kde-look. The selection to not show wallpapers doesn't even work in konqueror

Thanks for bringing this up. I have a fix in my tree, but it needs some further testing. Though, again, there are better channels than the dot for these sorts of reports. Even if we developers miss incoming reports (that unfortunately does happen), the folks who help us with bug triage usually don't, and, well, bugzilla has very long memory. Plus, at least I read my bug e-mail every day, and I don't read the dot anywhere near that often.

The thing is i don't understand the bug reports of kde, i'm used to launchpad. But i will try it again. Thxs for the fix

by MamiyaOtaru (not verified)

thanks ubuntu

Your whole posting tells everything and your attitude maybe is symptomatic for the problems KHTML is facing in the real world currently :-/

1. It's pretty easy to blame every KHTML problem on the web developpers not implenting standards. I personally can't check this, somethimes it simply sounds like the standard excuse.

2. Reality check! That's what I can only advise to people like you. What's the use if KHTML is standard compliant as hell but can't render real world web pages?

3. WWW-standard conformity is, thanks to Firefox's success and new alternative browsers, nowadays important to web developpers. The time of IE's monopoly are almost over. So the remaining problems are simply a question of KHTML being tolerant of sloppy implementations of standards. And face it, as long as there are humans developping for the web, there will be smaller errors and sloppy implementations of WWW standards. So the ability of a rendering engine to deal with the unavoidable is important!!!!!!!!!!!

Yup...

In konq I often get the rendering error ladybug in the corner. It could be that other browsers don't report bugs hence I don't notice anything, but often I do see slight differences in page rendering compared to other engines (which don't really bother me).

So I ask is it khtml being intolerant? khtml bug? web site too buggy? or all the previous?

All of the above, actually. Often times websites have coding errors that show errors on every browser, just our indicator is a lot more visible. Sometimes it can be the website doing too much UA sniffing and serving us crap. And yes, it can be (and often is) a KHTML or a KJS bug (or functionality); in fact there is a KJS bug I have a fix pending for right now which throws an error on a commonly used statistics tracking package.

Actually the worst problems are sites using browser detection(broken), they tend to send Konqueror pages looking quite different than what IE/Firefox/Safari get. And from what I have observed more often than not, those pages are broken too(It would not render correctly in any browser).

As long as some webdevelopers decide to send crap to Konqueror, the improvments it's developers make will have little impact on the percived result. It's even easily seen, wsimply set Konqueror to identify as a different browser on those sites, and in the majority of cases you DO NOT HAVE THESE PROBLEMS.

by Michael "That's... (not verified)

Run mail.google.com/mail?ui=1 with FF UA if you don't believe it.

> And that's the answer you always get when reporting those Konquror rendering
> errors :(((.

I call bullshit on that. Virtually the only time you get this response is in case of UA sniffing.

by Derek Kite (not verified)

Are you using trunk, or a release?

Trunk is quite good right now, if I remember correctly, around release time it was not so good. Awful in fact.

The non clickable links seems to have been fixed a little while ago. I haven't seen the cookie issue for a while, and only when I had a mismatched kdelibs/kdebase. Flash is much more stable, doesn't crash and loads much more reliably.

KDE4 is a work in progress, and each week things get a bit better. Until it all breaks again.

Derek

Flash - ah yes. Flash + Firefox = memory hog and crashings. Flash + Konqi = no problem.

by T. J. Brumfield (not verified)

Last I saw, Flash wasn't working in Konqi at all.

And, therefore, no memory problem ;)

Yeah, the nsplugin thingy crashes everytime with flash content on 4.1.1

by Luca Beltrame (not verified)

I haven't seen this issue with either OpenSUSE 11.0 (w/KDE4.1.1) or Kubuntu w/KDE 4.1. I can view Flash just fine.

Are you using the GtkQt style thingie or such?

It's working right now. I'm not using a release.

There were issues in the recent past.

The problem here is a closed source buggy thing that everyone wants to use. Not khtml.

Derek

by Anon Coward (not verified)

I'm using the 4.1 version supplied by openSUSE (the regularly updated "Factory" development version). Are you talking about 4.2 prerelease versions? These would be available in openSUSE, too....maybe I'll give it a try.

I try to use konq as much as possible, but on sites like digg konq just fails (try reading the comments).

web interfaces like my router's config page and the uTorrent webUI fail to even log in. Also flash (non free) is much more buggy under konq than it is under firefox.

I really dislike having to open firefox for every other page I visit and the fact that it uses the hideous gtk file dialogs (or its crappy inbuilt one), or that when using gtk-qt4 it still looks out of place (and causes weird page rendering errors). Sometimes I just give up and use firefox for the whole session

I just can't wait for Qt 4.5 so that then we can have a more compatible webkit kpart. I just don't think that as hard as the khtml guys work it will never reach full parity with webkit gecko etc. which have far more resources put into them (more devs, more money, more sponsors and more visibility).

but on sites like digg konq just fails

This one should be one of the most visible bugs, as the community diggs (and is encourage to digg) stories about kde related matters. Yet we cant use kde s own browser for digging.
A lot of things are coming along nicely in kde4, fmpov konq has the longest way to go.
Words of encouragement: some of the disappointment that can be noted concerning Konq4 s performance displays how valuable konq has been so far for the ppl missing it s full functionality atm.