StopTheFail wrote:I'm sure the effort in maintaining KHTML would outway the initial pain of integrating gecko, but as we all know, this is not going to happen.

That is not an even remotely comparable effort.
Gecko is not even available as a library with stable releases, basically everyone who used to have Gecko as their render engine had to maintain a fork and occasionaly synchronize with Mozilla.

WebKit on the other hand is meant to be used as a component by all vendors working on it, so even project which had been using Gecko have switched to WebKit, e.g. GNOME's default browser Epiphany.

Even if Gecko would be available as a real library with its own releases, API/ABI stability guarantees and so on, it would still be a tremendous effort to put the KHTML API on top of it, if that's even technically possible.
(it is not even known yet if that could be done based on WebKit and this is a direct desendent of KHTML itself)

Cheers,
_

anda_skoa wrote:That is not an even remotely comparable effort.
Gecko is not even available as a library with stable releases, basically everyone who used to have Gecko as their render engine had to maintain a fork and occasionaly synchronize with Mozilla.

WebKit on the other hand is meant to be used as a component by all vendors working on it, so even project which had been using Gecko have switched to WebKit, e.g. GNOME's default browser Epiphany.

Even if Gecko would be available as a real library with its own releases, API/ABI stability guarantees and so on, it would still be a tremendous effort to put the KHTML API on top of it, if that's even technically possible.
(it is not even known yet if that could be done based on WebKit and this is a direct desendent of KHTML itself)

Cheers,
_

Interestingly, Intel felt that basing Moblin's browser on Gecko was a worthwhile pursuit. I'd be interesting to hear from the Moblin devs why they felt it was feasable to do so, while others have chosen to go with Webkit.

On another note, that fact that Webkit is based on KHTML is of little value to KDE users as we speak, if their exposure to the standard browser for KDE is unable to provide a compelling user experience.

At the end of the day, a user doesn't care which rendering technology the devs have used. They care about results. I am unable to deploy Konqueror as a browser for users that have been using IE or Firefox. There are too many sites that either don't render correctly, or worse don't even function in a useful way when interacted with via Konqueror.

It is not even remotely feasible to expect the average user to use one browser for sites A, B, and C, and then use Firefox or IE for those sites which are broken in their primary browser.

So I ask, what is the point of providing a browser that cannot be used by the average user?

I say, integrate Firefox into KDE in a seamless way, and it turns out much work to this end has already been undertaken by the guys at Suse for which I'm very grateful. I'm sure after a few more years Konqueror, when shifted to Webkit and developed further, will provide another useful alternative, but for the time being that isn't the case, and that is the basic premise behind much of what I've talked about in this thread. To dismiss my posts as the rants of just another "hater noob" that "knows not of what he is speaking" is to be simply shooting the messenger.

I do appreciate the time and effort invested in Konqueror, I've used it myself for many years and have simply worked around any of its short-commings with other browsers, but I cannot expect most people to be happy to do the same. When we talk of what a developer or technical user is prepared to do, we can talk of work-arounds and such, but not when talking about the vast majority of users.

So I completely accept the position the current devs hold with respect to Konquerors development, and I don't see this changing any time soon. Konqueror will be what Konqueror will be, but to the users that I support, it will not be their browser of choice.

StopTheFail wrote:Interestingly, Intel felt that basing Moblin's browser on Gecko was a worthwhile pursuit. I'd be interesting to hear from the Moblin devs why they felt it was feasable to do so, while others have chosen to go with Webkit.

They probably don't care about the overhead of maintaining their own fork and WebKit might have been to late for them to consider.

StopTheFail wrote:On another note, that fact that Webkit is based on KHTML is of little value to KDE users as we speak, if their exposure to the standard browser for KDE is unable to provide a compelling user experience.

I was referring to KHTML and WebKits relation in the context of replacing KHTML.
Since it is not even known yet whether it will be possible to build KHTML's API on top of WebKit or whether KHTML needs to remain it is still very more likely that it is easier than to provide KHTML's API on top of Gecko.

StopTheFail wrote:At the end of the day, a user doesn't care which rendering technology the devs have used. They care about results. I am unable to deploy Konqueror as a browser for users that have been using IE or Firefox. There are too many sites that either don't render correctly, or worse don't even function in a useful way when interacted with via Konqueror.

Nice think with applications is that you can use any of them if one of them fits your needs better.
There are even users on Mac OS X or Windows which use Firefox because they like it better or because of extensions they like, etc.

Would be quite puzzling to find that users of Free Software desktops would only use the one shipped as the default, e.g. Konqueror on KDE or Epiphany on GNOME.

StopTheFail wrote:So I ask, what is the point of providing a browser that cannot be used by the average user?

On the other hand what would be the point of not shipping a handfull of kilobytes of the Konqueror executable especially since there are user using it?

What would anyone gain by Konqueror not being installed?

StopTheFail wrote:I say, integrate Firefox into KDE in a seamless way, and it turns out much work to this end has already been undertaken by the guys at Suse for which I'm very grateful. I'm sure after a few more years Konqueror, when shifted to Webkit and developed further, will provide another useful alternative, but for the time being that isn't the case, and that is the basic premise behind much of what I've talked about in this thread. To dismiss my posts as the rants of just another "hater noob" that "knows not of what he is speaking" is to be simply shooting the messenger.

Better integration of third party applications is always welcome.
However, the way I read the read is that there are quite some misconceptions about what resources are spent on why they are spent on what they are spent on and the only way not to spent them on that would be to have a viable alternative.

StopTheFail wrote:I do appreciate the time and effort invested in Konqueror, I've used it myself for many years and have simply worked around any of its short-commings with other browsers, but I cannot expect most people to be happy to do the same. When we talk of what a developer or technical user is prepared to do, we can talk of work-arounds and such, but not when talking about the vast majority of users.

I am not sure that there is a lot of work going on in Konqueror right now. As far as I know all respective developers are either working on shared filemanagement code as part of improving Dolphin or working on shared web rendering code as part of improving KHTML.

Once somebody brings up Firefox in such a discussion the focus usually shifts to one usage scenario of a combination of technologies, i.e. Konqueror + KHTML, and people start assuming that if one can replace this combination in that single scenario, the same replacement can be used for all others.

Any attempt to point out the flaw of this simplification is often met with insistance that this single usage scenario is the only one which exists and any alternative can therefore be seen as an universal solution.

Cheers,
_

anda_skoa wrote:They probably don't care about the overhead of maintaining their own fork and WebKit might have been to late for them to consider.

While the maintainence of their integration of Gecko into there environment is certainly not without development cost, I guess they felt it was the lesser of the available evils.

anda_skoa wrote:I was referring to KHTML and WebKits relation in the context of replacing KHTML.
Since it is not even known yet whether it will be possible to build KHTML's API on top of WebKit or whether KHTML needs to remain it is still very more likely that it is easier than to provide KHTML's API on top of Gecko.

It certainly makes sense that given that Webkit is a development of KHTML, it would be easier to integrate Webkit than Gecko, but that would seem to depend on how much Webkit has deviated from the KHTML codebase.

anda_skoa wrote:Nice think with applications is that you can use any of them if one of them fits your needs better.
There are even users on Mac OS X or Windows which use Firefox because they like it better or because of extensions they like, etc.

Would be quite puzzling to find that users of Free Software desktops would only use the one shipped as the default, e.g. Konqueror on KDE or Epiphany on GNOME.

Nothings wrong with shipping Konqueror in the default desktop. But I might add that I never said there was anything wrong with shipping it. My posts relate to Konquerors suitability as a general purpose browser. Konqueror provides other functions other than browsing that many find useful.

anda_skoa wrote:On the other hand what would be the point of not shipping a handfull of kilobytes of the Konqueror executable especially since there are user using it?

What would anyone gain by Konqueror not being installed?

See previouse statement.

anda_skoa wrote:Better integration of third party applications is always welcome.
However, the way I read the read is that there are quite some misconceptions about what resources are spent on why they are spent on what they are spent on and the only way not to spent them on that would be to have a viable alternative.

The basis of my main point would be along the lines of this. That developing, or maintaining the development of a HTML rendering engine would be a bigger task that the integration of somebody elses web renderer. I don't think for one minute think it would be a five minute job, just that it would in the long run be easier than developing and maintain your own renderer.

anda_skoa wrote:I am not sure that there is a lot of work going on in Konqueror right now. As far as I know all respective developers are either working on shared filemanagement code as part of improving Dolphin or working on shared web rendering code as part of improving KHTML.

Once somebody brings up Firefox in such a discussion the focus usually shifts to one usage scenario of a combination of technologies, i.e. Konqueror + KHTML, and people start assuming that if one can replace this combination in that single scenario, the same replacement can be used for all others.

Any attempt to point out the flaw of this simplification is often met with insistance that this single usage scenario is the only one which exists and any alternative can therefore be seen as an universal solution.

Cheers,

Some may over simply in that way, but I don't. But if you say that developing or maintaining the development of your own custom render is an easier task than integrating Gecko, well then I guess that would be where our positions would differ.

If I were doing the integration, it would be my desire to do as a kpart so as to be useful to other apps that need a renderer, not just Konqueror. You seem to be saying that this would make the task fairly impracticable.

StopTheFail wrote:It certainly makes sense that given that Webkit is a development of KHTML, it would be easier to integrate Webkit than Gecko, but that would seem to depend on how much Webkit has deviated from the KHTML codebase.

Exactly.
Since it hasn't been determined yet if replacing KHTML's internals with it WebKit would be feasible any estimate how much effort it would be to do it with Gecko can only be highly speculative.

StopTheFail wrote:Nothings wrong with shipping Konqueror in the default desktop. But I might add that I never said there was anything wrong with shipping it. My posts relate to Konquerors suitability as a general purpose browser. Konqueror provides other functions other than browsing that many find useful.

You wrote

StopTheFail wrote:So I ask, what is the point of providing a browser that cannot be used by the average user?

I interpreted that as the alternative being not to provide Konqueror as a browser.
Which, unless one specifically blacklists web render parts, translates into not providing Konqueror

StopTheFail wrote:The basis of my main point would be along the lines of this. That developing, or maintaining the development of a HTML rendering engine would be a bigger task that the integration of somebody elses web renderer. I don't think for one minute think it would be a five minute job, just that it would in the long run be easier than developing and maintain your own renderer.

I would certainly agree if there were any kind of real world estimates whether it would be technically feasible.
Right now it looks like it is less work to maintain KHTML than to provide and maintain an API, ABI and feature compatible wrapper around an engine maintained by somebody else.

For the purpose of web browser part this is already being worked on.

StopTheFail wrote:Some may over simply in that way, but I don't. But if you say that developing or maintaining the development of your own custom render is an easier task than integrating Gecko, well then I guess that would be where our positions would differ.

I am sorry, but you did over simplify the situation. Not as gross as other often do, but still neglecting development platform issues (you know, inconvenient stuff like API and ABI stability guarantees)

StopTheFail wrote:If I were doing the integration, it would be my desire to do as a kpart so as to be useful to other apps that need a renderer, not just Konqueror. You seem to be saying that this would make the task fairly impracticable.

A kpart should be easy, in fact some people are working on one based on WebKit. Moreover, when somebody claimed that there were KHTML specific portions in Konqueror, Konqueror developers clarified that there weren't.

But then again, the browser case is the easy one.

Since nobody has yet (to my knowledge) attempted to port the KHTML API onto any other engine, so I take it that it would really difficult.

Cheers,
_

anda_skoa wrote:Exactly.
Since it hasn't been determined yet if replacing KHTML's internals with it WebKit would be feasible any estimate how much effort it would be to do it with Gecko can only be highly speculative.

Over time, practices of, and technologies used by web developers change and evolve. Due to this, a renders abilities need to be adjusted over time. Or at least this has been the experience to date. Now if you're saying it's easier to do nothing than to either integrate Webkit or Gecko, then that's surely obvious to anyone. Whether that produces results people are happy with or not may be another story. I would suspect that the state of KHTMLs current rendering accuracy with respect to what most people expect in practice, not just strict compliance with the w3c standards, is not what the KHTML devs are happy with, and will require further development.

Now the situation we have is either they will continue to maintain their own renderer, which takes development resources, or integrate someone elses renderer, which requires development resources. The web doesn't stay still, so neither can a renderer. However, I would think that the code to integrate Gecko would be more a more stable target than what's happening out there on the web.

anda_skoa wrote:

StopTheFail wrote:Nothings wrong with shipping Konqueror in the default desktop. But I might add that I never said there was anything wrong with shipping it. My posts relate to Konquerors suitability as a general purpose browser. Konqueror provides other functions other than browsing that many find useful.

You wrote

StopTheFail wrote:So I ask, what is the point of providing a browser that cannot be used by the average user?

I interpreted that as the alternative being not to provide Konqueror as a browser.
Which, unless one specifically blacklists web render parts, translates into not providing Konqueror

To say that is to ignore the general thrust of what I'm saying.

It would be really useful to the end user, to have Firefox tightly integrated with the desktop as Konqueror isn't at the moment useful for them as a general purpose browser.
It would be better again (at least in the eyes of some) to have Konqueror correctly render and interact well with the web sites used by the general user.

anda_skoa wrote:

StopTheFail wrote:The basis of my main point would be along the lines of this. That developing, or maintaining the development of a HTML rendering engine would be a bigger task that the integration of somebody elses web renderer. I don't think for one minute think it would be a five minute job, just that it would in the long run be easier than developing and maintain your own renderer.

I would certainly agree if there were any kind of real world estimates whether it would be technically feasible.
Right now it looks like it is less work to maintain KHTML than to provide and maintain an API, ABI and feature compatible wrapper around an engine maintained by somebody else.

For the purpose of web browser part this is already being worked on.

StopTheFail wrote:Some may over simply in that way, but I don't. But if you say that developing or maintaining the development of your own custom render is an easier task than integrating Gecko, well then I guess that would be where our positions would differ.

I am sorry, but you did over simplify the situation. Not as gross as other often do, but still neglecting development platform issues (you know, inconvenient stuff like API and ABI stability guarantees)

Of course there are no API/ABI stability guarantees in the interface used by the Gecko engine for the purpose of integration into other projects, so where are the API/ABI guarantees in the KDE codebase? I must of missed them.
I'm not saying the wrapper is a five minute job. Just that once written, is likely to be easier to maintain than the rest of the internet.

You make it sound as though there are no other projects using the Gecko engine. That it's too unstable to be useful to anyone else by Mozilla.

anda_skoa wrote:

StopTheFail wrote:If I were doing the integration, it would be my desire to do as a kpart so as to be useful to other apps that need a renderer, not just Konqueror. You seem to be saying that this would make the task fairly impracticable.

A kpart should be easy, in fact some people are working on one based on WebKit. Moreover, when somebody claimed that there were KHTML specific portions in Konqueror, Konqueror developers clarified that there weren't.

But then again, the browser case is the easy one.

Since nobody has yet (to my knowledge) attempted to port the KHTML API onto any other engine, so I take it that it would really difficult.

Cheers,
_

As you say, and the KDE devs say, and the Konqueror docs say, KHTML is implemented via way of a KPART. Then you infer the lack of Gecko via KPART is proof that it's either technically imposable, or at least infeasible and that's a leap I'm not prepared to make.

StopTheFail wrote:Of course there are no API/ABI stability guarantees in the interface used by the Gecko engine for the purpose of integration into other projects, so where are the API/ABI guarantees in the KDE codebase? I must of missed them.

The KDE development platform (e.g. kdelibs, kdepimlibs) remain API and ABI stable across each major release's lifetime.
Same for Qt, GTK+, and numerous other libraries.

It is basically the only viable way a project can use the libraries produced by another, short of forking to have control over the changes of your own copy.

StopTheFail wrote:I'm not saying the wrapper is a five minute job. Just that once written, is likely to be easier to maintain than the rest of the internet.

My guess is that it would basically be the same effort as writing a whole new engine.
Just have a look at all the classes currently part of the KHTML API
http://api.kde.org/4.x-api/kdelibs-apid ... tated.html

Some of those can probably remain unchanged, but I am pretty that several would have to have their internal replaced.

StopTheFail wrote:You make it sound as though there are no other projects using the Gecko engine. That it's too unstable to be useful to anyone else by Mozilla.

At least I am not aware of any Gecko releases.

StopTheFail wrote:As you say, and the KDE devs say, and the Konqueror docs say, KHTML is implemented via way of a KPART. Then you infer the lack of Gecko via KPART is proof that it's either technically imposable, or at least infeasible and that's a leap I'm not prepared to make.

No. What I am uncertain of is whether all the API beside the KPart interface can be provided on top of a different renderer. Especially on Gecko since involved developers don't even know yet whether it would be possible on WebKit and this one already has a lot of similarities.

Cheers,
_

anda_skoa wrote:The KDE development platform (e.g. kdelibs, kdepimlibs) remain API and ABI stable across each major release's lifetime.
Same for Qt, GTK+, and numerous other libraries.

It is basically the only viable way a project can use the libraries produced by another, short of forking to have control over the changes of your own copy.

But that stability guarantee is only over each major release lifetime. Not forever. I got the feeling you felt that unless the API/ABI stayed static forever, that rendered Gecko such a moving target as to be unusable by any other project other than Firefox or Thunderbird.

anda_skoa wrote:

StopTheFail wrote:I'm not saying the wrapper is a five minute job. Just that once written, is likely to be easier to maintain than the rest of the internet.

My guess is that it would basically be the same effort as writing a whole new engine.
Just have a look at all the classes currently part of the KHTML API
http://api.kde.org/4.x-api/kdelibs-apid ... tated.html

Some of those can probably remain unchanged, but I am pretty that several would have to have their internal replaced.

So it is your position then that, that interface or the Gecko XPCOM interfaces are less stable and are more of a moving target than that of the minutiae of rendering the XHTML documents out there on the whole of the internets.

anda_skoa wrote:

StopTheFail wrote:You make it sound as though there are no other projects using the Gecko engine. That it's too unstable to be useful to anyone else by Mozilla.

At least I am not aware of any Gecko releases.

As Gecko is used by projects such as Fennec, Songbird, Moblin, OLPC's Sugar, Camino, Picassa, Flock, K-Melon, and Lunascape (which also uses Webkit and Trident as well), I guess there is hope for other projects out there as well.

anda_skoa wrote:

StopTheFail wrote:As you say, and the KDE devs say, and the Konqueror docs say, KHTML is implemented via way of a KPART. Then you infer the lack of Gecko via KPART is proof that it's either technically imposable, or at least infeasible and that's a leap I'm not prepared to make.

No. What I am uncertain of is whether all the API beside the KPart interface can be provided on top of a different renderer. Especially on Gecko since involved developers don't even know yet whether it would be possible on WebKit and this one already has a lot of similarities.

Cheers,
_

Well if we're stuck with KHTML well I guess there's no hope then is there?

StopTheFail wrote:But that stability guarantee is only over each major release lifetime. Not forever.
I got the feeling you felt that unless the API/ABI stayed static forever, that rendered Gecko such a moving target as to be unusable by any other project other than Firefox or Thunderbird.

API/ABI stability, at least for some time (preferably a long time), greatly improves the viability for basing work on it.
Just as a comparison, what is the API/ABI stability timeframe for libgecko (or whatever it is called as a library)?

StopTheFail wrote:

anda_skoa wrote:

StopTheFail wrote:I'm not saying the wrapper is a five minute job. Just that once written, is likely to be easier to maintain than the rest of the internet.

My guess is that it would basically be the same effort as writing a whole new engine.
Just have a look at all the classes currently part of the KHTML API
http://api.kde.org/4.x-api/kdelibs-apid ... tated.html

Some of those can probably remain unchanged, but I am pretty that several would have to have their internal replaced.

So it is your position then that, that interface or the Gecko XPCOM interfaces are less stable and are more of a moving target than that of the minutiae of rendering the XHTML documents out there on the whole of the internets.

I am afraid I don't understand this sentence. What does either the KHTML API or Gecko's XPCOM interface have to do with XHTML documents on the Internet?
Maybe it just does not belong to the part you quoted but to some other section?

StopTheFail wrote:

anda_skoa wrote:At least I am not aware of any Gecko releases.

As Gecko is used by projects such as Fennec, Songbird, Moblin, OLPC's Sugar, Camino, Picassa, Flock, K-Melon, and Lunascape (which also uses Webkit and Trident as well), I guess there is hope for other projects out there as well.

So they do releases of the engine now? Do you have an URL of a release announcement or project website?

StopTheFail wrote:

anda_skoa wrote:

StopTheFail wrote:As you say, and the KDE devs say, and the Konqueror docs say, KHTML is implemented via way of a KPART. Then you infer the lack of Gecko via KPART is proof that it's either technically imposable, or at least infeasible and that's a leap I'm not prepared to make.

No. What I am uncertain of is whether all the API beside the KPart interface can be provided on top of a different renderer. Especially on Gecko since involved developers don't even know yet whether it would be possible on WebKit and this one already has a lot of similarities.

Well if we're stuck with KHTML well I guess there's no hope then is there?

I am afraid that I don't understand this sentence either. Again especially in the context of the quoted paragraphs you added it to.

Cheers,
_

Perhaps I can clarify by stating what the bottom line is as I see it. If I want to avoid having to use multiple browsers depending on the particular website I wish to visit, I need to use Firefox.

If I want to use Konqueror due to its superior KDE integration but with the sure fire support for the web that Firefox has, then too bad for me. I need to wait for Konqueror to be updated.

If we assume that it's a worthwhile enough pursuit to make Konqueror a viable alternative to Firefox, then something needs to be done to make it so. I guess then the choices to be faced are something along the lines of:

either

• Update KHTML to work successfully with web sites/web apps as per Firefox

or

• Integrate a better functioning engine.
  
  • Webkit
    
  • Gecko
    
  • (My choice would be Gecko as it works with the most sites, but would settle for Webkit.)

All of this is obvious, as we have discussed. I guess our differences could be summarised as follows.

My guide as to which path to take would be something like:

Is it easier, and in the long run, more productive to update KHTML or integrate another engine?

You, or at least the devs feel that at the moment it's easier or more productive to update KHTML

I on the other hand feel it's better to integrate another engine.

Your position makes sense if the following are true;
it takes more work long term to;

• Have to keep making changes to "KGecko", as Mozilla can't keep their hands off the API/ABI for Gecko.
  
• That work on "KGecko" integration consumes more developer resources than having to perpetually keep updating KHTML in order to successfully interoperate with whatever XHTML/Ajax/Plugins the world throw at us.

My position makes sense if the following are true;

• The initial developer resources required to develop "KGecko" pale into comparison when put up against perpetually having to keep updating KHTML in order to successfully interoperate with whatever XHTML/Ajax/Plugins the world throws at us.

Some guiding information that I am aware of that informs my position on this;

• Previous integration of Gecko into Konqueror - Unfortuantely, has been dropped in the past.
  
• The work on "xPart" - A project to enable integration of "non in-process", independent apps as KParts.
  
• The use of Gecko in many projects independent of Mozilla, which suggests to me that it's API/ABI are not so unstable as to require constant re-factoring of code to work with it.
  
• Also, statements made by Mozilla developers to the effect that they are aware of the needs of other independant projects using their work, and need to be mindful of this as the move Gecko forward.

Some notes along the time line of KDE with respect to Gecko integration I've come accross.

• 2003 - Severel references to Gecko in Konqueror for Mandrake
  
• 2004 - Gecko made into a component that can be used by other KDE Apps
  
• 2005 - Several other, unassociated references by a few independant sources to Gecko availability in Konqueror
  
• 2005 - From aKademy - Gecko can be embedded into Konqueror, Dirk Mueller was payed to port Firefox to QT
  
• 2007 - The Gecko KPart has been abandoned. (sadly)
  
• 2008 - Talk about Mozilla-qt - I believe this is at least partially motivated by the needs of Nokia's Meamo platform.

Of course it shoud be easier (no neccessarily better) to integrate Webkit into a KPart because of QtWebkit.

I believe the current line of the devs is to update KHTML and backport what the can from Webkit. I assume this isn't going to change in the near future, and am resigned to the fact that I need to stay standardised on Firefox.

StopTheFail wrote:If we assume that it's a worthwhile enough pursuit to make Konqueror a viable alternative to Firefox, then something needs to be done to make it so. I guess then the choices to be faced are something along the lines of:

either

• Update KHTML to work successfully with web sites/web apps as per Firefox

or

• Integrate a better functioning engine.
  
  • Webkit
    
  • Gecko
    
  • (My choice would be Gecko as it works with the most sites, but would settle for Webkit.)

As far as Konqueror is concerned, this is a good summary.

StopTheFail wrote:All of this is obvious, as we have discussed. I guess our differences could be summarised as follows.

My guide as to which path to take would be something like:

Is it easier, and in the long run, more productive to update KHTML or integrate another engine?

You, or at least the devs feel that at the moment it's easier or more productive to update KHTML

I on the other hand feel it's better to integrate another engine.

No. As I tried to explain, focusing on web browsing in Konqueror makes one miss the big picture.
Because when doing that it really looks like an "either/or" choice.

Once the scope includes KHTML as part of the KDE development platform, it is an "and" choice, meaning the project has to spend resources on maintaining KHTML at least as part of the platform while also spend resources on some other engine as an alternative web browser component.

It would be an "either/or" choice if building KHTML's API on top of a different engine would be feasible, which has not yet even determined to be true for WebKit despite its similarities.
Thus my assumption that it would be harder to do it with an engine of totally different architecture/design.

StopTheFail wrote:Of course it shoud be easier (no neccessarily better) to integrate Webkit into a KPart because of QtWebkit.

Which is why this is being worked on instead of trying another attempt to use Gecko.

StopTheFail wrote:I believe the current line of the devs is to update KHTML and backport what the can from Webkit.

As far as I understand this is correct. Nessesary due to platform requirements, complemented by additional work on QtWebKit to make it better integrated with KDE.

Cheers,
_

anda_skoa wrote:It would be an "either/or" choice if building KHTML's API on top of a different engine would be feasible, which has not yet even determined to be true for WebKit despite its similarities.

I believe Simon Hausmann, Lars Knol and Matthias Ettrich did some work in the past with respect to integrating non KPart friendly software as a KPart.

anda_skoa wrote:Which is why this is being worked on instead of trying another attempt to use Gecko.

The easy way isn't always the best way though, but we should probably consider ourselves lucky if we at least get Webkit if not Gecko.

anda_skoa wrote:Once the scope includes KHTML as part of the KDE development platform, it is an "and" choice, meaning the project has to spend resources on maintaining KHTML at least as part of the platform while also spend resources on some other engine as an alternative web browser component.

In my previous post, I was describing the situation as I see it based on the premise of "KGecko" being a Gecko based KPart.

I believe the 'and' choice is dependent on whether it's impossible or not to create a KPart for the text/HTML mime type based on Gecko or Webkit.

Due to previous work done on this, I believe the "proof-of-concept" has been established, but without the will of someone to keep it going, has fallen by the way-side.

StopTheFail wrote:I believe Simon Hausmann, Lars Knol and Matthias Ettrich did some work in the past with respect to integrating non KPart friendly software as a KPart.

I am repeating myself, but the kpart is not the problem. This is rather obvious since there is one being worked on for WebKit.
Again, the hard part is KHTML as a library, and again, nobody has yet determined how much work it would be to build a compatible replacement based on the code of a different engine.

StopTheFail wrote:In my previous post, I was describing the situation as I see it based on the premise of "KGecko" being a Gecko based KPart.

I believe the 'and' choice is dependent on whether it's impossible or not to create a KPart for the text/HTML mime type based on Gecko or Webkit.

I know it is probably impossible to explain this in a way it can be universally understood, but let me again try to emphasise that the KPart interface is one portion of what KHTML provides.
It is the one which can most easily be provied by something else, so simplifying the situation to that concept only makes it look like an "either/or" choice.

Unfortunately the devil's in the details and the KPart interface of a different engine alone will not allow a stop of maintenance of KHTML's code base.
Which makes any effort of creating a WebKit kpart of Gecko kpart an additional project, orthogonal to the needs to working on KHTML.

StopTheFail wrote:Due to previous work done on this, I believe the "proof-of-concept" has been established, but without the will of someone to keep it going, has fallen by the way-side.

This is probably referring to the Gecko integration, but just to be sure I'll repeat that some developers are working on WebKit related integration right now.
As a KPart obviously, no one has (to my knowledge) yet started to work on reimplementing KHTML's API on top of another code base.

Cheers,
_

anda_skoa wrote:I am repeating myself, but the kpart is not the problem. This is rather obvious since there is one being worked on for WebKit.
Again, the hard part is KHTML as a library, and again, nobody has yet determined how much work it would be to build a compatible replacement based on the code of a different engine.

anda_skoa wrote:I know it is probably impossible to explain this in a way it can be universally understood, but let me again try to emphasise that the KPart interface is one portion of what KHTML provides.
It is the one which can most easily be provied by something else, so simplifying the situation to that concept only makes it look like an "either/or" choice.

Unfortunately the devil's in the details and the KPart interface of a different engine alone will not allow a stop of maintenance of KHTML's code base.
Which makes any effort of creating a WebKit kpart of Gecko kpart an additional project, orthogonal to the needs to working on KHTML.

But surely it is assumed that to move to another engine, you must support all public facing interfaces to the old engine with whatever mechanisms are required. For somethings that would be a KPart, and for anything using the KHTML interfaces directly, a wrapper.

StopTheFail wrote:But surely it is assumed that to move to another engine, you must support all public facing interfaces to the old engine with whatever mechanisms are required. For somethings that would be a KPart, and for anything using the KHTML interfaces directly, a wrapper.

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,
_