KDE Commit-Digest for 21st October 2007

In this week's KDE Commit-Digest: Fortune-teller and Keyboard Layout applets for Plasma, KNewsTicker resurrected for KDE 4.0 as a Plasmoid. Rewrite of <canvas> tag support in KHTML. Various new language syntax highlighting in Kate. Internal database storage work in Digikam. More playlist handling work, and support for Magnatune "streaming membership" in Amarok 2. OpenDocument loading of charts in KChart for KOffice 2. Various graphics fixes and a user handbook for the Bovo game. Kolourpaint is now fully ported to Qt4. Continued work on the Eigen 2 library. Further porting away from KDEPrint to the printing facilities provided by Qt4.

Dot Categories: 

Comments

by Christian (not verified)

How much work would it be to provide missing features to webkit as opposed to duplicating the efforts of others into khtml? Filling out bugs on bugs.kde.org is cool 'n all, but why should khtml remain when there is the more actively developed webkit? Seems like it would take more work to duplicate webkit features in khtml then to fix webkit and bring it up to the level of existing khtml's features and run with it from there. Then everyone would get the benefits.

by SadEagle (not verified)

If my memory serves me right, it'd require going through ~6000 or so different commits, figuring out how they relate, and disentangling things, which is made much harder by some pointless rearrangements Apple made. That's not practical with our manpower[1]; it will likely be much easier to get 90% of the useful things that the fork does with 10% of effort by being smart about it. After all, it's always been about doing more with less, in KHTML and all of KDE.

You see, having more manpower does not mean you're more productive, since it also means you can throw manpower at a problem, or even invent a problem to throw the manpower at (OK, so there is Google doing that for people now). I would never spend 1 hour thinking of a change and then 50 implementing it and 20 more fixing it up. I would rather spend 5 hours thinking (in chunks, like say when walking someplace or taking a shower), and then 5 implementing it. It also means we don't have much noise, commits for some abstract sense of beauty[2], etc. To give an example, note that we do work closely on the JavaScript engine, but in our own repositories. And when I merge stuff perodically, I find that some ultra-great changes, which were often discussed with us, are mixed in with tons of commits which basically do nothing.

------
[1] It might be easier to do by making the other tree run with our regression tester, but that's quite tricky, since the baselines are finicky, and that would require someone from the other end to put in the bulk of the effort.
And now, perhaps I am being silly, but I would hope some of those well-wishers claiming to be involved in KHTML development would have done some of this already. I would certainly help with some of the black magic in tr's fontoverload code.

George Staikos did something like this for JavaScript. That was a much easier case, and it worked. But it also didn't work out quite as he expected, since we still kept our own tree, and for good reason. Unfortunately, most people just talk.

Doing this sort of integration would indeed get us very close to the ideal solution; leaving some social problems --- and there may be technical solutions to the social problems.

Of course, right now they are solving the social problems by reminding us that
Apple folks are all pretty nice, just with different goals and design philosophies (even if those philosophies annoy the heck out of me sometimes, but heck, they're doing it less than some KDEers lately --- see footnote #2),
and these nice folks would never do something like publish a misleading article forcing a rectraction via a FAQ, unlike people who think they're doing you a favor.

[2] Coincidentally, one such commit in kde libraries broke some form submissions pretty badly in trunk, and many more have broken things greatly before.

by jospoortvliet (not verified)

No matter how good KHTML is, it has and will have very few users. That means webdevelopers won't test on it, so it won't be usable on many sites. WebKit, on the other hand IS tested with many sites. Joining forces with them allows KDE to take advantage of that, while it keeps the possibility of adding whatever we like. Imho, that's the way to go.

by hmmm (not verified)

Can you trust apple? History says you can't. In fact, if their market position allowed it they would be wayyyy worse than microsoft. It is in their culture not to be open.

If someday the decide that their CVS should not be accessible anymore, what of the Free/Open devs?

As a KDE user, I want KHTML to be tailored to KDE's needs, not to have webkit retrofited... In the end, it is all about having control of your creation. And I believe the KHTML developers have every right and motive to keep working on their project. And you should support them, because it is because of people like those that you get KDE, not because of big companies.

And on a philosophical note, what message does this would send: "A Free project is useful/competition? Why compete? fork it and kill the original! People will praise you for it!".

Obviously, you don't really want Free software, just free... And if possible provided by a company with a bad ego problem.

by liquidat (not verified)

"If someday the decide that their CVS should not be accessible anymore, what of the Free/Open devs?"
They would do what the rest would do: if Apple closes the CVS again and only delivers code blocks as patches the "rest", meaning Nokia, Adobe, Gnome and the KDE project, would set up a new, fully open place to continue development.

WebKit is much more these days than just Apple.

by SadEagle (not verified)

That's not so simple. Development is not a bunch of random people, it has a community and a structure. Right now, the development in Apple's fork is very much centered around their employees (and their needs), partly because the project culture is very inefficient and not well-suitable for part-time contributors. If they were to stop it, the project might not survive, since the interests of the outside contributors may not be sufficient to sustain development. And don't expect KHTML contributors to step in and take things over should that happen, since there might not be any involved, especially if this stuff is forced through the back door, over the development team's objection --- heck, the FUD designed to do that has already discouraged some of our contributors from working in our tree, never mind working in Apple's interests.

(Not that I expect Apple to close development --- they gets tons of free labor right now, w/o giving up much of control).

by Moltonel (not verified)

Indeed. Even if KDE would switch to webkit (or offer it as an option - eek), there would still be this big cultural difference which drives khtml and webkit appart, a little bit more every day. The focus and needs are not the same. In the long run, KDE would be as unhappy with webkit as Apple would be with khtml.

Technically, neither khtml nor webkit is a clear winner (AFAICS). The best we can hope for is improved cross-polinisation between the two projects (patches, testcases...).

Disclaimer : I'm not a kde/apple dev; my view is a very subjective one.

by Borker (not verified)

In the end, the ball is really in apple's court. If they start playing nice and do all the things that a good participant in an open source project should do then it would reduce the arguments against using webcore (and gain apple all the benefits of free software participation) but pretty clearly, that is not high on apple's agenda. As mentioned in the article, apple are more about closed door development followed by a flashy reveal by Jobs than they are in an open, reciprocal development process.

by Aaron J. Seigo (not verified)

... and you are involved in the webkit development process how exactly? i ask because you're making some remarks that have the ring of being informed, and yet it goes against what i've seen.

by T. J. Brumfield (not verified)

KHTML vs Webkit is far more simple in the ideal solution.

In an ideal world, open source means you take the best code and try to merge the best aspects of both. Since the fork, both projects have made innovations and improvements. Merging it isn't necessarily simple, but ideally it is the best solution.

by Iuri Fiedoruk (not verified)

I think it's really strange how some people defend khtml against webkit.
Some of them because of it being contamined by companies like apple I can understand, but other not. They say to not trash code, they say khtml have better things than webkit, but let's take a look:

KDE 4.0 is replacing kicker for a mix of a plasmoid and kickoff. At start it will have much less features than kicker.
KDE 4.0 is replacing konqueror for dolphin in file management, and most people that used it I heard says it's much better than konqueror.

I don't see a so hard defense of those two softwares as I see in khtml/webkit case. You know, khtml could still be in as optional, same as the case of konqueror as file manager.

by Dolphin-fanatic :) (not verified)

Issue 81 (2007-10-21) is not clickable in Google Reader.

"Issue 81 (2007-10-21) <- THIS SHOULD BE BLUE AND HYPERLINKED, IT ISN'T
from KDE Commit-Digest
Fortune-teller and Keyboard Layout applets for Plasma, KNewsTicker resurrected for KDE 4.0 as a Plasmoid. Rewrite of tag support in KHTML. Various new language syntax highlighting in Kate. Internal database storage work in Digikam. More playlist handling work, and support for Magnatune "streaming membership" in Amarok 2. OpenDocument loading of charts in KChart for KOffice 2. Various graphics fixes and a user handbook for the Bovo game. Kolourpaint is now fully ported to Qt4. Continued work on the Eigen 2 library. Further porting away from KDEPrint to the printing facilities provided by Qt4.Discuss at http://dot.kde.org/1193149851/ http://commit-digest.org/issues/2007-10-21/" <- THIS HREF IS ALSO WEIRD

greetings

by Tim (not verified)

Wow - at least a decision has been made. I don't know though, it seems khtml is always playing catchup. I still have to open firefox all the time for many different sites. I continue to use khtml because of my love for konqueror, but it would be nice to be on the radar of web developers for a change and not have to wait for the next version to fix [x] problem.

"Apart from dynamic scripting there is Java, Flash, cookies, URI shortcuts, password managers, security and networking support"

I can see how dynamic scripting, java and flash could be a problem, but the rest should not be a concern for an HTML viewer. If the are, then the code is not properly modularized.

That quoted paragraph makes this decision seem like an emotional rationalization. Yes, KHTML is our baby - but we need to let it go now. If it's legacy ends up having been the core of WebKit - that's not a bad legacy. Please don't make the user community suffer more html compatibility issues just for the sake of not being able to accept that your child has grown up.

by Level 1 (not verified)

In this case, its not really about modularity. Its mostly a question of: do you want to stick to internationally accepted and well defined w3c standards, or do you want to imitate internet explorer's functionality as closely as possible*? You have to be willing to answer "2" to be able to render a lot of websites "correctly."

*ick.

by SadEagle (not verified)

Add "mozilla's functionality" to #2 as well. These days using non-standard Mozilla stuff is more in style.

by Emil Sedgh (not verified)

/me __HATES__ browser compatibility issues, specialy IE problems...

hearing that mozilla is going to be like IE and include non-standard things (like -moz-foo) is so bad

by suy (not verified)

Er... AFAIK, using "-foo-new_property", where "foo" is the name of the browser or rendering engine, is not only fine, but the way recommended by the W3C for adding plattform specific properties. Do a grep for "-khtml-" in kdelibs, and be surprised. :)

Browser compatibility issues, is all browsers understanding "width" as "width of the content", and MSIE understanding "width" as "width of the content, plus the padding, plus the borders". This is completely different.

by Emil Sedgh (not verified)

i know that even -khtml-opacity was there too, but why now that w3 is recommending 'opacity', mozilla uses '-moz-opacity', ie that sucks and im even not going to talk about it...

different function and tag names is an issue too

by SadEagle (not verified)

I actually wasn't referring to that. Most -moz- properties are just prerelease CSS3 stuff (and most -khtml- ones are prelease CSS3 stuff, or for internal use), and people /usually/ do not mess this stuff up.

But take for example the gmail complaints below. For a while, gmail stopped working for us when spoofed as Firefox. Why? Because there is this non-standard thing MSIE invented as innerHTML, which everyone emulates. We implemented it as close to IE as possible, but... Mozilla decided to generalize it. And the gmail relied on it. In this case, the difference was trivial, but in all honesty, if MS was doing it, people would be crying "embrace and extend".

A better examples are those things like HTMLDocumentElement.prototype. I had people asking me why we were lacking this "DOM" feature. Well, it's because it's not part of any DOM spec, and just happens to be the way Firefox worked.
AKA nearly the exact equivalent of window["[[HTMLDocumentElement.prototype]]"] in KHTML, just less well-hidden. Of course, because people started using it, now everyone has to implement it -- Opera, Safari, us. Accidental? Fair enough. Extra work for us for non-spec'd behavior either way.

Mozilla folks also feel like they own the JS language. Which, given how ES4 seems to follow the JS2.0 inanity, may be they do. But, well, they added the getter/setter feature that's not part of ECMA 262-3 spec, and guess what?
Other browsers have to implement that.

P.S. Extra bonus (bogus?) points go to whoever named non-standard events like DOMContentLoaded.

by Simon (not verified)

It is unfortunate that a lot of developers seem to think that works in gecko == standards compliant. Nowadays I tend to test in Konqueror first of all.

Having said that, I would like to see something like DOMContentLoaded in the standards and in KHTML

by Stefan (not verified)

ACK for the first point. What works in Konqueror seems to work in all other browsers (except IE, of course; but these are mostly CSS issues). Perhaps I should rethink implementing AJAX features in my web application. Because thinks are working so good at the moment without JavaScript.

by B (not verified)

Konqueror really needs webkit to be taken seriously at all.

by SadEagle (not verified)

You'll continue to have to open firefox, unless you file bug reports.

by Dima (not verified)

Well, I have to open Firefox for wellsfargo.com, since Konqueror almost freezes there. I filed a bug two and a half months ago:
https://bugs.kde.org/show_bug.cgi?id=148528

No activity there at all.

by SadEagle (not verified)

Well played, well played. Will try to take a look during the weekend.

by Peter Thompson (not verified)

BTW, am I the only one unable to use Konqueror correctly with EBay? Neither can I upload pictures nor properly use the popup menus in "My Ebay" (they pop up as blank white rectangles without text).

This is so for quite some releases, I think there was even a bug report. I was just wondering as EBay isn't the most unusal site on the internet.

by Ed (not verified)

Mine show up as gray blank boxes. Actually I can see them for a split second before they go blank.

by Dima (not verified)

So posting bug URLs in forums actually works :)

Anyway, I realized that KDE 3.5.8 improved things (as I commented in the bug), so it's usable now.

by AC (not verified)

My support goes to the KHTML developers and I agree with their point of view.

If there's some issue with compatibility maybe adding an option to switch the rendering engine to WebKit (or even Gecko - what happened to Kecko?) could be made.

by Reply (not verified)

Ok,

So, some people think KDE should go with WebKit (which might be part of a future Qt 4 release) while others think KDE should develop KHTML. (I'm pretty sure where this is going: KDE will support both, and pass the choice on to users).

However, I have to ask: is it smart to release KHTML as part of kdelibs-4.0.tar.bz2?

Even *IF* WebKit turns out to be the prefered solution KDE will still have to support KHTML with security updates until the end of the 4.0 cycle. It just doesn't seem smart to commit to that at this point. (remember, this is an HTML rendering library. There are security issues there that are going to have to be fixed).

Maybe by 4.2 KHTML is viewed as the clear winner; in that case, it could be added to kdelibs. Until that happens, I think it's in KDE's and KHTML's best interest to have KHTML live in its own package and be a dependency of KDE 4.0.

by SadEagle (not verified)

KHTML is a library which many applications rely on to operate.

by Tim (not verified)

Could you expand on this. Do packages really rely on khtml or do they rely on the registered html viewer.

by SadEagle (not verified)

They rely on the DOM APIs.

by Reply (not verified)

Thats exactly the point, should they depend on khtml (which is going to fall further and further behind) or should they just go for the QtWebkit stuff which provides all the same functionality and more. Plus actually is a well known player on the market.

by Moltonel (not verified)

I don't see your point, having khtml inside kdelibs or in its own tarball doesn't make any difference maintenance-wise. Actually, separating the libs would needlessly put more burden on packagers.

by jospoortvliet (not verified)

Nah, for 4.0, the decision is clear: KHTML stays where it is. It is not practical otherwise. We can reconsider for 4.1 and further (and we might do that).

by Reply (not verified)

Well, I'm already aware of that. Which is why I made the post.

To you and Moltonel:

Having KHTML inside the kdelibs-4.0 tarball means you have to support it through all KDE 4 releases, which is a guarantee KDE can't possibly make as far as I can see. You can't guarantee there will still be enough people intersted to give it the maintainence it requires.

If it moves to its own package that's not a problem: KDE only guarantees API and ABI stability for kdelibs.

by niko (not verified)

Many Web Developers test their pages in several Browsers: IE6, IE7, Firefox and Safari. Some on Opera. But not too many have a linux machine just for testing in Konqueror.
And: they don't get payed to make things work in konqueror!

Almost all simple pages work without any problem - but some of those ajax pages do not. (gmail is a perfect example)

If Konqueror would use WebKit (and identify as WebKit - so those browser-sniffers get something they know) many problems would be solved.

niko

PS: I'm a Web-Developer using Konqueror the whole day :D

by Juhani Lyly (not verified)

my Konqueror works very well on (to, in, with?) gmail

by Timoth (not verified)

I can identify with that. I'm also a web developer and the decision from our management is to support IE6, IE7, Firefox and Safari. My development environment is Gentoo + KDE + Zend Studio and my favorite browser (by far) is Konqueror.

I make every effort to test and make things work in Konqueror but when we have tight deadlines and rushing to complete, I cannot afford the time to debug and figure out what's wrong (IE gives me enough problems on that front). Once it works in the required list of browsers, it's done.

In the end, I cannot deny there are days I wish Konqueror was using webkit because it could solve many problems for me (sorry, I'm being selfish here :/), and we could add Konqueror as a supported browser with little (none?) testing overheads for us.

Tim.

by Grósz Dániel (not verified)

Konqueror should display valid HTML pages perfectly (as much as possible) and web developers should create valid HTML pages. So KDE should choose from KHTML and WebKit which more properly supports standards.

by Juhani Lyly (not verified)

Konqueror works well in (?) gmail

by Patcito (not verified)

it looks like the site has been bought by someone else http://www.khtml.info/

by Andreas (not verified)

that site was never very well maintained anyway

by christoph (not verified)

Thanks for the weekly digest!

I am missing the statistics section (e.g. number of bugs opened and closed), is there any other way to get that information?

by Darryl Wheatley (not verified)

Okay, I haven't been able to put KDE 4 on my machine yet because others need it for production use, but I have some ideas that would be great to see implemented:

1) A different default color scheme for the Oxygen window decoration. Gray is certainly professional, but a light sky-blue could look even better, especially if it had a nice soft gradient.

2) While it's a great idea to see the Plasma Applet Browser pop up when that wrench icon in the corner of Plasma is clicked, perhaps it could expand into a hybrid of "Desktop Properties" (e.g. to change wallpapers etc.) and Ubuntu's new "Appearance Preferences" applet (http://cybernetnews.com/wp-content/uploads/2007/09/ubuntu-7.10-compiz-fu...), with options to have "no", "minimal" and "maximum" 3D compositing effects. "Applets Browser" could be one tab of several in that dialog, all to do with appearance settings. I guess some people might worry this would bloat the dialog and could duplicate a similar one in System Settings, but the redesign of Konsole's options dialog proved that a well-organised settings dialog can have excellent usability despite a multitude of options, and need not have a spartan interface with very few.

3) Looking at recent screenshots of Dolphin, I have no idea whether the actions panel available in the D3lphin version (e.g. Compress here etc. like at http://cybernetnews.com/wp-content/uploads/2007/10/dolphin-network.jpg) has gone to in the KDE 4 version. Is it simply hidden by default?

I mean all the above comments/questions as an innocent noob, and hope no-one becomes offended by anything contained above. I'm really impressed with the way KDE 4 is going - it;s exciting to see all the pieces come into place! Keep it up everyone!

by Alan Ramm (not verified)

Another thing, with the grippy things, can they be turned off like in The OS That Must Not Be Named? Perhaps the grippy things could be made to only appear when you hover over a toolbar that can be moved?

by Hans (not verified)

I suppose you mean the grippy things in toolbars; yes they can be hidden by locking the toolbar (like you lock the Kicker).

by Alan Ramm (not verified)

I see. Thanks very much! :)

by Aaron J. Seigo (not verified)

> when that wrench icon in the corner of Plasma is clicked,

mouse over, not clicked. i'm trying to get rid of clicking as much as possible (though no more than is possible =)

> expand into a hybrid of "Desktop Properties"

it will provide access to various bits of configuration UI, yes. that's the whole point of it =)

> "Applets Browser" could be one tab of several in that dialog

i'm hoping to have multiple entries that expand out of the toolbox rather than have one massive dialog full of tabs in a bit to find a maximal breadth-vs-depth arrangement.

> I have no idea whether the actions panel

the information panel is still there; AFAIK the actions are being reworked however. a generic class for them was just written up (by dfaure) and moved into libkonq recently.