Love for Konqueror

[Dāvis Mosāns]

2015-09-06 13:27 GMT+03:00 David Faure <faure at kde.org>:
> (redirecting to kfm-devel where konqueror development used to happen)
>
> On Tuesday 09 December 2014 21:10:01 Martin Steigerwald wrote:
>> Hi!
>>
>> I see some discussion in the thread "Re: Is Konqueror still a live project?",
>> which seems to be incomplete in my kmail devel-ml folder tough, but it doesn´t
>> seem it came to any conclusion.
>>
>> I am posting as a user who reports bug, helped with a little performance
>> optimization work and CRM114 spamfilter configuration for KMail and builds some
>> stuff to help testing and to make it short:
>>
>> I miss an updated Konqi. I mean the Konqueror webbrowser.
>>
>> I used it often but I use it less and less as it has various problems:
>>
>> - websites not rendering correctly with KHTML
>>
>> - Strg + / - zoom not working for Webkit (thats why I have it at KHTML to
>> resize websites quickly in Akregator)
>>
>> - Issues with SSL/TLS certificate handling (on certain sites I get asked about
>> certifictate from fbstatic.com or so, seems sites who link to facebook stuff, I
>> tried accepting the cert or disallowing it but I get this again and again)
>>
>>
>> Alternatives all have their weaknesses.
>>
>> - Iceweasel / Firefox: I just look at the GTK file dialog box it uses and I am
>> done with it (sorry, to be honest: One of the worst usability nightmares
>> *ever*). Or that you cannot search cookie exception rules. And integration
>> issues with KDE here and there. I know people tried making KDE integration,
>> but it is not readily available in Debian.
>
> Not even the file dialog integration? Wow. That one works well in OpenSuSE.
>
>> - Chromium: It still feels like a forein body in my KDE desktop. It is fast
>> and all that… but what gives, even with system window borders…
>>
>>
>> And then only Konqi does:
>>
>> - ton of other protocols and KIO stuff
>>
>> - easily have several windows open which are *separate* processes (unlike
>> Iceweasel or Chromium or even Qupzilla it seems, and I think even rekonq which
>> is not currently packaged for Debian, last is 0.9.2-1 for Wheezy, I do have a
>> 2.4.2 package from someone who did one, but thats also not updated)
>>
>> - integrate that well with KDE desktop, bookmark handling, Alt-F2 krunner stuff
>> and so on. Some of the Alt-F2 stuff doesn´t work as I replaced default browser
>> with Qupzilla at the moment. I do not remember which at the moment, but there
>> are things that don´t work with it.
>>
>> - web archives into war files. I loved this, but this also only works with
>> KHTML.
>
> That last bit should be easy to fix, I would think.
>
>> I bet webbrowser work is a lot of work… but are there any plans, ideas?
>>
>> Right now I get the impression it at least to some extent bitrots, which is
>> sad.
>>
>> Konqi with updated web engine… and well, okay, maybe a core set of
>> functionality, maybe it doesn´t need all the functions, maybe some kind of
>> usability studies could reveal what people want most in it, miss most with
>> other browsers compared to Konqueror.
>>
>> I think Konqueror was once one of the pillars of KDE. I´d love to see a
>> comeback of it. My C++ coding skills are pretty basic, but I would like to
>> help in ways I can. And maybe it can be QMLified for its GUI.
>>
>>
>> Right now there is no webbrowser that really satisfies me to use in Plasma
>> desktop.
>>
>> I know this is may be a huge one, but I wanted to draw some attention to this.
>
> I agree with everything you said, but I just don't have time to take care of Konqueror
> in addition to KF5 and Qt contributions.
>
> In fact, there are a number of orthogonal issues:
>
> * Konqueror's GUI itself, which requires a sensibility to usability and modern GUIs
> (see my blog for a set of ideas from Nuno years ago, or Rekonq for an alternative).
> Is Rekonq still developed / maintained, btw?
>
> * The webbrowsing engine. KHTML is fully under our control, but bitrotting.
> QtWebKit is "frozen" by Qt, so hard to change.
> QtWebEngine is AFAIK a closed monolith where we can't integrate KIO.
> There's no good choice in there it seems :(

There are choices, just have to choose one.

Maintaining web engine is a massive task (web standards are huge) and it's not
really practical for small team. Also from user's perspective when two engines
support standards correctly then it doesn't matter which engine is used and more
important is UI/UX. Thus I would say that using not actively
maintained web engine
is worst choice. Even Opera switched from their own Presto engine to Blink.

So choice is between which actively maintained web engine to use.
Gecko, Servo, Blink or WebKit2? (QtWebEngine is basically
Chromium/Blink wrapper)

I think using [1] CEF (Chromium Embedded Framework) could be good idea as
then both [2] Blink and [3] Servo can be used.

[1] https://bitbucket.org/chromiumembedded/cef
[2] https://www.chromium.org/blink
[3] https://github.com/servo/servo

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<