218

The User wrote:Konqueror is a great application.
Why should we give it up?
Rekonq is a new application, not perfect.
Rekonq has two essential features (the otherones are uninteresting):
-Webkit (which is integrated in Konqueror)
-Tabs in seperate processes
How could we bring the second feature to Konqueror?
By modifying KParts: There could be an option for KParts to open the program in a new process.

So there would be all nice rekonq-features in Konqueror.
Rekonq does not provide all the great Konqueror-Features:
-display PDF, PS etc.
-Konqueror-Addons
-FTP, SSH, file...
-service-menus

I think adding the feature to KPart would be the easiest good solution for the performance-issue. The rendering-issue is already solved by WebKit-Part as an alternative to KHTML .
But there is still work to make Konqueror the best browser in the world: there aren't such great Addons like in Firefox. (e.g. Firebug, Add to Searchbar or iMacros.

The User

Who said give it up, also another reason why I like Rekonq is because of how simple it is. That is a feature in my book, with Konq there is all these unneeded features because of it being a file-browser. Kinda why there is dolphin now, to appeal to the lesser audience who doesn't need all them features.

I don't use dolphin, too.
But the file-managing-components of Dolphin and Konqueror work together.
rekonq and Konqueror does not really work together.
I think a Konqueror without file-managing would be still a better Web-Browser than rekonq and there would not be the double maintainance.

The User wrote:Rekonq has two essential features (the otherones are uninteresting):
-Webkit (which is integrated in Konqueror)
-Tabs in seperate processes

I'd say one more: since it's "only" a web-browser the interface is more straight-forward. Konqueror can be quite bewildering the first time you use it - and especially if the user thought it was just a webbrowser.

The User wrote:Rekonq does not provide all the great Konqueror-Features:
-display PDF, PS etc.
-Konqueror-Addons
-FTP, SSH, file...
-service-menus

The first one will probably happen given enough time, since Konqueror only uses kparts for that I'd guess it's bound to happen for any other KDE-browser as well.

As for the rest...no, rekonq doesn't have those and shouldn't either. As far as I can tell, rekonq kinda fills a niche. Traditionally, Konqueror was both file-manager and browser (in KDE3). Now Dolphin has, for many people, taken over the file-manager part. Konqueror is still available for those that like the one-tool-to-rule-them-all idea. Why wouldn't the same happen if there was a dedicated web-browser as well? And a dedicated browser would, imo, be much more newbie-friendly.

Besides, for file-viewing purposes dolphin and konqueror share a lot of code and kparts (if I've understood it correctly). Konqueror and rekonq (or some other browser) could do the same, so an improvement in one would mean an improvement in the other.

The User wrote:I think adding the feature to KPart would be the easiest good solution for the performance-issue. The rendering-issue is already solved by WebKit-Part as an alternative to KHTML .

I don't see much of a difference rendering-wise between the two to be honest.

Kryten2X4B wrote:Why wouldn't the same happen if there was a dedicated web-browser as well? And a dedicated browser would, imo, be much more newbie-friendly.

Besides, for file-viewing purposes dolphin and konqueror share a lot of code and kparts (if I've understood it correctly). Konqueror and rekonq (or some other browser) could do the same, so an improvement in one would mean an improvement in the other.

A rekonq-KPart should not use his own tabs. That should be managed via Konqueror.

Kryten2X4B wrote:I don't see much of a difference rendering-wise between the two to be honest.

I have said, it is solved, so it is unimportant.

Tell me: What are the features of rekonq you are missing in Konqueror?
I know, the simplicity. But you could get simplicity by removing Konqueror-features (like for Dolphin). That would be easier than merging Konqueror and rekonq. If there is no other relevant aspect, it would not be useful to merge them.
(I'm not a rekonq expert. If there are really nice features, tell me about them!)

The User

The User wrote:A rekonq-KPart should not use his own tabs. That should be managed via Konqueror.

Well, I wasn't thinking about tabs specifically. More like things like firefox-like extensions as just one example that could be implemented browser-independent so to speak, and just let Konqueror and/or rekonq and possibly others to use if they chose to.

The User wrote:Tell me: What are the features of rekonq you are missing in Konqueror?
I know, the simplicity. But you could get simplicity by removing Konqueror-features (like for Dolphin). That would be easier than merging Konqueror and rekonq. If there is no other relevant aspect, it would not be useful to merge them.

I'm not an expert on it either. I've just experimented with it. I haven't performed any measurement tests, but at first glance it's faster. Other than that, _I_ am not missing anything in Konqueror (maybe a firefox extension or two...). I'm just trying to view it from the eyes of a newbie. Although admittedly it's less confusing now-a-days when clicking on a local file no longer (by default that is) just opens a webpage in a sidebar.

Some FF-Extensions would be great in Konqueror.
For those people who don't like the "all in one" a browser-only-tool would be possible.
But i think that a small Konqueror-version would be better maintanable than a rekonq-konqueror-merge.

The User wrote:But i think that a small Konqueror-version would be better maintanable than a rekonq-konqueror-merge.

Who said anything of a merge?

The User wrote:Some FF-Extensions would be great in Konqueror.
For those people who don't like the "all in one" a browser-only-tool would be possible.
But i think that a small Konqueror-version would be better maintanable than a rekonq-konqueror-merge.

I would like to see a plasma plug-in for Konqueror just as there is in Amarok (I'm repeating myself ).
This would be the best thing ever. And I believe that in the long run it will be done, that's why in KDE4.3 there won't be plasmarc any more but plasma-desktoprc and plasma-apprc.

@Krysten
Who said anything about a merge?
You. You spoke about to make rekonq an independent app integrated into Konqueror like Dolphin.

The User wrote:You. You spoke about to make rekonq an independent app integrated into Konqueror like Dolphin.

That's not what I meant. What I meant was:

1. Keep Konqueror as-is (that is, capable of both web-browsing and file-management).
2. Introduce a browser-only, whether rekonq or something else.

Naturally, some features would be useful to both. Say the ad-block technology Konqueror uses. I don't know how that is implemented today, but what I was suggesting was that both Konqueror and the new browser should be able to use the same technology. That is, if the adblock part is updated both Konqueror and Rekonq would benefit. Much like Konqueror today uses the dolphin kpart when used as a filebrowser.

To conclude, the three apps (konqueror, dolphin, rekonq) would be very modular and only use the KDE-components needed for their intended use-cases.

Is that clearer?

That's what I have meaned with "merging".
I think it would be okay to have an additional "browser only", but I'm unsure, if rekonq is a real candidate.
rekonq:
-uses its own tabs, for Konqueror-integration this is problematical
-has subprocesses for each tab (crash-safety)
-uses WebKit
When you want to have a small browser there are two ways:
First:
-Create better compatibility between rekonq and Konqueror (tabs, multi-processing, other KParts like Okular)
-Integrate important Webbrowsing features of Konqueror into rekonq
Second:
-Create a new light-weight Konqueror-based web-browser
-The technologies of this browser and Konqueror would automatically belong together
-Maybe use some good parts of rekonq, e.g. the sub-processes (maybe sub-processing-support in KParts)

I would prefer the second option. But there is the question:
Which features should be removed to get a light-weight-browser?
Should kio_file be removed? Firefox also support file://.
Should kio_ftp be removed? FTP is quite useful for webbrowsers.
All the extra-features like the Konsole? I think the Konsole is just a module.

Edit:
I think this thread is very confusing. There are these ideas:
-WebKit in Konqueror
-Gecko in Konqueror
-A new light-weight-webbrowser
-A Plasma-based interface for Konqueror
-Firefox-Addons in Konqueror

I'm definitely on favour of WebKit. There isn't one reason to keep using KHTML as default (as in KDE 4.3, actually, it has more to do with Qt 4.5, if you compile 4.2 with the newest Qt it will work well too). Why?

1.- It's a waste of effort. Apple, GNOME, OpenMoko, Google, Nokia, Symbian, and many other companies are supporting Webkit, there is no reason to waste human resources on KHTML.
2.- It's faster than KHTML.

3.- It renders (correctly) a lot more websites.

4.- It's similar to KHTML code wise, so it shouldn't be hard for KDE devs to start working on it.

5.-It's already integrated on Qt 4.5 and works amazingly well with KDE.

6.-It will keep improving.

Devs and some people is attached to KHTML because:

1.- They hate apple.
2.- They are extremely irrational and mulish. It's their baby, so they can't let it die.

-------------

Also, Konqueror is good (I'm not saying kill konqueror), however, it shouldn't be default for web browsing, just like it isn't for file management. The interface is pretty cluttered (open an image, and then tell me it isn't, or just look at the default toolbar, and the configuration menus OMG), it has a clumsy, confusing (Joe downloaded a document, he selected "open", and it opens inside Konqueror, he can't edit the document, he's extremely annoyed) behaviour.

Something like Rekonq as default would be a much more sane default (just like Dolphin is).

I wouldn't agree with 2 and 3.
I have both webkit and KHTML and tried both for most of webpages that I use. And came to realise that for now KHTML is still better than qtWebKit.

KHTML is a great project and need to continue.

But it would be nice if KDE let us chose our favorite engine : KHTML, Gecko or WebKit... and then the applications would adapt themselves using the engine the user chosed.

Actually KHTML is getting better and better (the 87/100 on the Acid3 test just heat my hearth), involved performance, SVG support... less bugs also. Now we can navigate the whole web without any issues (assuming the websites code is clean).
But using KHTML or not should be an user choice, even in KDE himself. And making KDE able to use his own engine and the Gecko and WebKit engine would be a great thing for both KDE and KDE users.

My two cents:
kross scripting + kgethotnewstuff and webkit engine would make an awesome browser. If this is going to be arora, rekonq, konqueror or something else isn't important for me.

I also tried out arora and I found that arora works better and faster compared with konqueror. Have a look at this site (any d&d gamers out there?): http://www.pathguy.com/fr.htm
Konqueror's java script performance is so bad you can hardly use it. In Arora this site just works with reasonable speed.