let me start by stating what should be obvious, but which if i fail to note will result in a lot of unwanted email in my inbox: a KDE port/integration of the Mozilla suite, especially Firefox and gecko, is useful and important. go Zack and Lars!
however, this effort does not reduce the usefulness of khtml (the KDE html rendering suite) to KDE. khtml is a bridge to other projects, a way to stress test the rest of our libraries, is a source of interest for several KDE hackers and is lighter on resources that gecko making it more appropriate as a component for apps that need to show some html but whose primary purpose on this planet is not to be a web browser. but these are not the most important reasons for khtml continuing to exist and be maintained.
the biggest reason is that it provides a component to our internal set of applications and libraries that a modern desktop can not be without, and that it is the completeness of that set of technologies that gives KDE one of it's most valuable assets: agility.
others have said it before me, but it bears repeating: KDE is the only mainstream desktop that is nimble enough to push out broad sweeping changes that require application support to matter in a very short period of time (e.g. <1 year). this is due in large part to the large number of applications that are developed as part of the larger KDE project community. this include applications in KDE extra gear as much as it does those in kdebase.
Microsoft has a large stable of applications, but the internal management structure does not lend itself to nimbly changing the applications across the board. GNOME has the community oriented aspect necessary, but lacks the coherence across application projects to fully assert such changes at will from the center. (i'm noting making this up, Havoc said as much in his recent blog on his ideas for GNOME3.) Apple probably has the internal structure to accomplish this, but not enough applications.
with khtml, KDE can do something interesting and cool in a base library and instantly have it available in every html using KDE application. inline spell checking was one such cool addition in recent years. we couldn't do this without khtml.
as KDE4 comes up we'll be able to make the changes we desire and need in khtml without Mozilla becoming a show stopping blocker for us because their development cycle doesn't match ours. we can make changes to KOffice without having to wait for OOo to decide whether or not to join in and make a new release, which is especially poignant given that KOffice will be using the same file formats as OOo. we can deliver a few hundred native applications in one fell push to the download servers that coherently deliver what our libraries have to offer.
now, this does not mean we should not continue to improve our working relationships to Mozilla or OOo or other such projects, it just means we can do so without becoming inextricably tied to their schedules and priorities. in fact, KDE is probably the most capable desktop to form such working relationships because the liability involved in such cooperation is very low for KDE. this lowered risk affords us greater latitude to explore the options in the wider world, and we should take advantage of that.
viva la khtml!
Subscribe to:
Post Comments (Atom)
11 comments:
I agree, KHTML is important, even though a lot of konqueror's rendering is grotesque, I end up using it exclusively because it's integrated. That's exceptionally important to me.
Though, this is where it ends in my eyes. As long as it's integrated, I'll choose gecko over KHTML every time, it's a bit heavier, but not by much. At least, that's what I find. Even if it renders slower, it renders more and accurately. Being faster at a subset is not being faster, in my eyes. Unfortunately, SUSE 9.1 doesn't seem to get any Firefox love so I can't test it, but I find Firefox to be faster when it comes to rendering, but that's on different machines.
I can see some issues, from what I gather it goes something like this.
KHTML is sort of slowed by Apple, AFAIK much of the work done on Safari/KHTML isn't inputted upstream, but rather must be ported by the KHTML team. In anycase, that's time wasted. I could be wrong about this, but you'd think Apple would be interested in having the current KHTML team and their KHTML team to work on the same base so there is more work and things get done faster and better -- at little cost.
Then there is the fact that browser code is non-trivial. So you don't have a lot of hackers who can step up. I can't even begin to imagine how big the code is and how hard it would be to jump in somewhere and get something done.
Also there are a lot of standards that must be implemented besides simply the de-facto non-standards of IE but those can be ignored and that won't be too big a deal.
(try again)
hey aaron
(this post made me make a blog account... nothing to see there, move on ;-))
your post made me think of the projects talked about by a gnome dev.
*some diggin'*
here you go: http://www.oreillynet.com/pub/wlg/6911
that's a cool idea. being able to save your current 'workspace' as a project, to open it later, thats not only cool, but actually usefull. it would make using your computer desktop even easier than your real one (as its damn easy to clean it :D)
@saem: kthml doesn't derive it's value from being Konqueror's rendering engine. it's the fact that KDE has greater control over its direction and its use throughout KDE applications other than Konqueror that gives kthml its value.
even if/when gecko becomes a standard kpart for use in Konqueror as the web browser engine, khtml will still be invaluable to KDE.
@superstoned: i described this concept in my blog entry of April 13 (though i'm hardly the first to cover this idea =). Jono posted his blog on this topic on the 21st. i wonder if he reads my blog? =)
I like khtml for one reason, and that's plain speed, but I simply refuse to use it at the moment due to the fact that it won't render gmail/javascript. I couldn't find a bug in b00gzilla stateing that it is broken, but I haven't had much time to look.
@aaron
Fair enough, there is control over the direction. Which is nice, but to render HTML, what else is there. If speed is a problem, the KDE crowd working on Gecko can serve KDE's interest by optimizing it. If it's missing something that KDE requires, roll it in.
So the direction isn't TOO big a deal. Though, in the previous paragraph, I've over simplified things to a degree but nothing going too far.
So even though apps may use KHTML, if gecko can be helped to deliver all that KHTML does now, then what's left?
If at any time that gecko seriously hampers KDE, forking remains an option, but at least until that happens we can ride on a lot of developer power of Mozilla.
hey aaron,
i just read these two, aparently talking about what an apple employee said about spotlight - actually he is describing tenor :D
klik
klik
and this is the apple dev's post on /.
klik
and about your blog from april 13, someone there is talking about more and dynamic use of kpart-technology. i've been thinking (and even bugged developers) about a bad way to do that, some time ago. my idea was to enable konqi to open documents and pictures read/write, so you could save your session as a bunch of tabs. anyway, that was a bad idea - basically, you just try to work around bad window management, that way. so - saving a session, and using tenor to manage these dynamically - adding relevant information automatically, that would also fulfill this need.
Opera, btw, has a nice feature - save session. of course, its just like you bookmark a bunch of tabs (altough, i recall opera also seves position in documents, and unfinished posts on forums etc). pretty neath.
is there a better way for Safari/KHTML devs and KDE/KHTML devs to interoperate? It seems so disappointing to hear about backporting instead of working from the same /root. Maybe this is with regards to control. How does this compare to Darwin development?
@saem:
"if gecko can be helped to deliver all that KHTML does now, then what's left?"
yes, if they were identical in properties then there would be nothing that khtml could offer over it. =)
but they are not identical in properties. for instance, KDE does not have any say over the release cycles of gecko.
"but they are not identical in properties. for instance, KDE does not have any say over the release cycles of gecko."
I see you point, and now I completely agree with you. I just wish I was proficient enough to help out with the project.
Post a Comment