Being a khtml developer and reading all those posts on the planet I just feel confused.
Basically, there are like 3 sentences to sum up. I like to work on khtml because it’s interesting and I get to work with super-smart people like Maksim or Germain and others. I don’t want to work on QtWebkit (or any other fork of webkit) as a free developer (without being paid) because it would mean I have to constantly keep up with work done by apple and other companies. Is it as much interesting? for me it’s not. And the third – it’s really possible to integrate both engines in konq and let people choose, with KPart technologies it’s only about making additional button (hopefully).
From my pov I would wish for one thing – contribution. Either it would be developing webkit kpart, konq, khtml, reporting bugs, broken sites, helping triaging (yay to bugsquad!), making testcases. And you can see – you don’t have to be a C++ developer to do that, you don’t have to be developer at all. Though I can’t make people do anything, let’s agree on that (it’s only my wish š ).
So, it’s just my 2 cents about the topic after all…
Vtokarev's Weblog 
July 1, 2009 at 1:58 am |
I understand what you are saying. I think on the matters regarding bug reporting, broken sites, and perhaps triaging are the least of the problems with khtml. There are plenty of bug reports covering the problems with konqueror. The problem seems to be; no one really wants to work on them. My biggest issue with konqueror is flash, and for most sites I just don’t use konqueror anymore. It took me a long time to get over that since switching to kde4, and it still really annoys me that I have to use firefox. The only way I have been able to see any flash in konqueror is with the kmplayer hack. It works… mostly… kind of… and not near as good as flash in firefox. I personally think flash is a scourge, a pox. But it seems now a days, many, many web sites are in love with it.
I remember long ago before kde-4.0 was launched while it was still being talked about and things were abuzz over dolphin. I asked on thedot (IIRC) if konqueor was going to be left to the wayside in favor of dolphin. I was assured by Arron then that was not going to happen. Sadly, as I have bumped my version of kde from 4.0 through each release to 4.2.4, I can only assume I was mislead by Aaron’s response. Frankly, I have not seen that much work put into konqueror. I got the impression then no one really wanted to fix konqueror which is why they started focusing on dolphin.
I would love to help, and don’t really care if khtml or webkit is used. It simply does not matter to me. Was does… konqueror being restored to its rightful place as the kick-ass application that it was known for.
July 1, 2009 at 2:30 am |
@Dennis: bug reporting and stuff is not the least problems with khtml. Having more bug reports is good for several reasons. E.g. you can pick stuff that’s important (lots of reports). You can easier reduce problem by picking simpler reports. And reducing the problem (includes dealing with tons of html/js hacking) could take as much time as actually fixing the bug in khtml itself.
About the flash: after switching to qt4.5 I have much less issues with flash. I’m happily using youtube without a problem nowadays e.g. I know it’s not a good reason if for someone it just works. At least, it shows that it’s possible to make it work.
And the last: please don’t tell that noone want to fix bugs. There are. I would reason here with you – I can point you to change logs of konq, khtml, closed bug reports etc.
July 1, 2009 at 2:35 am |
While I completely understand your point of view, there is another one to consider. Sometimes, its best to just let something die. KHTML was fantastic back in the day, it then evolved, rather forcefully into Webkit. Now, Webkit has left KHTML in the dust and its about time everyone realised that.
Just like evolution of life, when the human species split into the Neanderthals and the Homo Sapiens, only one survived. The superior one. Its about time we all realised that KHTML needs to die in order for KDE to flourish as a whole, using webkit as the basis for Konqueror.
July 1, 2009 at 3:01 am |
Well, we are not in the marketing here. I consider myself a dev who just want to hack on something cool (from my POV) with cool people. And I don’t think you jest let project die… it happens with time if something else comes around (better alternative). With KDE/khtml this is not the case yet.
July 1, 2009 at 2:43 am |
Well I don’t spend a lot of time keeping a close pulse on what you devs are doing in the background. I just take a quick look at the changelog as posted on the kde site when they announce the availability of the next version. So yes, there are folks plugging away on konqueror… there just doesn’t seem to be that much progress.
That’s great flash works mostly in 4.5, it mostly, kind of, sort of works now. But this particular issue people have been gnashing their teeth about for several years. So it looks like I will have to wait another year for 4.5.
The thing I don’t really understand is this… you have mentioned bug reports, traige, etc being helpful. I can agree with that. But I have the feeling there is some other issue that is going on with konqueror. I just don’t know what that is. I it just a lack of developers?
July 1, 2009 at 2:46 am |
I feel your pain, knowing that Webkit was forked from KHTML long ago, and KHTML devs don’t get half the credit they deserve for that. But sadly as I see know, there is simply not enough manpower to keep KHTML going with this insane browser (r)evolution, Firefox and Chrome are beating the hell out of each other on speed basis, but I feel that KHTML just doesn’t have that development squad behind it, that can compete with Google’s and Mozilla’s boys, even Microsoft is starting to feel cornered.
My big problem is with Konqueror is that it’s not Firefox or IE, they both render differently, they are two worlds, Opera and Safari take Firefox as the reference, so they render almost like Firefox. The problem is that here comes Konqueror which has a very small userbase, and comes as a third player, that would require extra attention. The problem here is that Konqueror has too small userbase to get that extra attention, so the only thing it could do if it had the manpower is to be like Firefox.
I have read an argument a few weeks ago that Konqueror renders KDE widgets, which is nice and all, but we web developers like to customise those anyway.
July 1, 2009 at 3:10 am |
Truely, I feel no pain at all. I wasn’t there when it was forked and now it’s completely diferent project.
Anyway such kind of comments is not helping anyone to gain motivation to work on something. I think everyone who is smart enough to run linux is know how good could be healthy interaction between kde-qt-webkit. So repeating it doesn’t help them to understand that more. And I already said my reasons to to participate in that interacticon.
And also it doesn’t help either for motivation of people who is working now on kde technologies: konq/khtml. It’s even likely otherwise for them.
July 1, 2009 at 4:17 am |
Guys, you can’t tell / suggest to people what they should be to hacking on ‘for fun’ . The whole point of them doing it is _for fun_. Enjoyment etc.. it’s like suggesting to someone which model of car they should be working on in their spare time.
Should KDE include the KHTML kpart as the default rendering engine for konqueror ? In the long term the answer may be no, BUT at _this_ time , the webkit kpart is not yet working. Aurora is not yet functional enough to replace konqueror as the _default_ web browser shipping with KDE.
So as vtokarev pointed out you can :
a) help with bug reports on KHTML
b) help with development on the webkit kpart
c) help with development of aurora or another replacement.
Trying to convince the (3)? KHTML developers to stop working on KHTML is both pointless and down right rude.
To the devs, thank you for your hardwork.
July 1, 2009 at 4:55 am |
It is people like you, vtokarev, and the other KHTML devs that make open source what it is. THANK YOU SOOO MUCH for doing what you enjoy and sharing it with others.
It has been simple all along, and you said it here again: If enough other developers are motivated and interested and working on a webkit part, it cost little to integrate it into konqueror and no one will stand in the way to prevent them from doing that. There’s been LOTS and LOTS of talk but little action. Till then, I am very very very grateful to you and the other KHTML devs are doing what you so clearly enjoy doing: providing a better KHTML with every KDE release. Yeah, we all know there may be a few areas that it doesn’t serve every user’s need. But until enough people put their efforts where their mouths are, I am very happy that you and the other KHTML devs remain interested in improving KHTML.
This much I know: There are many users who are genuinely grateful for your work and I’m happy to speak for them here.
Thanks again!!!
July 1, 2009 at 5:05 am |
Thanks for the good words š
And here I probably make a general comment: KDE is *free* desktop environment which is developed by volunteers, if you want want it engaged more with companies like Google, Apple you should probably just use their products instead. Or the one that were able to find collaboration with them, e.g. like Mozzila does.
Anyway, ideally perfect balance is needed, but we are not living in the perfect world.
July 1, 2009 at 5:32 am |
I want to say something to KHTML developers: YOU ARE THE BEST. If I were a programmer, I will work on KHTML. Other guys should stop talking and should start working in what they see is good and fun for them.
July 1, 2009 at 7:59 am |
Wow, really remarkable š So in the end the KDE community will be composed by 50-100 people happily working on a highly insulated closed circle.
July 1, 2009 at 8:56 am
The situation will not get better, if the insulated closed circle kept there and feed by trolling.
But the situation will get better if someone step up and get kdewebkit part work.
July 1, 2009 at 9:00 am
“Wow, really remarkable š So in the end the KDE community will be composed by 50-100 people happily working on a highly insulated closed circle.”
This doesn’t make any sense at all: KDE developers have been working on “what is good and fun for them” since the beginning, and the number of people contributing to KDE has been going up and up the whole time.
July 1, 2009 at 5:11 pm
So? What’s the problem there?
July 1, 2009 at 5:48 am |
OK, I have heard these arguments before and I don’t accept them anymore.
There is no denying that KHTML is lacking and with Apple, Google, Mozilla and MS against you it will only get worse.
Here is why:
The browser is becoming a application platform and if you don’t have the user base your engine will not be supported because every complex web app is buggy and only works in tested browsers.
You guys and the few konq users need to accept that. Once you have you will see that you contribution isn’t really helping KDE.
It is hurting KDE. Yeah, you heard that right. You guys are giving people the illusion that things might get better, but they aren’t. And for social reasons you keep people from working on other stuff.
So please just stop and thereby increase the pressure for a working solution. You guys don’t have one and_it_is_hurting_KDE.
July 1, 2009 at 6:03 am |
It’s only your vision of the world. While I agree with you that browser is becoming an application platform, I think of the progress being made quite differently. Maintaing the whole platfrom means slow down progress very much as you would have to support backward compatibility. Therefore it means stable specs e.g.
Moreover look how audio/video tags or svg is still not widely used, though major browsers support them (except IE). And microsoft will not give up easily here.
July 1, 2009 at 7:16 am
I don’t think so, but even if the rapid browser innovation were to slow down things like Google Web Kit etc will never have a profile for KHTML, because … here comes the clue stick .. you don’t matter because nobody uses KHTML and that will not change!
It will be a 24/7 job to get things like Google Wave working in FF, IE, Chrome, Safari and Opera. Nobody will care for KHTML.
Sorry, but you guys seem delusional.
Even most _KDE_ devs don’t use KHTML .. reality check anybody?
July 1, 2009 at 7:55 am
Hm, what about Microsoft? linux share is yet very small. Why do you consider it or hope for the better? you need more arguments
July 1, 2009 at 8:24 am
So I guess this was about my post. I admit, I don’t have any clue what you mean.
I’m not talking about microsoft in any way, and I don’t say anything is wrong with linux. Do you mind explaining closer what you’re targeting at?
July 1, 2009 at 8:18 am
Google Web Toolkit, not Google Web Kit
KHTML is OK for KDElibs, but not for the web as we have it today.
It is _just broken_ for users, don’t let some KDE geeks or KHTML devs tell you otherwise.
There are alternatives, but this stupid hope that KHTML will be sufficient at some point in the distant future is really bad. You guys will never keep up with open source rendering engines that are fueled with boat loads of money.
_You just won’t_ and the sooner you get that into your thick heads the better for everybody.
And as always Web devs will never care for KHTML, just get used to it. W3C standards won’t help you. Not a bit. They are too big and too complex for web apps and that is why web apps only work in tested engines.
July 1, 2009 at 8:26 am
what’s the point here exactly? except for being rude
July 1, 2009 at 8:47 am
Do I get it wrong or is the reply here strange. I’m in the same “column” replying to you (?). Then it probably wasn’t targetted to me (?).
Anyway, I can’t see where I’ve been rude anyway.
Well, it’s a fact that the browser becomes a “central” application nowdays. A browser must feature those things for a proper web experience for a lot of users.
Konqueror/KHTML does not offer this nowdays (but did offer a great web experience for a long time). With HTML5/JS and all this pling-pling coming, and companies actively developing engines, it will get harder and harder to catch up with them (google, apple, opera, mozilla).
July 1, 2009 at 7:59 am |
+1 for “it’s hurting KDE”
July 1, 2009 at 9:30 am
and trolling is hurting more !
July 1, 2009 at 5:49 am |
You are doing really good work! And as you don’t get payed for anything you can develop what makes more fun for you.
Imho the people complaining should first come up with a fully integrated working WebKit KPart and then let the users decide. But they can *not* expect from KHTML developers doing that.
Go KHTML, go!
July 1, 2009 at 7:32 am |
totally agree
July 1, 2009 at 8:45 am |
Yes, I agree with you !
I wonder, why Nokia (Qt software) does not hire a guy to fix WebKit Kpart ?
July 1, 2009 at 10:59 am
What should be the reason for hireing? KDE is just a platform using Qt.
They don’t care if there is a webkit part for kde, I think.
July 1, 2009 at 12:40 pm |
Yes, let’s discard all valid constructive critisism if the person is not skilled in C++. That will totally lead us to better relationship between developers and users
July 1, 2009 at 1:38 pm
Is it valid and constructive at all?
Anyway, relationship with users are always hard for geeks, please understand that
July 1, 2009 at 6:23 am |
it is very important to support khtml and konqueror as the browser will be the principal application.
I think the javascript of konqueror is not very good as when i disabled it the browsing is extreme fast
July 1, 2009 at 6:30 am |
Oh, poor child. If you don’t like working on QtWebKit, because you have to work in a larger team that consists of more than three or five people, then do us all a favor and move KHTML out of kdelibs and into playground where you can play all day long on stuff you like and don’t hurt KDE users with your totally lacking rendering engine.
July 1, 2009 at 6:43 am |
Please don’t suggest something you know nothing about.
a) khtml has to stay in kdelibs till kde5
b) there apps like kopete or kmail that currently depends on khtml and no one yet showed intention to change that (why should it we as it works and stable)
And the problem is not working in a big team, the problem is that there are full-time payed contributors that are doing their jobs and people who contributing in their free time. It’s just not that interesting for me as you would have to adjust your workflow.
July 1, 2009 at 7:42 am
Well, kopete and others could switch as well. But why doing so, it’s not wrong having it included.
It’s worth for those programs (and works good), but as a “default” browsing engine in a web browser it’s just not full-featured enough.
I think that are two different needs.
July 1, 2009 at 7:46 am
I know about “a)”. That was a nice shot to sabotage QtWebKit. But you don’t tell the truth. KHTML doesn’t have to be there, only something compatible has to be.
So if you KHTML guys had any dignity, you’d written a KHTML-API to QtWebKit adapter, moved the actual KHTML code out of kdelibs, and let common users browse web sites that are incompatible with KHTML.
Instead you prefer to torture anyone who just uses the default KDE browser, because he/she doesn’t know better. I’ve seen people switch the whole DE, because they didn’t know they can use non-default applications under KDE. After I told them that they could do that, they didn’t bother, because they got already used to GNOME or whatever.
Regarding “b)”: The two apps you’ve listed probably only use KHTML because their source code is so old, there wasn’t an alternative back then. It’s totally different with newer apps. Mailody switched to WebKit a while ago. Plasma uses WebKit exclusively. AFAIK the same is true for Amarok, whose team has bigger resources than KMail/…
If you really refuse to adjust your workflow, I really hope your employer (if you have one) reads this. With this attitude, you’ll probably never get the chance to work on FOSS for a living. Normal people’s dream is to do their hobby for a living. Have you even tried to work with the WebKit team or are you just assuming that it’s bad? I’ve only read good thinks about working with the WebKit team by GNOME/Epiphany developer Alp Toker.
July 1, 2009 at 7:59 am
“If you really refuse to adjust your workflow, I really hope your employer (if you have one) reads this. With this attitude, youāll probably never get the chance to work on FOSS for a living.”
The problem is, nobody pays him to do that, that makes your statement to be bogus. In a real corporate environment, your statement is quite true (he needs to adjust his workflow).
I pay a lot of respect to KHTML developers, at least they do something useful and interesting, unlike you trolling around.
July 1, 2009 at 8:35 am
@ Markus
Please stop trolling. If you have money please hire someone to work on KdeWebKit fully time and khtml developers will help him if he have problem in understanding khtml API. If you do not have money, please consider learning programing and start hacking KdeWebKit. If you do not have willing to learn programming, please consider to convince someone from developers to start hacking in something he consider it not fun for free.
Please, say something useful or consider to be silent.
July 1, 2009 at 9:21 am
@Markus you are out of line and not at all useful
July 1, 2009 at 8:50 am |
Moving khtml to playground is not decision of KHTML developers and it can not be till KDE 5.0 provide that there is a good replacement for it š .
Till now there is no good replacement for KHTML part, please consider working in it to be ready for kde4.4 .
July 1, 2009 at 9:01 am |
Give the guy a break – he works on what he wants to work on for _free_. If you pay his wages you can tell him what to do.
So, I use Konq, Arora and Firefox. Firefox has the least website issues but is horrible to use. Arora (Qt-webkit) and Konq (khtml) both have rendering issues on different sites. I’d prefer Konq with at least the option of using webkit but someone has to step up and code it. In the meantime thanks to all the khtml devs for their continued work in making the rendering engine for my (80% ish) preferred browser.
July 1, 2009 at 7:29 am |
I see this of a users point of view, as a user of KDE (well, doing some patching, but I’m basically somebody who needs it as productive system).
We don’t say KHTML isn’t worth being in KDE, it’s just not worth being KDEs default browsing engine, or at least not worth being the only choice installed in the default distribution.
In example, you could let even the users choose which engine they like – or let the distributions choose.
Reimplementing a WebKit part and let KHTML live is a good option, so you can take more than enough time to fix the existing problems with KTHML.
I agree, that if you enjoy working on KHTML – do so. But don’t deny there is a heavy need for an engine supporting javascript better than KHTML does.
Broken sites? There are plenty, if you just surf the web a little more “randomly”, you’ll recognize it.
GMAIL (chat, dynamic updates, not working with HTTPS proxy at all)
Facebook (javascript hangup)
reviewboard.kde.org (can’t publish reviews)
A lot of forum software (cookie based login)
Broken Features? KIOHTTP
Proxy support, for two years now (still no nested connections for HTTP / HTTPS, in example gmail.com, you can’t login if you’re behind a HTTP/HTTPS proxy, squid in my case). That’s a real problem being in a company, most companies force to use HTTP/HTTPS proxy servers.
I think if I continue, the list will grow for 2-3 pages. Note that this are not complaints, but it is a fact that khtml is not working properly.
I’m talking of a 6 days old trunk build, so not 4.2.2 or 4.2 or 4.1.
—-
Yes, I agree that of course somebody needs to stand up and just create a WebKit part. I don’t think I have the skills to do so, but I’ll even take a look at it, maybe I can be of some help (and if it’s just about figuring out problems with the webkit part).
July 1, 2009 at 7:48 am |
Don’t put words in my mount please. I’m not denying need for fully compatible and supported rendering engine (gecko, webkit or whatever you wish).
The main point – go and recruit people to adapt such engine in KDE, if you can’t – then don’t suggest changing something that’s already working even if not perfectly
July 1, 2009 at 8:13 am
Well, my apologies, but your post seems like “it works for kopete, kmail and others”. It looks as if you don’t see any need, and that was my point. Obviously, there is a need for a WebKit part, and I also say it’s ok if you don’t intend to work on this. It’s your spare time, do what ever you want, even if it’s probably of no use at all long-term (if you don’t mind that).
I’d say the webkit part already works as well as KHTML at the moment. I at least havn’t found more problems with it than I have with khtml.
I’m in example patching JuK, and yes, I’m for replacing JuK with amarok. Amarok is by far more widely used, and obviously does a better job for most users than JuK does.
July 1, 2009 at 8:13 am |
wait a minute, what the difference between kio and khtml ? I think the KWebKit is using kio ? Moreover the https thing is upstream bug not kde bug š
July 1, 2009 at 8:14 am
That was mentioned as a problem with Konqueror, not KHTML.
July 1, 2009 at 9:35 am
@ STiAT
Fair enough, I thought you blame khtml for kio bugs. I think kdewebkit part will be good option but some bugs will be there which not related to html engine.
July 1, 2009 at 10:19 am
True, there will be bugs, which probably won’t be fixed. It’s maybe wrong bringing up a problem of Konqueror to a KHTML topic. Still, it is a problem :p .. but maybe a more kdelibs related one.
I was also a bit mislead, since the qwebkit browsers of course don’t have this problems (since they won’t use kiohttp :p).
Well, there are enough other things which would need attention in khtml / kjs as well, so just forget about this one.
Basically, we have a kde problem. Missing developers for a webkit part, which seems as if it is hard to find.
Allthough, maybe we can get some devs on this for 4.4 or 4.5 (?).
July 1, 2009 at 6:15 pm |
> A lot of forum software (cookie based login)
Well then do report those sites to the bug database. I currently have 6 or 7 sites open in different tabs, all of them cookie based logins into different forum applications – none of them has any problem whatsoever.
July 1, 2009 at 7:30 am |
From a user’s perspective Konqueror is quite a good browser. I like it way better than Mozilla or Opera. What it lacks is a whole bunch of plugins that Mozilla has.
As for WebKit…hmmm. Maybe this idea is a dumb one, but is is it possible to make Konq a multy-core browser. By this I mean multy-rendering-engines browser. So that it would have a dropbox allowing to switch from khtml to gecko and webkit. I think it would be a killer application for a KDE desktop. It would bring the power of 3 most advansed browsers into one KDE app.
I am not sure if it is technically feasible.
Anyway, what is technically feasible is to create a community behind Konq to make it better to make it stand out. This is my word as a communication specialist.
July 1, 2009 at 2:35 pm |
I think it is wrong to dismiss the differences between Konqueror and competing browsers as simply a lack of plugins. Built-in features that are present in most, if not all, modern web browsers are lacking in konqueror. This includes the full-text address bar bookmark and history search (what started as the firefox “awesome” bar but was quickly copied by others), open window lists, “highlight all” in find, runners that can do actions on web page contents (like IE activities and Firefox Ubiquity), downloadable search engines, private browsing, and per-tab processes. Konqueror has some cool, unique features, but it also lacks features that are quickly becoming de-facto standards in modern web browsers. This, of course, can be rectified by implementing these features, but at least for 4.3 konqueror simply lacks features that most or all of its competitors have and that people therefore rightly expect from their web browsers. That is not to say konqueror is a bad browser, it is a very good browser, but to be realistic it does lack features found in its competitors. Frankly, my problem with konqueror is more the lack of features I use a lot (like the so-called “awesomebar”) rather than problems with khtml.
July 1, 2009 at 8:07 am |
What if …. konqueror wasn’t present on KDE4 ? Distributions would have shipped Firefox, Users will get their standars web experience, maybe praise Linux for that.
Instead Users browse with khtml, get frustrated, drop konqueror, eventually they drop KDE. Many developers do that too. Nobody wants to offend khtml developers, they’re great! But it will be a good move to move it to playground.. KDE governance seems not that wise here..
July 1, 2009 at 8:11 am |
well, some time ago there were some loud voices crirticizing KDE E.V. for KDE4. These voices were just screaming, but the resulting DE is just a great one.
July 1, 2009 at 8:18 am
I still do have critism for KDE4, but not for the desktop but rather for how and in which state it was released ;-).
The DE itself is a great one – or at least it starts to become a great one now with 4.3.
July 1, 2009 at 8:18 am |
Really I do not understand your logic. You suggest to drop konqueror for Firefox. What I know that most distribution is shipping Firefox as the default browser. This is distribution decision not KDE decision.
July 1, 2009 at 8:55 am
Hopefully not, that’s what I currently have :D.
Nothing is wrong with Konqueror as a browser!
Nothing is wrong with KHTML / KJS as engines!
It is a Problem that nobody stands up and gives the option to users to use another engine (WebKit or what ever you want).
It’s actually a problem that KHTML developers can’t be blamed for. They do what they want, and do their best to provide a working HTML / JS engine for KDE.
But well, we can blame … the world, all of them, for not having a developer willed to do this WebKit part š … (j/k).
If I understood vtokarev correctly, he wouldn’t mind another kpart for webkit. He just states that he (and very likely other KHTML devs) won’t be the ones working on this (did I get it right now? :D).
July 1, 2009 at 9:05 am
Sorry for the mislead with replies, I just don’t get why it works incorrectly sometimes š
Yes, you get it right.
July 1, 2009 at 8:20 am |
Yes, it’s your right to hack on KHTML and have fun. Nobody can blame you if you like doing that. But the fact is — KHTML doesn’t satisfy most of the users anymore. It doesn’t even satisfy your fellow KDE developers.
So, go on, keep working on KHTML, we are not blaming you for that. But don’t act surprised when you find out that nobody thinks KHTML is relevant. The simple truth is nobody cares about KHTML.
I am sorry to tell you that when somebody finally will do at least half-decent attempt of working on WebKit-KPart, he will get much more credit then you. He might be not as good as you and work not as hard as you. But he will be loved and saluted by everyone, because his efforts will do much more for KDE’s success.
And that moaning on Planet — it’s not about you working on what you find fun, it’s about lack of working WebKit-KPart. Nobody will force you to work on it, it’s just you are the most qualified person to do it.
Oh, and maybe — just maybe — if you will try to work on something that most of your users care about, you will suddenly feel motivated to continue? Maybe you could allocate at least day or two to poking at WebKit KPart? Will it really hurt?
July 1, 2009 at 8:50 am |
Very nicely put…
KDE users know, half the KDE devs know, why only KHTML devs live in isolation…
and refuse the acknowledge that there is a problem with KHTML..
Although I have limited c++ experience, I will definitely definitely will get involved in webkit integration with konq.
July 1, 2009 at 8:23 am |
Hello vtokarev, I just wanted to say that you have the perfect attitude š
khtml and webkit are different
you are free to work on what you want
contribution is the solution
good luck !
July 1, 2009 at 8:53 am |
Vtokarev : good for you, man. It is your free time and you have no obligation whats-o-ever to anyone who tries to freeload on your skill by trying to force you to work on something you do not quite enjoy as much. It is like saying to someone who plays amateur football in her free time : stop doing that, you’ll never reach champions league and you are hurting the image of football. Rude nonsense and I have no problem calling it out as such.
To all those are so passionate that they feel the need to badmouth your work as ‘hurting KDE’ : put up or shut up. Ie, develop the QtWebKit-konqueror yourself or, if you lack the skills, pool up resources and offer Vtokarev something he can’t refuse : an excellent salery to do as you wish him to do.
July 1, 2009 at 9:55 am |
Thank you very much KHTML and Konqueror developers for al the hard work you do! I hope all this moaning about KHTML doesn’t discourage you to continue woring that hard in the future. Just keep in mind that we do exist: users who use Konqueror with KTML and we like using it more than what else is currently available elsewhere. In our household and at my parents’ house we are all using Konqueror and it is working very well, including Flash. It’s not perfect ofcourse, but the pluses like integration outweight the minuses for us. I still remember when Firefox (still Mozilla back then) first came out. There were more problems with it and I had to use IE more frequently than I have to use Firefox currently. So it sure is not as bad as some people are traing to portray it. Maybe we have just become more spoiled and like to complain more. It would be so much better to see people actually doing something to improve the situation in a way they think it is best than to complain and by doing so possibly do some harm. I also can’t understand how someone can say that people improving Konqueror and KHTML do harm, Come one, Improving things can’t do harm. What’s doing more harm is complaining and doing nothing on the WebKit part integration. So yeah in the ende I’d say, more work and less complaining and talking and this would be the best for all. And again thank you to all *working* on KHTML/Konqueror and KDE WebKit/Konqueror, as in the end that is all that matters.
July 1, 2009 at 10:07 am |
Sponsored hack sprints might make a difference..
July 1, 2009 at 10:40 am |
KHTML is fine KJS is the one that needs some love! Just rip off squirrelfish extreme and get on with it š
July 1, 2009 at 11:03 am |
Couldn’t you simply create some compatibility layer / API so one could select what to use (KHTML, WebKit or even Gecko if someone can be bothered to integrate it) in KDE’s system settings and then all applications that want to show some HTML use the chosen rendering engine?
That way everybody should be happy as one could use ones preferred choice, no justification for any bitching would be there and you would be free to work on your choice without getting flamed every other day. (Don’t take it personally but KHTML is really lacking on quite some “web 2.0” sites – doesn’t matter if the sites are to blame or KHTML, to an user it simply “doesn’t work”).
Therefore please give it a thought since it would solve that mess once and for all (thanks to a compatibility layer it could be introduced to 4.x as well without any need to wait for KDE 5.x).
July 1, 2009 at 11:26 am |
There is already that layer and it’s called KPart.
btw, the web2.0 term is misleading, there is no general concept behind it
July 1, 2009 at 1:11 pm |
OK, here you will find the documentation of KPart :
http://developer.kde.org/documentation/tutorials/kparts/index.html
I’m waiting WebKit Kpart for kde4.4 š
July 1, 2009 at 11:05 am |
I totally support KHTML. I think it is very healthy for KDE that it exists and I hope it can compete with other rendering engines. I think a world where a small indipendant rendering engine is also competative is a better one. I hope that neither of my comments on other blogs appeared to suggest otherwise.
The points I made were simply that, from the point of view of engineering the whole desktop environment, there seems to be a problem with the browser. This is not suggesting any particular technical issue just that a significant proportion of users clearly don’t find KHTML/Konqueror meets their needs.
And *from this point of view* (the overall design of the KDE experience) it is hard to dismiss the issue. That doesn’t necessarily mean using WebKit and it certainly doesn’t mean telling you that you have to work on WebKit.
Konqueror is a great browser and could be a world-beating browser with it’s current architecture, the possibilities provided by other KDE technology and fixing whatever is bugging current KDE users into using other browsers.
July 1, 2009 at 2:14 pm |
I think what people really moan about is the perceived potential benefit of you working on qtwebkit, which is wrong, just like the OMG LINUX SUX, KDE & GNOME SHUD MERG, DONT 2PLICATE STUF comments…
I agree with you, nobody can force you to hack on something you don’t want to and until people actually work themselves on what they want to get, things are going to stay the same. IMHO, the fact that this is not happening just shows how difficult it is to make a good browser engine.
I personally use konqueror a lot for documentation (man pages, OSS websites that dont have too much bling, APIs, etc.) Having all that stuff accessible from a single point is great (e.g. kwallet integration in drkonqi). For the bling I use opera/FF and loathe the lack of integration (although this is another topic, XDG…)
Some more visibility of the Konq/khtml/kjs developers on planet would definately be a good thing though, sometimes the lack of communication makes it look like your project is almost abandoned.
keep it up
vespas
July 1, 2009 at 7:45 pm |
I agree with you that Konq/KHTML/KJS developers should speak up and be proud of their work (Really you should). Please, vtokarev keep bloging about KHTML.
July 1, 2009 at 2:18 pm |
Keep up the good work, and keep hacking on what you want to hack on.
People simply do not understand that no one is preventing a webkit part from being developed by working on khtml.
It is not about marketing or what people think is best. KDE is a free project and most work is voluntary: people work on what they want to work on. It is that simple: the one who does the work decides.
If there is the need for a webkit part, someone has (and will continue) to hack on it. People that are working on khtml deserve our praise, and I hope they will find motivation to continue doing so.
This is open source at its best.
July 1, 2009 at 2:26 pm |
Keep on the good work! KHTM/Konqueror *do* rock!
July 1, 2009 at 5:56 pm |
I find it rather amusing that people are blaming khtml for the distributors choice. Why do they have to make the “browser” icon launch konqueror, when firefox is currently the only shipped browser that can do all of the job?
July 1, 2009 at 7:45 pm |
– Nurcse, maybe we could go to reanimation…?
– No, the doctor said to morgue – so we go to morgue!
Seriously, stop burying khtml when it is alive and lives happily. This is not the way the project dies – even a good project would die when no one wants to continue working on it – this is not the case for khtml.
If you want webkit in konqueror – write a better kpart which would intergrate to kde like khtml does or even better – so there would no more reasons to leave khtml there. For now there are plenty of reasons not to do this.
Until this is so, khtml would live and evolve. I do not want plain html renderer with no integration inside konqueror – its power not in this – use aurora if want plain webkit.
Healthy competition would always be good for both competing projects and in the end for end users.