anda_skoa wrote:Exactly.
Which is why it looks like there won't be a replacement, or in your words "move to another engine", because doing that is not yet know to be even feasible (if at all possible).

Cheers,
_

You are joking aren't you?

To have Konqueror be useful to all and sundry as a browser, something needs to be done.
A Gecko based KPart would be brillient
A Webkit based KPart would do
A KHTML based one that behaves EXACTLY as Webkit, same behaviour, same rendering bug for same rendering bug would also achieve the desired outcome for end users.

That way, when a Web developer tests his project against what they think are the browsers of choice of his/her intended users, Konqueror users will also get the expected behaviour of that Web based project. Most Web devs don't test against Konqueror/KHTML. They test against IE, Firefox/Gecko, and Safari/Chrome/Webkit. If you think this is gunna change, well then there you go.

KHTML's publicly facing API and interfaces are surely more stable a target than all of the multitude of Web projects out there in the world.

StopTheFail wrote:You are joking aren't you?

No.
I follow KDE development quite closely, even in areas I am not directly involved with and while I know that people are working on WebKit integration as a KPart and as an additional render engine, I haven't even seen the slightes hint of anyone attempting or evaluating replacement of KHTML's internals.

StopTheFail wrote:A Gecko based KPart would be brillient
A Webkit based KPart would do
A KHTML based one that behaves EXACTLY as Webkit, same behaviour, same rendering bug for same rendering bug would also achieve the desired outcome for end users.

We do agree on that, don't we?

StopTheFail wrote:That way, when a Web developer tests his project against what they think are the browsers of choice of his/her intended users, Konqueror users will also get the expected behaviour of that Web based project. Most Web devs don't test against Konqueror/KHTML. They test against IE, Firefox/Gecko, and Safari/Chrome/Webkit. If you think this is gunna change, well then there you go.

Why would I assume that?
I am not even confident that just switching engine will be a solution to all problems, web site developers seem to test against browsers, not engines (at least some of the runtime checks I've seen indicate that).

StopTheFail wrote:KHTML's publicly facing API and interfaces are surely more stable a target than all of the multitude of Web projects out there in the world.

Like in one of the above posts I afraid I don't understand what you try to transport with this sentence. What does the KHTML API have to do with web projects?
Most web sites do not have any API as far as I know and for those that have I am not aware of any stability policies.

Cheers,
_

anda_skoa wrote:

StopTheFail wrote:You are joking aren't you?

No.
I follow KDE development quite closely, even in areas I am not directly involved with and while I know that people are working on WebKit integration as a KPart and as an additional render engine, I haven't even seen the slightes hint of anyone attempting or evaluating replacement of KHTML's internals.

Some people are discussing the pros and cons of doing just that, but maybe not the right people?

There's certainly some delight amongst some with the news that Webkit is coming to Konqueror, as KHTML doesn't provide a viable solution to them at the moment.

Whether that's in addition to, or as replacement of KHTML seems to be of little concern to them.

anda_skoa wrote:

StopTheFail wrote:A Gecko based KPart would be brillient
A Webkit based KPart would do
A KHTML based one that behaves EXACTLY as Webkit, same behaviour, same rendering bug for same rendering bug would also achieve the desired outcome for end users.

We do agree on that, don't we?

Well it's what I think, and if you agree, then I guess that's one less thing to argue about.

anda_skoa wrote:

StopTheFail wrote:That way, when a Web developer tests his project against what they think are the browsers of choice of his/her intended users, Konqueror users will also get the expected behaviour of that Web based project. Most Web devs don't test against Konqueror/KHTML. They test against IE, Firefox/Gecko, and Safari/Chrome/Webkit. If you think this is gunna change, well then there you go.

Why would I assume that?
I am not even confident that just switching engine will be a solution to all problems, web site developers seem to test against browsers, not engines (at least some of the runtime checks I've seen indicate that).

Well, surely it's the behaviour of a particular rendering engine that Web devs test against. I think it's generally accepted that with the engine goes that engines behaviour.

anda_skoa wrote:

StopTheFail wrote:KHTML's publicly facing API and interfaces are surely more stable a target than all of the multitude of Web projects out there in the world.

Like in one of the above posts I afraid I don't understand what you try to transport with this sentence. What does the KHTML API have to do with web projects?
Most web sites do not have any API as far as I know and for those that have I am not aware of any stability policies.

Cheers,
_

Well, it goes like this. Over time a renderer gets modified and enhanced in order to support the changing needs of Web devs and users.
In addition to this, and at the same time, Web devs also test against whatever the popular renderers are out there as they see it, modifying their own code in order to provide the expected behavior they're after.

There's this sort of "organic" morphing inter-play going on.

To avoid having to continually play with and maintain your own particular engine, one way to go is to use one that someone else is maintaining. One perhaps that is already considered to have the most desirable behavior. One that is very widely used, and therefore very widely tested against.

So, the specific problem we have (assuming Konqueror in its current state is unsatisfactory.)
a) Change KHTML to play nice with the websites out there in the real world, and at the same time convince web devs to code to and test against KHTML, or
b) Change things so that we use someone elses engine. One that already behaves the best with the various multitudes of websites out there, and one that is coded to and tested against in the normal course of developing a web app.

Now if it were easier to modify KHTML, and keep testing it against countless numbers of websites, and to modify it, so that those websites present the original developers intended behavior, as we wont be able to get them to test against it themselves, than this is what should happen.

If it's easier in the long run, to integrate an engine that already has all of this done for you, well that might be a good way to go.

A major determinant would be which task has the most fluid and random target. Are the public facing parts of KHTML a more stable, smaller, easier target to 'target', and therefore likely the easiest target to deal with, so then presents the least amount of constant flux while replacing KHTML or is it easier for the KDE team to monitor and test against all the random and changing and new websites that keep popping up, keep modifying KHTML and backporting parts of Webkit adinfinitum, in order to provide the desired behavior of the engine.

To summarise:
Replace KHTML, deal with KHTML's public facing interfaces,
or
Repair KHTML, deal with the internets as a whole.

When the Webkit KPart is stable and easily available, there will be much rejoicing.

StopTheFail wrote:Some people are discussing the pros and cons of doing just that, but maybe not the right people?

I am sure they are, however no such discussion has happend yet in enough detail (and I am reading kde-core-devel, kde-devel and kfm-devel)

StopTheFail wrote:Well, surely it's the behaviour of a particular rendering engine that Web devs test against. I think it's generally accepted that with the engine goes that engines behaviour.

Unforuntately not.
They test against browsers, sometimes against different versions of the same one.
A site is either sending standard content to all browsers, probably with exceptions for broken ones like IE6, or they are sending specific content to browsers they test and some fallback to others.

All of the latter I've seen so far check for browsers, even specific versions, rather than engines or versions thereof.

Using the same or very similar engine as one of the usual suspects will certainly help, but unfortunately never have the same results as using one of them directly.

StopTheFail wrote:Replace KHTML, deal with KHTML's public facing interfaces,
or
Repair KHTML, deal with the internets as a whole.

You forgot the third and most likely option
Have an alternative engine to "deal with the internets as a whole" and keep KHTML as the implementation of its interfaces.

Basically all options in reverse order of likeliness.
Option three is being worked on, option two could probably be done using more code from webkit, option one is, as far as I know, not even known to be technically possible.

Especially the required stability makes it difficult, because changes should not (more like must not) effect anything built upon it.

Developers or web engines which are part of a development framework don't have the luxury to forward any instability to their users just because their providers have not reached the same level of development majurity. Their users (application developers) expect stability.

So while it might be possible to reimplement KHTML as a wrapper on top of something else, until that has been established it is hardly possible to estimate whether implementation and maintenance of that wrapper would be less work than maintenance of the current implementation.

Since it is an option but nobody is working on it while at the same time there are several people working on the other two suggest to me that it is the least viable one.

Given my own experience with wrappers, it might actually be even easier to fork the other code base
and change it to fit the interface. Which of course is just a variant of option two, just with porting happening in the other direction.

Cheers,
_

anda_skoa wrote:

StopTheFail wrote:Some people are discussing the pros and cons of doing just that, but maybe not the right people?

I am sure they are, however no such discussion has happend yet in enough detail (and I am reading kde-core-devel, kde-devel and kfm-devel)

Yes, unfortunately it's likely KHTML will outstay its welcome by quite some time in the eyes of some. There are some others who are 'very' commited to keeping it around no matter what.

anda_skoa wrote:

StopTheFail wrote:Well, surely it's the behaviour of a particular rendering engine that Web devs test against. I think it's generally accepted that with the engine goes that engines behaviour.

Unforuntately not.
They test against browsers, sometimes against different versions of the same one.
A site is either sending standard content to all browsers, probably with exceptions for broken ones like IE6, or they are sending specific content to browsers they test and some fallback to others.

All of the latter I've seen so far check for browsers, even specific versions, rather than engines or versions thereof.

Using the same or very similar engine as one of the usual suspects will certainly help, but unfortunately never have the same results as using one of them directly.

So if I put the Webkit engine in another app, supply a Safari/Webkit Agent string with my request, and the website sends back content for a Safari/Webkit browser, I wont get the expected behaviour? News to me.

anda_skoa wrote:

StopTheFail wrote:Replace KHTML, deal with KHTML's public facing interfaces,
or
Repair KHTML, deal with the internets as a whole.

You forgot the third and most likely option
Have an alternative engine to "deal with the internets as a whole" and keep KHTML as the implementation of its interfaces.

Nah, I think I've covered that option.

StopTheFail wrote:Whether that's in addition to, or as replacement of KHTML seems to be of little concern to them.

StopTheFail wrote:Well, surely it's the behaviour of a particular rendering engine that Web devs test against. I think it's generally accepted that with the engine goes that engines behaviour.

You can test how false that is quite easily. Use a couple of different webkit-based browsers for a length of time. Say Konqueror with webkit enabled, rekonq, arora, epiphany and safari. They don't render things exactly the same. Some websites look identical. At other times, there are subtle differences, and at other times the site doesn't work as intended at all unless the browser is safari (probably because the website developer takes some of safari's idiosyncrasies into consideration, or possibly because the different browsers uses different revisions of webkit).

Kryten2X4B wrote:

StopTheFail wrote:Well, surely it's the behaviour of a particular rendering engine that Web devs test against. I think it's generally accepted that with the engine goes that engines behaviour.

You can test how false that is quite easily. Use a couple of different webkit-based browsers for a length of time. Say Konqueror with webkit enabled, rekonq, arora, epiphany and safari. They don't render things exactly the same. Some websites look identical. At other times, there are subtle differences, and at other times the site doesn't work as intended at all unless the browser is safari (probably because the website developer takes some of safari's idiosyncrasies into consideration, or possibly because the different browsers uses different revisions of webkit).

Ahh, hmmmmmmm..... O.K., I'll play along.

To say that would seem to be completely missing the point.

Now if you're after pixel perfect rendition of a page that appeared in Safari on Windows, well surely you need to be running Windows. Even re-sizing a window for any browser on any platform can alter the layout of a page somewhat, not to mention effects of different fonts, and controls etc.

So if that's what you're after, I'm afraid you're gunna have to dump Linux as your platform of choice, and do a nice little install of Microsoft Windows. I hear a lot of good things about Windows 7.

If you want to stay with Linux, and you actually want to be able to use a web app though, instead of being met with a complete pile of dysfunctional gobbledygoop, well then one of the many main-stream browsers would need to be in your arsenal, or at least a browser based on one of their engines.

Compare Google Docs and Google Wave just to name a couple. Try them in both Konqueror and in Arora. I think you'll be pleasantly surprised with Arora's rendition. Unfortunately, as Arora doesn't support flash if you're using QT 4.4, I'll have to hang onto Firefox just a little longer, or if I find the time, maybe update QT.

Now, I can certainly conceive of possible situations where by simply having the very same engine from Safari integrated into another platform, it could (however unlikely) produce undesirable behavior, in the real world where we currently live, we have to make choices from within the scope that is available to us. And if you're going to try to argue that right now, as we speak, it's better to use the Konqueror+KHTML combination rather than something else for those heavily AJAXy sites out there that break with that very combination, well then this is going to get interesting.

I can only assume you have a list of example sites that perform better in Konqueror+KHTML vs a Webkit or Gecko based browser, so I'll be interested to test them, and from that, analyse where the Webkit or Gecko based browser is running afoul.

It turns out that Arora on a Karmic install does indeed support Flash.

Good news or what eh?

StopTheFail wrote:Now if you're after pixel perfect rendition of a page that appeared in Safari on
Windows, well surely you need to be running Windows. Even re-sizing a window
for any browser on any platform can alter the layout of a page somewhat, not to
mention effects of different fonts, and controls etc.

So if that's what you're after, I'm afraid you're gunna have to dump Linux as
your platform of choice, and do a nice little install of Microsoft Windows. I
hear a lot of good things about Windows 7.

No, I'm not looking for pixel perfect rendering. I know perfectly well that's
impossible, or as near impossible as it gets anyway. And to be honest, I prefer
it that way since I don't like how Windows renders fonts.

My only point was that the rendering engine is not a catch-all solution. Most of
the time it works as intended, but there's no guarantee. Or in other words: if the
engine had been the target rather than the browser I would expect a given site to be
rendered the same on the same system. That is, changing between rekonq and arora
on Linux, or my system only for that matter, shouldn't make a difference. Everything
else stays constant after all. Fonts, resolution, color-scheme and what not.


I came across a site just a few days ago that refused to let me fill in a form
because "This browser and OS combination is not supported", and I got that in every
browser I have available (including firefox), which only goes to show that the
engine is not necessarily by itself providing better compatibility. I have no idea
what the damn site is doing to check but spoofing doesn't work either.

StopTheFail wrote:I can only assume you have a list of example sites that
perform better in Konqueror+KHTML vs a Webkit or Gecko based browser, so I'll be
interested to test them, and from that, analyse where the Webkit or Gecko based
browser is running afoul.

I only "tested" webkit-based ones so konqueor+khtml comparison is impossible.
Besides that, I didn't keep notes. It was a very rough and unscientific comparison
really, and while most sites looked fine in all browsers I could see differences
quite easily - which shouldn't be the case if the engine was all that mattered. Most
sites look fine in Konqueror too (whether they work as intended is another matter).

Oh, I was looking at a site that displays (for warning purposes) what it thinks
I'm running when it comes to OS and browser. At all times it correctly identified
the OS as Linux, but the browser...rekonq, arora, and konqueror+webkit were all
thought to be Safari. Konqueror+khtml was thought to be Mozilla/Netscape 5. The only
webkit enabled browser correctly identified was Chrome. Which, to me, sounds like
Chrome is likely to be the most compatible webkit browser for sites that check the
useragent.

Now as I said (directed at anda_skoa)

StopTheFail wrote:To have Konqueror be useful to all and sundry as a browser, something needs to be done.
A Gecko based KPart would be brillient
A Webkit based KPart would do
A KHTML based one that behaves EXACTLY as Webkit, same behaviour, same rendering bug for same rendering bug would also achieve the desired outcome for end users.

That way, when a Web developer tests his project against what they think are the browsers of choice of his/her intended users, Konqueror users will also get the expected behaviour of that Web based project. Most Web devs don't test against Konqueror/KHTML. They test against IE, Firefox/Gecko, and Safari/Chrome/Webkit. If you think this is gunna change, well then there you go.

From that I would've thought my contention could be understood by just about anyone.

You must disagree that to produce the best outcomes for users of web content, you should use the engines that web content is tested against.

Either that, or your attempting to build a stawman. (http://en.wikipedia.org/wiki/Straw_man)

You're completely entitled to, but I think any reader following this thread would see what's going on there.

To go to your points relating to host O/S detection strategies used by some sites, consider this.

No matter WHAT rendering solution is provided, if LINUX is detected as the host O/S and broken content or no content at all is send back in response to that, then do tell, how does changing Engine/Browser combos or even FIXING Konqueror+KHTML produce a desirable outcome for as long as the platform is LINUX?

Given that many binary plugins can detect O/S regardless of User Agent setting, where that strategy is used for content delivery selection, I reckon we might be in a bit of a pickle there wouldn't ya say? Perhaps we could go back to the old method of running Windows applets via a Wine plugin?

StopTheFail wrote:You must disagree that to produce the best outcomes for users of web content, you should use the engines that web content is tested against.

To some extent, yes. Because the sites are not tested against Gecko or Webkit or the IE engine. They're tested against Firefox, Safari, Chrome, and Internet explorer (okay, in that case the browser and the engine are essentially the same thing). Other browsers using the same engine will not be tested against, and it's not at all certain the site will work as intended. Sometimes because the site-devs took shortcuts, other times because the browser-developers introduced bugs, but the fact remains: the only browser 100% compatible with firefox is firefox, and the only 100% compatible with Safari is Safari. And on the platform where there is most users of respective browser - Windows and MacOS X respectively.

StopTheFail wrote:No matter WHAT rendering solution is provided, if LINUX is detected as the host O/S and broken content or no content at all is send back in response to that, then do tell, how does changing Engine/Browser combos or even FIXING Konqueror+KHTML produce a desirable outcome for as long as the platform is LINUX?

It doesn't, but that's my point. Changing to another engine is at best only a partial solution. I have no doubt it would improve the browsing experience for many, but it's no panacea as long as there are stupid web-developers around.

Kryten2X4B wrote:

StopTheFail wrote:You must disagree that to produce the best outcomes for users of web content, you should use the engines that web content is tested against.

To some extent, yes. Because the sites are not tested against Gecko or Webkit or the IE engine. They're tested against Firefox, Safari, Chrome, and Internet explorer (okay, in that case the browser and the engine are essentially the same thing). Other browsers using the same engine will not be tested against, and it's not at all certain the site will work as intended. Sometimes because the site-devs took shortcuts, other times because the browser-developers introduced bugs, but the fact remains: the only browser 100% compatible with firefox is firefox, and the only 100% compatible with Safari is Safari. And on the platform where there is most users of respective browser - Windows and MacOS X respectively.

(emphasis mine.)

And it's that kind of argument that's generally made just to try and mis-represent the main point.

Lets say we're talking about Windows appaling position with respect to malware, and someone made a statement such as:

Well a Linux PC can catch Windows virus's so na, na, nana, na!!!

Now it's true that can happen..... if we have Wine installed, etc. etc...

But it sort of misses the point by about 5 or 6 miles.

Kryten2X4B wrote:

StopTheFail wrote:No matter WHAT rendering solution is provided, if LINUX is detected as the host O/S and broken content or no content at all is send back in response to that, then do tell, how does changing Engine/Browser combos or even FIXING Konqueror+KHTML produce a desirable outcome for as long as the platform is LINUX?

It doesn't, but that's my point. Changing to another engine is at best only a partial solution. I have no doubt it would improve the browsing experience for many, but it's no panacea as long as there are stupid web-developers around.

Not only is it a partial solution, it's about the best possible solution money or dev time can buy.

I suppose it's only about the best possible solution money can buy, because by your reckoning, the actual absolute best would be to find the money to pay Apple to port Safari, and to pay Adobe, Sun, and co to release versions of their plug-ins that report spoofed O/S info.

wtbennington wrote:Konqueror - which REALLY SUCKS for web browsing

I agree with this part, although I wouldn't say it really sucks, rather it sucks compared to FF.

For all those who disagree, here ya go:

1.


2.Konqueror doesn't load the advanced editor on the KDE wiki edit page; its creator site bah.

3.There's no offline mode option on the file menu, unlike other browsers.

4.I can't seem to be able to set the page and/or text area to display from right to left, essential for rtl languages you know.

5.When images are disabled, it doesn't put any link in place of linked images, that makes the same feature pretty useless IMO.

6.Again when images are not set to load automatically, I can't view an individual image the normal way,If I choose to view the image from the right-click menu, it will open in a new tab which is not desired really.

7.History panel(Go>Show History) links open in a whole new window instead of a new tab.

That's all I can remember right now.Otherwise it's a great browser, I like how it fits the KDE workspace.Though some would say IE's Achilles' heel was also its high level of integration with Windows.

Other than Konqueror, I don't agree with your other points.In fact, I'd rather have an integrated desktop in which every application works in conjunction with other related applications;Sort of how Microsoft develops their software, it's not a bad thing as long as it doesn't hinder other software's progress.

My 2 cents.

One thing I've noticed is that, at times, Konqueror renders things wrongly while at others it renders them fine. I get the impression it's something to do with the cache, but I'm not certain.

P.S, Offline mode is part of the cache policy and can be changed in tools --> HTML settings --> Cache policy. Yes, this could probably use some love, but then Konqueror doesn't get any love by boycotting it.