218

Let's compare three strategies:
1. Take Firefox and create a Qt-Port. You'll have huge problems and it's very uninteresting to develop such a port. It's not possible to port all new features of Firefox instantly.
2. Take a new basic browser like Arora, then add the Firefox-features sequentially. This browser will never have the same features like Firefox. The development will always be too slow.
3. Take an old browser with very flexible and intelligent concepts and sometimes even better features than in Firefox. Then use those concepts to enlarge the power and care about some details (for example bookmarks or JavaScript-Engine). You'll get a very usable browser with better features than Firefox.

Don't throw KParts, KIO and KParts-Plugins away for a mediocre browser!

The User wrote:Don't throw KParts, KIO and KParts-Plugins away for a mediocre browser!

KParts and KIO are technologies used by a lot of KDE applications and won't be dumped. It's just that in Konqueror the usage of them is very visible, so it's often mentioned as the prime example.
In other applications users don't notice the work of KIO and KParts - they just work. And that's exactly the way it should be.

And I don't consider JS-performance and bookmark-management "details" of a webbrowser. These are very basic functions for such an application. If Konqueror doesn't improve a lot in these areas it is fair to replace it with something more usable. That doesn't mean that it's dumped completely - it could live on in extragear and still be used as a technology-demo or by powerusers.

In KDE 3.x, Konqueror was my favorite file-manager, I really loved it! I was very sceptical about Dolphin, but soon found out that it does the job even better than Konqueror.
That's why I think a dedicated webbrowser is quite a good idea...

Look at other ideas:
Somebody suggested to create a KPart-Mozilla-Plugin to view PDFs etc.
But in this thread many people say: Hey, let's create a web-browser without those features.

(I don't understand your bookmarking problem, it works fine for me)

Arora will never reach Firefox, Konqueror could be a browser wich is sometimes better and sometimes worse than Firefox.

My idea:
Create a Konqueror Todo-List and let's build groups working on it.

PS:
Are there any results which parts of KJS are slow? Lexer, Parser, Bytecode-Generator, Bytecode-Interpreter? Is there a good Bytecode-Cache?

The User wrote:Arora will never reach Firefox, Konqueror could be a browser wich is sometimes better and sometimes worse than Firefox.

Why? Can you give some arguments?

Because Konqueror has non-mainframe-features.
Arora and Reqonk are trying to become conservative browsers by adding Firefox' features step by step. But the development of Firefox is of course faster.
Konqueror's modular concept makes it sometimes better than Firefox. When you think that Konqueror doesn't have enough basic-functionality, these issues should be fixed but this doesn't make KParts-usage etc. bad. And remember that Konqueror has still better basic web-browsing features than Arora and Rekonq.

Please also read my post on the top of this page...

The User

The User wrote:Because Konqueror has non-mainframe-features.
Arora and Reqonk are trying to become conservative browsers by adding Firefox' features step by step. But the development of Firefox is of course faster.
Konqueror's modular concept makes it sometimes better than Firefox. When you think that Konqueror doesn't have enough basic-functionality, these issues should be fixed but this doesn't make KParts-usage etc. bad. And remember that Konqueror has still better basic web-browsing features than Arora and Rekonq.

Please also read my post on the top of this page...

The User

This thread isn't about dumping Konqueror, its about dumping KHTML.

It will never be popular enough that web designers are testing against it. It will always be behind other engines.

pembo13 wrote:This thread isn't about dumping Konqueror, its about dumping KHTML.

It will never be popular enough that web designers are testing against it. It will always be behind other engines.

Sadly, you have point. gmail, FCKeditor is just 'some' web apps who rejects to work with Konqueror. I don't know, if it is juts because they didn't tested and add browser agent filer, or Konqueror is really incapable, but its enough for daily user to dump Konqueror...

Wasn't there a GSoC project making KJS support more scripts?

It's simply impossible to dump everything. We need concrete and implementable ideas. Arora is a very bad idea, because it doesn't rely on existing technology. Look at Kopete, Konversation and Quassel. All try to implement IRC but all have problems. It could be the same with Konqueror, Rekonq and Arora.

Of course it would be great to merge KHTML and WebKit, but are there ideas, how to do it?

I think a button to report pages which doesn't work (especially JS-issues, sometimes JS-events doesn't work properly etc.) would be very useful.

First off all KHTML, I have't seen any results about KHTML and html5 and css3 capability. If KHTML is going to be able to follow up all these technologies (having in mind, that html5 official spec is not yet released, but it is starting bo be used by many web developers), including video, geolocation native support (no more embed) etc.

http://techbase.kde.org/Projects/KHTML

I think somebody who really understands KHTML (=KHTML-developer) should say something about the situation.

KHTML has also good sides:
-uses KDE widgets
-good access via C++ (important for KWallet)

The User wrote:Wasn't there a GSoC project making KJS support more scripts?
because it doesn't rely on existing technology

That statement makes no sense. How can a piece of software that exists today not rely on existing technology.

The User wrote:Of course it would be great to merge KHTML and WebKit, but are there ideas, how to do it?

The KHTML guys apparently aren't interested in that, if they were, they would have done so already as they are the ones in the best position to do so.

The User wrote:I think a button to report pages which doesn't work

That would be one depressing solution, and only a partial one as developers still won't be targeting KHTML.

The User wrote: (especially JS-issues, sometimes JS-events doesn't work properly etc.) would be very useful.

It may be useful, but I don't see how it would be very useful. You'd still be just putting you fingers in holes in a dyke as they open up.

Well, forget the because-clause, I think I was tired and I've forgotten to remove this sub-sentence.

Well, IMO KDE should drop KHTML and switch to fast and glitch-less WebKit as soon as possible (KHTML is deprecated by now: it renders pages even slower than Gecko...)

@SkyBon: Due to KDELibs Binary Compatibility policies it is not possible to remove KHTML, and therefore KDE applications are more likely to use it over Webkit, especially since they do not have to do things such as KDE integration themselves.

Konqueror has a qtwebkit that you can use instead of KHTML
just install the qt webkit in your distro restart konqueror
and choose Viiew>View Mode > Webkit
Though for me Webkit can die I stay with KHTML its ours and better implemented with KDE to my taste