So, I just contributed to "grave" konqueror bug (Bug #154060) which has been open since 2007 (kde4.0). This is but one of my disappointments with konqueror that further makes my original point. In fact, this particular bug has me considering whether or not to drop konqueror altogether as my browser of choice. Though, I'm not quite there yet. As a side note - Based on the lack of activity on this thread, I have to assume either that this isn't an effective forum for raising these concerns or else nobody else really cares. Maybe the entire KDE world is using FF or Chrome already.

Just a few questions for any interested Konqueror developers...

- Is KHTML (or WebKit) the right rendering engine for the future?
- Can it keep up with the growing demands of the Web?
- If so, why then the heavy site incompatibilities?
- If not, what are the next generation plans?
- What about the Konqueror components (e.g. HTTPS support, etc)?

These are all very valid questions that are, no doubt, discussed quite routinely in Konqueror inner-development circles. As an end user, however, the direction of Konqueror is quite unclear and the current state, unsettling. Is there any interest, either in the user community or among developers to advance Konqueror in any notable way?

fcwells59 wrote:Just a few questions for any interested Konqueror developers...

- Is KHTML (or WebKit) the right rendering engine for the future?
- Can it keep up with the growing demands of the Web?
...
- If not, what are the next generation plans?

This depends on the (development) effort that's put into it, which seems to be picking up quite a bit in the last month (see other thread about The State of KHTML in KDE4.4), so the future is looking a lot brighter for KHTML.

- If so, why then the heavy site incompatibilities?

I don't know if 'heavy' is the correct term. I've experienced occasional incompatibilities and reduced functionality because KHTML is a second-class citizen in an IE+FireFox+Safari world. Apparently there has been a lot of effort recently to reduce the incompatibilities.

These are all very valid questions that are, no doubt, discussed quite routinely in Konqueror inner-development circles. As an end user, however, the direction of Konqueror is quite unclear and the current state, unsettling. Is there any interest, either in the user community or among developers to advance Konqueror in any notable way?

Well, the community is pretty well divided with some saying drop Konq/KHTML and just use FireFox or a webkit-based browser, some saying use WebKit in Konqueror and some saying advance Konq/KHTML. The developers seem to be strong supporters of advancing Konq/KHTML, as evidenced by the recent surge of commits to KHTML. KHTML is a fairly tightly-integrated component of KDE and Konqueror is KDE's web browser (that also does file browsing/previewing, etc. as it always has). IMO, I would love to see Konqueror emerge as a 1st class citizen in the web. I would love to be able to use only KDE apps on my KDE desktop and being able to drop Firefox (and Chrome) entirely for Konqueror would be another step towards that goal.

On the site incompatibility point. I agree that Konq does fairly well, but it's misses in one way or another on a lot of the sites I visit. Facebook is one good example of an incredibly popular site that Konq does really poorly with. In fact, it even (sadly) struggles with KDE.ORG occasionally. I recognize that this is a really tough battle - considering that the web is predominantly built for IE - but FF and Chrome somehow seem to manage rather well, as I point out in my opening post (albeit, they have huge resources to throw at it). And KHTML rendering isn't the only issue. HTTPS/SSL support struggles; theme support non-existent and may never be planned, etc.

Thus, it seems KDE needs to once and for all make the tough decision whether or not to let Konq go. I, for one, would like to keep it. I have remained loyal to Konq throughout the majority of it's life.

As IE is to Windows, Konq presently is to KDE. Sure, the KDE user community can probably survive without it, but its integration and other powerful features would be a sad and substantial loss.

I'm new to KDE. I'm an avid Firefox user. But Firefox (or Iceweasel) is GTK+ based and I'm a bit of a purist so I would like to use a Qt-based browser. Konqueror has potential to be that but will it be as quick once all the bells and whistles are loaded? I admit I don't understand the KHTML -vs.- WebKit stuff. I wouldn't mind a Qt-based "Firefox" or Opera or Chrome or ... but making my Firefox icons look more KDE while the underpinnings are still GTK+ are of no real interest to me as it is all window dressing.

I've used Gnome for years. I make no promises about defending Gnome or KDE or Xfce or whatever. Likewise Konqueror, Firefox... But one thing I've learned in life is you have to be true to yourself. With a few exceptions, of course, by and large this attitude is rampant within the Linux community and I encourage that to continue here.

HunkirDowne: Being new to KDE, you may not realize how central Konqueror has always been to KDE technology (see my opening post to this thread). Although the KDE desktop continues to mature and evolve quite nicely, Konqueror not so much - at least on the browser front. Hence my (possibly sole) disappointment and this call to action.

The notion of attempting to integrate other browsers as others have suggested here, while not entirely unattractive on some levels, doesn't address the key Konqueror issue. Nor do I think such an approach can effectively be maintained long term. The goals and objectives of KDE vs those of the browser du-jour (FF, Chrome, Iceweasel, Opera, etc) I believe will simply always be misaligned.

My own personal opinion is that Konq must either remain and be enhanced if KDE is to ever reclaim any substantial desktop share or be dropped altogether. The latter would require Dolphin to assume the many powerful features otherwise lost. Leaving things in their current state gives the KDE desktop a serious dis-integrated and un-polished appearance in my view that only contributes to heavy KDE disregard. As a long and loyal KDE user, this is a hard pill to swallow.

subscribed

@Dimitrios: You can subscribe to a topic by using the link at the bottom of the page. It's under the "Who is online?" field and the line above "Powered by phpBB..." text. Please use this the next time.

i could nt found it, i think is not in the right place as i thought that there is only the Powered by phpbb details

sorry for that

I hear there is currently word around the devs to replace Konq with Rekonq...though bear in mind even the developers of Rekonq are saying that it isn't fit for purpose.

As for me...I'm using Chrome now...yes, yes, it's gtk+ again, but at least it actually WORKS without much hassle...

I'm going to recant what I said here before... I've tried Dolphin for a few weeks and decided it sucks.

never mind

about webkit, i use some times chrome and there are many times that it cant displays dropdown box menus in very important sites (administrations, public services etc) . With konqueror i never had this kind of problems. Personaly i dont think that the solution would be the switch to webkit, but the improvement of kjs

Hello fcwells59,

I am using Konqueror 4.6, Qt 4.7.0 under the KDE 4.6 platform.

fcwells59 wrote:Konqueror certainly doesn't lack features.

Konqueror 4.6 lacks a print preview feature. Bug #258634
Konqueror 4.6 lacks one or 2 web authoring debuggers.
Konqueror 4.6 lacks a good bookmarks management.
Konqueror 4.6 lacks advanced print features (scaling, paper size, priting selection, printing frame).
Konqueror 4.6 lacks support for CSS 2.1 page media.
Konqueror 4.6 has a bunch of reproducible crash bugs (Bug #237652, Bug #262697, Bug #264985, etc.) and reproducible hang bugs (Bug #247033) which are very serious bugs.

fcwells59 wrote:too many sites just don't render properly with Konqueror. Users don't understand why, nor do they care.

Some sites will not render like other browsers: after examination of HTML/CSS/DHTML code involved and specifications involved, I often (not always!) reached the conclusion that Konqueror was rendering correctly the code.

Users may not understand why and they may also care about it.

fcwells59 wrote:They just want it to work. Blaming the web sites for standards non-compliance is pointless and non-productive.

I disagree. Standards compliance and validity are the cornerstones of interoperability on the web. The first blame to give would be to web authors when they do not write their webpages with valid code (HTML code and CSS code).
Validation explanations

fcwells59 wrote:Somehow Firefox and IE manage to get beyond this debate

This is simply not true: HTML code well-formedness, validity and compliance of code still determine, decide in those browsers (IE8+, Firefox 3+).

Firefox has been able to also report HMTL4 validation errors thanks to Marc Gueury's HTML validator add-on extension, and this, since Firefox 2. Since Firefox 1.5, CSS errors are by default being reported in Firefox Error console.

In backward-compatible "quirks" rendering mode, webpages with errors can be rendered in various ways, in impredictable manners.

fcwells59 wrote:Konqueror's developers should set aside the standards debate

Developers of other browsers are not setting aside the web standards. They try to make their browser comply accurately with standards.

fcwells59 wrote:re-engineer Konqueror's Web Browser to meet the browse-ability needs of today's Web

Many times, other browsers are wrong and incorrect. I could enumerate a long list of testcases backing up my claims here.

IMO, what Konqueror needs and requires here and now is donation$ and community involvement.

Gérard Talbot

Is still alive khtml ?
http://khtml-konqueror.blogspot.fr/