Hi,
I am going to summarize what I wrote yesterday on IRC so everyone can read it.
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons: * We do not control the packaging of Firefox. It is not even open to provenpackager! We'd be completely at the mercy of the Firefox maintainers. * In particular, the Fedora Firefox package will most likely NOT include the KDE integration developed by openSUSE, ever. That means the package will integrate extremely poorly into our Plasma setup (e.g., no KDE file dialogs). * Firefox also has unwanted GNOME dependencies such as (lib)startup-notification. * Shipping Firefox means we have to ship a third HTML engine just for Firefox! We already have to ship KHTML and QtWebKit because KDE software requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses QtWebKit. Shipping Firefox means adding Gecko and thus pointless code duplication and more security updates for users to worry about. * Users who absolutely want Firefox can simply install it from the repository. Or they could use one of the other spins, which (last I checked) all included Firefox (either as the one default or next to Midori). Users who do NOT want Firefox forced on them will have no option to choose from anymore if we join the monopoly. * I don't buy the argument that there is "no alternative" to Firefox. There are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq and Konqueror+KWebKitPart just work on almost all websites out there. (And even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE applications wherever possible. Here, it is clearly possible. Shipping non-KDE applications is acceptable if those are specialized applications with no KDE alternative (think, e.g., Blender). A browser is not specialized, it's a core part of the desktop. And the KDE alternatives exist and work. * I also don't share the worries about Rekonq's future. The port to Qt 5 + QtWebKitWidget is proceeding well. A switch to QWebEngine will be done only when QWebEngine will be ready, a sound decision. And if this really should become a problem in the future (i.e. AFTER F21), we can always reevaluate the default browser decision at that point. * Firefox does not use kioslaves. As such its URL support is inconsistent with the other applications we will ship. In particular, Firefox does NOT support man:foo and info:foo URLs. IMHO, those are by far the most comfortable way to read man and info pages. It also cannot reuse things like kio_gopher, requiring a separate extension (for Gopher, that would be OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the other kioslave-handled protocols just work. * Firefox also has some "features" that are worrisome for Fedora as a whole: - The anti-malware and anti-phishing protection (enabled by default!) sends a hash of every URL you visit to Google (yes, Google!). - Firefox Health Report sends some additional data to Mozilla. It is also enabled by default! - Mozilla also intends to show client-side advertisements (i.e. ones that are NOT part of a web page you are visiting) by default. This is both an added annoyance (as if the ads on the web weren't bad enough!) and a privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq support ad blocking out of the box, Firefox doesn't.) And the Firefox trademark and packaging situation are such that we have no control over these "features", nor any future ones that get added.
So please consider these points before voting here: https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration#Defaul... (votes please ONLY from Plasma working group members, 4 voting members have not voted yet). If you voted for Firefox and these arguments convinced you otherwise, it's also not too late to change your mind!
Let's PLEASE let the Plasma Product be a Plasma product, not yet another Firefox product!
Kevin Kofler
On Wed, Mar 26, 2014 at 01:49:13PM +0100, Kevin Kofler wrote:
- Firefox also has some "features" that are worrisome for Fedora as a whole:
- The anti-malware and anti-phishing protection (enabled by default!) sends a hash of every URL you visit to Google (yes, Google!).
As I understand it, this actually only sends hashes to Google when the first 32 bits of the hash match a list that is *pulled* to your system. And when there is a match, only those 32 bits are sent and the list of full 256-bit hashes with that prefix is returned.
It's still worrisome from a privacy perspective, but not quite as scary as it would be to actually send a hash of every URL or to send full hashes.
Kevin Kofler wrote:
So please consider these points before voting here:
https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration#Defaul...
(votes please ONLY from Plasma working group members, 4 voting members have not voted yet). If you voted for Firefox and these arguments convinced you otherwise, it's also not too late to change your mind!
I'm not a member of this group, which I have never heard of. This poll seems a bizarre way of choosing the best way forward. Surely if you are going to ask anyone, you should ask KDE users.
I've tried Konqueror, which you recommend as an alternative to Firefox, and in my experience it is simply inferior in many ways, which is not surprising considering the numbers involved in the two developments.
Timothy Murphy wrote:
I've tried Konqueror, which you recommend as an alternative to Firefox, and in my experience it is simply inferior in many ways,
And Rekonq? That's the one that's mainly up for discussion now.
which is not surprising considering the numbers involved in the two developments.
In both Konqueror's and Rekonq's case, the actual engine is WebKit, which has A LOT more developers than the browser shells.
Kevin Kofler
Just use the one that "works best"
Eli
On Wednesday 26 March 2014 13:49:13 Kevin Kofler wrote:
Hi,
I am going to summarize what I wrote yesterday on IRC so everyone can read it.
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
- We do not control the packaging of Firefox. It is not even open to
provenpackager! We'd be completely at the mercy of the Firefox maintainers.
- In particular, the Fedora Firefox package will most likely NOT include the
KDE integration developed by openSUSE, ever. That means the package will integrate extremely poorly into our Plasma setup (e.g., no KDE file dialogs).
- Firefox also has unwanted GNOME dependencies such as (lib)startup-notification.
- Shipping Firefox means we have to ship a third HTML engine just for Firefox! We already have to ship KHTML and QtWebKit because KDE software requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses QtWebKit. Shipping Firefox means adding Gecko and thus pointless code duplication and more security updates for users to worry about.
- Users who absolutely want Firefox can simply install it from the repository. Or they could use one of the other spins, which (last I checked) all included Firefox (either as the one default or next to Midori). Users who do NOT want Firefox forced on them will have no option to choose from anymore if we join the monopoly.
- I don't buy the argument that there is "no alternative" to Firefox. There are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq
and Konqueror+KWebKitPart just work on almost all websites out there. (And even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE applications wherever possible. Here, it is clearly possible. Shipping non-KDE applications is acceptable if those are specialized applications with no KDE alternative (think, e.g., Blender). A browser is not specialized, it's a core part of the desktop. And the KDE alternatives exist and work.
- I also don't share the worries about Rekonq's future. The port to Qt 5 + QtWebKitWidget is proceeding well. A switch to QWebEngine will be done only when QWebEngine will be ready, a sound decision. And if this really should become a problem in the future (i.e. AFTER F21), we can always reevaluate the default browser decision at that point.
- Firefox does not use kioslaves. As such its URL support is inconsistent with the other applications we will ship. In particular, Firefox does NOT support man:foo and info:foo URLs. IMHO, those are by far the most comfortable way to read man and info pages. It also cannot reuse things like kio_gopher, requiring a separate extension (for Gopher, that would be
OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the other kioslave-handled protocols just work.
- Firefox also has some "features" that are worrisome for Fedora as a whole:
- The anti-malware and anti-phishing protection (enabled by default!) sends
a hash of every URL you visit to Google (yes, Google!).
- Firefox Health Report sends some additional data to Mozilla. It is also enabled by default!
- Mozilla also intends to show client-side advertisements (i.e. ones that are NOT part of a web page you are visiting) by default. This is both an
added annoyance (as if the ads on the web weren't bad enough!) and a privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq support ad blocking out of the box, Firefox doesn't.) And the Firefox trademark and packaging situation are such that we have no control over these "features", nor any future ones that get added.
So please consider these points before voting here: https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration#Defaul t_web_browser (votes please ONLY from Plasma working group members, 4 voting members have not voted yet). If you voted for Firefox and these arguments convinced you otherwise, it's also not too late to change your mind!
Let's PLEASE let the Plasma Product be a Plasma product, not yet another Firefox product!
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Wednesday 26 March 2014 18:49:10 Kevin Kofler wrote:
Eli Wapniarski wrote:
Just use the one that "works best"
But "works best" depends on the environment it runs in. Integration is an important factor.
Yes it is... But its not the only one. At the end of the story, for me at least. If you don't include firefox, I would install it anyway. Sorry die hards. But I don't have the inclination to fight with the web browser when I want to surf.
I just wanna surf.... Kawabunga
Eli
Eli Wapniarski wrote:
Yes it is... But its not the only one. At the end of the story, for me at least. If you don't include firefox, I would install it anyway. Sorry die hards. But I don't have the inclination to fight with the web browser when I want to surf.
Nobody is stopping you from just doing that, this discussion is about the DEFAULT, i.e. the one included on the live images and set up as the default file/protocol association.
Kevin Kofler
On 2014-03-26 13:49 (GMT+0100) Kevin Kofler composed: ...
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
...
- Shipping Firefox means we have to ship a third HTML engine just for Firefox! We already have to ship KHTML and QtWebKit because KDE software requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses QtWebKit. Shipping Firefox means adding Gecko and thus pointless code duplication and more security updates for users to worry about.
... FWIW as a counter-point, only two non-antique browser engines support absolutely sized objects: KHTML & Gecko. IE, Blink & WebKit for screen media have an absolute 3:4 ratio between pt and px, meaning e.g. that a CSS declaration of 12pt will always be rendered on a display screen @16px, regardless of physical display density. This conforms to CSS3 specification, which is a change from prior CSS versions. IOW, for a web page to display what should be a 10cm wide object 10cm wide (except by accident), an antique, a Gecko, or a KHTML browser engine is required. You can see this for yourself with e.g. http://fm.no-ip.com/Auth/dpi-screen-window.html or http://fm.no-ip.com/Auth/dpi-screen-sample.html or http://fm.no-ip.com/Auth/Font/fonts-ptdemo.html if your DE is configured to accurately match your physical display density.
Felix Miata wrote:
FWIW as a counter-point, only two non-antique browser engines support absolutely sized objects: KHTML & Gecko. IE, Blink & WebKit for screen media have an absolute 3:4 ratio between pt and px, meaning e.g. that a CSS declaration of 12pt will always be rendered on a display screen @16px, regardless of physical display density. This conforms to CSS3 specification, which is a change from prior CSS versions. IOW, for a web page to display what should be a 10cm wide object 10cm wide (except by accident), an antique, a Gecko, or a KHTML browser engine is required. You can see this for yourself with e.g. http://fm.no-ip.com/Auth/dpi-screen-window.html or http://fm.no-ip.com/Auth/dpi-screen-sample.html or http://fm.no-ip.com/Auth/Font/fonts-ptdemo.html if your DE is configured to accurately match your physical display density.
That's an argument for Konqueror, it has KHTML available by design. :-p
But really, if the CSS3 spec is broken, there is not much we can or should do about that. :-(
Kevin Kofler
On 2014-03-26 18:51 (GMT+100) Kevin Kofler composed:
That's an argument for Konqueror, it has KHTML available by design. :-p
For sure, but I really intended the point more as an argument against WebKit, an aside. Most of my browsing is done in SeaMonkey. I use Konq/KHTML and FF as well, but not Chrom* except in isolated instances of wanting to see what WebKit does. Chrom* UI is awful: http://fm.no-ip.com/SS/gchrome300159922b-1200x144init.png
But really, if the CSS3 spec is broken, there is not much we can or should do about that. :-(
True, but the the CSS writers consider it not broken, a choice made intentionally to keep web browsers from appearing to be broken when they are used to render stupidly designed pages, surgery to remove a diseased lung instead of stopping smoking.
Felix Miata wrote:
For sure, but I really intended the point more as an argument against WebKit, an aside. Most of my browsing is done in SeaMonkey. I use Konq/KHTML and FF as well, but not Chrom* except in isolated instances of wanting to see what WebKit does. Chrom* UI is awful: http://fm.no-ip.com/SS/gchrome300159922b-1200x144init.png
Don't worry, Chromium is not in Fedora (and of course neither is Chrome), so that one is not up for discussion anyway.
Kevin Kofler
Um, is there a reason why QupZilla http://www.qupzilla.com/ was not included or is this just an oversight? QupZilla is a Qt-based web browser that currently is better maintained than Konqueror and Rekonq together. Konqueror's UI is very cluttered, whereas Rekonq's UI is not conforming to KDE standards, eg. no menu bar (not even optional), tabs on top (IIRC not configurable), etc.).
As far as I'm aware, Plasma Active has it's own web browser, so no synergy effects between it and the Plasma Active browser are to be expected.
QupZilla OTOH visually fits quite nicely into the rest of KDE applications and it has KWallet support. It also has good extension support, including support for user scripts. I think in general QupZilla also finds the balance of configurability and ease of use that KDE people expect, whereas Konqueror and Rekonq are on opposite ends of that spectrum.
A port to the Chromium-based QtWebEngine of Qt 5 is also already under way. The latest version is packaged in Rawhide. In case you use F19 or F20 and want to easily check it out, I've packaged it under http://download.opensuse.org/repositories/home:/KAMiKAZOW:/Fedora/
Before I switched to Fedora for hardware compatibility reasons, I was conducting my own research on that matter to propose a Qt-based web browser to openSUSE. I think I went in with an open mind. Disclaimer: I contributed German translations to all three projects but I do not consider myself an active contributor to either.
Markus
On Wednesday 26 March 2014 13:49:13 Kevin Kofler wrote:
Hi,
I am going to summarize what I wrote yesterday on IRC so everyone can read it.
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
- We do not control the packaging of Firefox. It is not even open to
provenpackager! We'd be completely at the mercy of the Firefox maintainers.
- In particular, the Fedora Firefox package will most likely NOT include the
KDE integration developed by openSUSE, ever. That means the package will integrate extremely poorly into our Plasma setup (e.g., no KDE file dialogs).
- Firefox also has unwanted GNOME dependencies such as (lib)startup-notification.
- Shipping Firefox means we have to ship a third HTML engine just for Firefox! We already have to ship KHTML and QtWebKit because KDE software requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses QtWebKit. Shipping Firefox means adding Gecko and thus pointless code duplication and more security updates for users to worry about.
- Users who absolutely want Firefox can simply install it from the repository. Or they could use one of the other spins, which (last I checked) all included Firefox (either as the one default or next to Midori). Users who do NOT want Firefox forced on them will have no option to choose from anymore if we join the monopoly.
- I don't buy the argument that there is "no alternative" to Firefox. There are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq
and Konqueror+KWebKitPart just work on almost all websites out there. (And even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE applications wherever possible. Here, it is clearly possible. Shipping non-KDE applications is acceptable if those are specialized applications with no KDE alternative (think, e.g., Blender). A browser is not specialized, it's a core part of the desktop. And the KDE alternatives exist and work.
- I also don't share the worries about Rekonq's future. The port to Qt 5 + QtWebKitWidget is proceeding well. A switch to QWebEngine will be done only when QWebEngine will be ready, a sound decision. And if this really should become a problem in the future (i.e. AFTER F21), we can always reevaluate the default browser decision at that point.
- Firefox does not use kioslaves. As such its URL support is inconsistent with the other applications we will ship. In particular, Firefox does NOT support man:foo and info:foo URLs. IMHO, those are by far the most comfortable way to read man and info pages. It also cannot reuse things like kio_gopher, requiring a separate extension (for Gopher, that would be
OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the other kioslave-handled protocols just work.
- Firefox also has some "features" that are worrisome for Fedora as a whole:
- The anti-malware and anti-phishing protection (enabled by default!) sends
a hash of every URL you visit to Google (yes, Google!).
- Firefox Health Report sends some additional data to Mozilla. It is also enabled by default!
- Mozilla also intends to show client-side advertisements (i.e. ones that are NOT part of a web page you are visiting) by default. This is both an
added annoyance (as if the ads on the web weren't bad enough!) and a privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq support ad blocking out of the box, Firefox doesn't.) And the Firefox trademark and packaging situation are such that we have no control over these "features", nor any future ones that get added.
So please consider these points before voting here: https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration#Defaul t_web_browser (votes please ONLY from Plasma working group members, 4 voting members have not voted yet). If you voted for Firefox and these arguments convinced you otherwise, it's also not too late to change your mind!
Let's PLEASE let the Plasma Product be a Plasma product, not yet another Firefox product!
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Markus Slopianka wrote:
Um, is there a reason why QupZilla http://www.qupzilla.com/ was not included or is this just an oversight?
It was brought up on the chan later (and so far didn't get much support). Mainly, we didn't consider it right away because it's a (mostly) Qt-only browser (one out of several QtWebKit browsers, actually, e.g., there's also Arora). Maybe we should reconsider. (Christoph Wickert also says QupZilla is the best Qt browser, that's why he maintains the Fedora package.)
QupZilla is a Qt-based web browser that currently is better maintained than Konqueror and Rekonq together. Konqueror's UI is very cluttered, whereas Rekonq's UI is not conforming to KDE standards, eg. no menu bar (not even optional), tabs on top (IIRC not configurable), etc.).
I don't personally like Rekonq's UI either, I prefer Konqueror.
QupZilla's look is indeed more customizable, the default looks more like Konqueror (I just tried it), one of the screenshots on the website shows it set up to look like Rekonq.
QupZilla OTOH visually fits quite nicely into the rest of KDE applications and it has KWallet support.
But it does not support KIO. :-( So, in particular, no man:, info:, gopher: etc. URLs. (Both Konqueror and Rekonq support that.)
It also does not support KDE web shortcuts, like gg: to search in Google, bz: for Red Hat Bugzilla with a bug ID, bug: for KDE Bugzilla with a bug ID etc. :-( (Both Konqueror and Rekonq support that, too.)
Also, Edit / Preferences does not comply to the KDE HIG. (It's a GNOMEism.)
So, unfortunately, it shows that it is Qt-only, KDE integration is only partial.
That said, you have a good point there, in particular one against Firefox: Firefox does not support KWallet! Another very strong reason not to default to it. Folks, you can argue all you want that users "don't notice" missing system integration, but for KWallet, users WILL notice.
It also has good extension support, including support for user scripts.
That's a plus (and something neither Konqueror nor Rekonq currently have).
I think in general QupZilla also finds the balance of configurability and ease of use that KDE people expect, whereas Konqueror and Rekonq are on opposite ends of that spectrum.
My personal opinion is that Konqueror is the right approach. But I'll take any KDE or even Qt-only browser as our default over Firefox any day. (As for myself, you can pry my Konqueror from my cold, dead hands. ;-) )
A port to the Chromium-based QtWebEngine of Qt 5 is also already under way. The latest version is packaged in Rawhide. In case you use F19 or F20 and want to easily check it out, I've packaged it under http://download.opensuse.org/repositories/home:/KAMiKAZOW:/Fedora/
Is QtWebEngine even good enough for that (i.e. writing a browser around it) yet? The Rekonq developer does not think it is, and based on what I've read from Qt upstream, I'd tend to agree.
By the way, getting QtWebEngine into Fedora is going to be a real problem. We don't even have upstream Chromium in because it bundles so many libraries, and now that thing bundles Chromium! I get the feeling that we can only get this in if the reviewer closes both eyes deep shut. :-( But this is going to affect all Qt/KDE browsers and even non-browser applications (so we won't be able to chicken out of it just by shipping Firefox) sooner or later. It's a real problem.
Before I switched to Fedora for hardware compatibility reasons, I was conducting my own research on that matter to propose a Qt-based web browser to openSUSE. I think I went in with an open mind.
Thank you for your insights.
Kevin Kofler
On Thursday 27 March 2014 01:16:11 Kevin Kofler wrote:
But it does not support KIO. :-( So, in particular, no man:, info:, gopher: etc. URLs. (Both Konqueror and Rekonq support that.)
Right, but I found it an acceptable trade off (YMMV) for a browser that is very actively maintained. Scrolling through commit logs, there is already a bunch of QupZilla contributors visible on the first page of GitHub, whereas Rekonq is pretty much a one-man show of Andrea Diamantini.
Konqueror is practically dead with most files not been touched for YEARS! https://projects.kde.org/projects/kde/applications/kde-baseapps/repository/r...
When I looked at various browsers, my agenda was to find the best Qt-based web browser available. Not the best manpage browser, not the best Gopher browser.
It also does not support KDE web shortcuts, like gg: to search in Google, bz: for Red Hat Bugzilla with a bug ID, bug: for KDE Bugzilla with a bug ID etc. :-( (Both Konqueror and Rekonq support that, too.)
I'm not too familiar with QupZilla’s extension infrastructure but I guess these could be added -- if one actually thinks that these shortcuts are a must-have feature (I don't).
Also, Edit / Preferences does not comply to the KDE HIG. (It's a GNOMEism.)
In the limited time I had contact with QupZilla's maintainer(s), I found them easy to interact with and open for ideas. I'm sure this is something they would not refuse to implement, esp. if becoming default in Fedora KDE is a prospect.
My personal opinion is that Konqueror is the right approach. But I'll take any KDE or even Qt-only browser as our default over Firefox any day. (As for myself, you can pry my Konqueror from my cold, dead hands. ;-) )
As you wrote yourself, this is not about removing options from the repos. ;-) Personally, I use Firefox. While I considered QupZilla of all Qt-based browsers the best candidate for a default in a KDE environment, I would not keep it for me either (so from my own POV it actually does not matter what you'll choose). I think of myself to have a good eye what most regular KDE users want: They are more advanced than the regular Ubuntu user but at the same time not so eager to tweak absolutely everything as Awesome WM users. ;-)
So please don't read my mail as one by a fanboy who wants "his" browser to become default. :-)
Is QtWebEngine even good enough for that (i.e. writing a browser around it) yet? The Rekonq developer does not think it is, and based on what I've read from Qt upstream, I'd tend to agree.
I have no insights into QtWebEngine. All I know about it is from blogs (Digia's and QupZilla's). I'm not sure if QupZilla 2.0 will simply support both QtWebKit and QtWebEngine or rely on QtWebEngine exclusively. http://blog.qupzilla.com/2014/01/qupzilla-161-released.html does not got into detail on that topic.
http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/ clearly says that Digia "no longer will do any feature development in Qt WebKit".
I am not aware of any plans by KDE upstream for their KDEWebKit wrapper to migrate.
Markus Slopianka wrote:
I am not aware of any plans by KDE upstream for their KDEWebKit wrapper to migrate.
As far as I can tell, it is not even possible to support the same features (KIO integration in particular) on top of the current QtWebEngine. It does not use QNetworkAccessManager as QtWebKit did. Support for the main protocols (like HTTP) is hardcoded inside the Chromium code. Adding protocols is possible at the QtWebEngine level, it does that for qrc:, but (as far as I can see) for no other protocols, nor does it (currently) expose an API for QtWebEngine users to add THEIR protocol handlers. (And I think the Chromium API requires you to first get a list of all the protocols you can handle so you can install handlers for them, which is doable for KIO, but far from ideal.)
IMHO, QtWebEngine is a step backwards all over the place (compared to QtWebKit). :-( Nested bundling (bundled Chromium which bundles the world), much more limited platform (CPU) support, less powerful API (because Chromium doesn't expose as much as WebKit did, which limits what QtWebEngine can offer), no GStreamer support, no QNetworkAccessManager/KIO support, …
Kevin Kofler
On Thursday 27 March 2014 14:49:24 Kevin Kofler wrote:
IMHO, QtWebEngine is a step backwards all over the place (compared to QtWebKit). :-( Nested bundling (bundled Chromium which bundles the world), much more limited platform (CPU) support, less powerful API (because Chromium doesn't expose as much as WebKit did, which limits what QtWebEngine can offer), no GStreamer support, no QNetworkAccessManager/KIO support, …
If anybody is able to continue to maintain QtWebKit (eg. by coordinating with the WebKit-GTK people to use the same branch), I'd welcome them with open arms.
On Thu, Mar 27, 2014 at 01:16:11AM +0100, Kevin Kofler wrote:
Markus Slopianka wrote:
That said, you have a good point there, in particular one against Firefox: Firefox does not support KWallet! Another very strong reason not to default to it. Folks, you can argue all you want that users "don't notice" missing system integration, but for KWallet, users WILL notice.
good or bad? I will never store anything but throwaway passwords in the Firefox wallet. I won't use a browser which integrates with the "system" wallet and neither a browser without NoScript, AdBlocker and some of the cookie extensions.
Richard
--- Name and OpenPGP keys available from pgp key servers
On 03/28/14 05:45, Richard Z wrote:
On Thu, Mar 27, 2014 at 01:16:11AM +0100, Kevin Kofler wrote:
Markus Slopianka wrote:
That said, you have a good point there, in particular one against Firefox: Firefox does not support KWallet! Another very strong reason not to default to it. Folks, you can argue all you want that users "don't notice" missing system integration, but for KWallet, users WILL notice.
good or bad? I will never store anything but throwaway passwords in the Firefox wallet. I won't use a browser which integrates with the "system" wallet and neither a browser without NoScript, AdBlocker and some of the cookie extensions.
+1
after following this thread for a while and reading the 'battle' of the good and bad of firefox as a browser, i feel that it is time to jump in to the mess and voice my feelings.
first off, this thread reminds me of a song that came out at the turn of the 70's. "War". it had a kick-ass beat, it is a protest song, but i still like it. so did every one in a disco club where i was manager and head bartender.
in war, there is the line, "War. what is it good for?".
in a similar context, "Firefox. what is it good for?".
well firefox is great for web browsing and has a great 'library' for handling bookmarks. way better than what is available in 'konqueror' in web browser mode.
there is very little that the konqueror can be set up for and the display frame for bookmarks sucks. also, try to set up a bookmarks tree, or duplicate bookmarks in different branch headings. not very easy to do.
i could go on and on about the advantages of firefox bookmarks, but to do so is really not necessary. also, it is a feature that is best appreciated by playing with it.
firefox is 'rfc compliant' and 'html5' compatible. i do not know about konqueror.
need something different for firefox or add capabilities to how it functions, well just check the vast 'add-ons' that are available. does konqueror have any such?
i would hate to think that i had to go out on web and not have 'NoScript' and 'AdBlocker' available. just to mention a couple of the add-ons that i use.
does konqueror have such?
agreed, i am comparing to konqueror, but i apply same to 'Rekonq' which i have not tried. i see no need or desire to.
so firefox does not meet the 'standards' of a 'Plasma Product', it does meet the standards of what is needed for a great web browser.
konqueror, as a file browser is great. in my opinion, much better and more versatile than 'Dolphin'.
i will give one credit to konqueror for web use, it works well for ftp for 'drag and drop'.
in closing, i suggest this, keep firefox as a selectable package. also, leave rekong as a selectable choice also. do not force it to be installed as a default.
no one knows the needs of all the end users. the web browser, as well as the email client, should be left up to the user to decide what is best for the user.
as linux users, we are not in a dictatorship way of life. it is a life of choice. leave web browser and email client up to the choice of the end user.
thank you.
Am 28.03.2014 16:21, schrieb g:
in closing, i suggest this, keep firefox as a selectable package. also, leave rekong as a selectable choice also. do not force it to be installed as a default.
did anybody say something different in that thread? frankly you can install *any* package in any product
no one knows the needs of all the end users. the web browser, as well as the email client, should be left up to the user to decide what is best for the user.
did anybody say something different in that thread?
as linux users, we are not in a dictatorship way of life. it is a life of choice. leave web browser and email client up to the choice of the end user.
did anybody say something different in that thread?
the topic is about *what is installed as default*
On 03/28/14 10:32, Reindl Harald wrote: <>
just what is your problem?
i am very much aware of what "Subject:" line says, as well as what Kevin and others have written about. mainly;
The discussion of what should be the default browser on the Plasma Product
my reply was that, like others, firefox is my choice of browser and i believe that *no browser* should be made the _default_.
being that you are a 'non native english', i can see that you may tend to not understand what op wrote, and, not understand what i wrote.
therefore, i consider your reply to my post as being of lack of adequate comprehension or understanding, and refuse to enter a nit picking bickering with you, which you seem to enjoy. else you would not have posted as you did.
have a great day.
Am 28.03.2014 20:41, schrieb g:
On 03/28/14 10:32, Reindl Harald wrote: <>
just what is your problem?
i have none, you have one reading your post i answered
i am very much aware of what "Subject:" line says, as well as what Kevin and others have written about. mainly;
The discussion of what should be the default browser on the Plasma Product
my reply was that, like others, firefox is my choice of browser
guess what: i am a firefox user
and i believe that *no browser* should be made the _default_
that will surely help users sitting in front of a machine and have to figure out how to browse the web in 2014
being that you are a 'non native english', i can see that you may tend to not understand what op wrote, and, not understand what i wrote.
i understand what you wrote but it makes no sense
in case of a KDE "product" it is a logical conclusion to not ship a GTK based browser in the default setup
therefore, i consider your reply to my post as being of lack of adequate comprehension or understanding, and refuse to enter a nit picking bickering with you, which you seem to enjoy. else you would not have posted as you did
your post sounded like someone is taking away firefox from you while you can anyways type "yum install firefox" or use whatever GUI to achieve the same
On 03/28/14 16:15, Reindl Harald wrote: <>
congratulations, you have been reinstated to my 'pestaside' filter.
g wrote:
first off, this thread reminds me of a song that came out at the turn of the 70's. "War". it had a kick-ass beat, it is a protest song, but i still like it. so did every one in a disco club where i was manager and head bartender.
in war, there is the line, "War. what is it good for?".
in a similar context, "Firefox. what is it good for?".
I get the impression that you completely missed the point of that 70's song…
i would hate to think that i had to go out on web and not have 'NoScript' and 'AdBlocker' available. just to mention a couple of the add-ons that i use.
Konqueror has both ad blocking and per-site JavaScript blocking built in. (Rekonq has ad blocking, but unfortunately no per-site JavaScript blocking, only a global setting.)
Kevin Kofler
On 03/28/14 19:47, Kevin Kofler wrote:
g wrote:
first off, this thread reminds me of a song that came out at the turn of the 70's. "War". it had a kick-ass beat, it is a protest song, but i still like it. so did every one in a disco club where i was manager and head bartender.
in war, there is the line, "War. what is it good for?".
in a similar context, "Firefox. what is it good for?".
I get the impression that you completely missed the point of that 70's song…
oh?
was it not a protest of the Vietnam "police action", aka, war?
at least the one to which i reference, by Edwin Starr, appeared as such to me.
[also, above, i should have used word _start_ instead of _turn_.]
i would hate to think that i had to go out on web and not have 'NoScript' and 'AdBlocker' available. just to mention a couple of the add-ons that i use.
Konqueror has both ad blocking and per-site JavaScript blocking built in. (Rekonq has ad blocking, but unfortunately no per-site JavaScript blocking, only a global setting.)
i happen to have 18 active 'extensions', with 3 more disabled until i need them. plus 8 active 'plugins'.
i dare say that konqueror or rekonq will/would/might come close.
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Am 29.03.2014 04:02, schrieb g:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
then you need http://www.linuxfromscratch.org/ because otherwise you will always have packages as default
g wrote:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Thanks, but I think it's a given that we need to install one web browser by default, and that the question is which one. Not installing any (or some how providing a choice) is not an option we are considering.
-- Rex
Rex Dieter wrote:
g wrote:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Thanks, but I think it's a given that we need to install one web browser by default, and that the question is which one. Not installing any (or some how providing a choice) is not an option we are considering.
On the other hand, we *could* move the webbrowser outside of treating it as part of the desktop environment, and more as an (essential) addon application.
-- Rex
On 03/29/14 15:45, Rex Dieter wrote:
Rex Dieter wrote:
g wrote:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Thanks, but I think it's a given that we need to install one web browser by default, and that the question is which one. Not installing any (or some how providing a choice) is not an option we are considering.
is linux not all about _choice_. ;-)
On the other hand, we *could* move the webbrowser outside of treating it as part of the desktop environment, and more as an (essential) addon application.
that could be a better way. and, "even mo betta" if it where set up to give user/installer a _choice_ as to which browser.
Am 29.03.2014 23:34, schrieb g:
On 03/29/14 15:45, Rex Dieter wrote:
Rex Dieter wrote:
g wrote:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Thanks, but I think it's a given that we need to install one web browser by default, and that the question is which one. Not installing any (or some how providing a choice) is not an option we are considering.
is linux not all about _choice_. ;-)
you have the choice all the time to install whatever browser you want or even any available at the same time
On the other hand, we *could* move the webbrowser outside of treating it as part of the desktop environment, and more as an (essential) addon application.
that could be a better way. and, "even mo betta" if it where set up to give user/installer a _choice_ as to which browser
and i want to have some additional choices in the installer:
* what texteditor * what video player * what audio player * what image viewer
no, i don't want that really i only want to point out where that leads
why should a browser be handeled special and whatever justification you would use what do you do if the same is taken for any sort of software and who will maintain that?
On Sat, 2014-03-29 at 15:45 -0500, Rex Dieter wrote:
Rex Dieter wrote:
g wrote:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Thanks, but I think it's a given that we need to install one web browser by default, and that the question is which one. Not installing any (or some how providing a choice) is not an option we are considering.
On the other hand, we *could* move the webbrowser outside of treating it as part of the desktop environment, and more as an (essential) addon application.
I'd go along with that. I know this may be somewhat heretical, but I use KDE because I like the GUI, not because I like most of the specific apps. I don't use Kmail and friends, or Kwallet, or the media player or probably a bunch of other stuff. I use Evolution for mail, Chrome and Firefox for browsing, VLC for media playing, qBittorrent for torrents etc. I do use Konsole and Dolphin but could get by without them. Digikam is very good but it would still be good running under another DE. I can't even remember the last time I used Konqueror but it's many years ago. I do understand about the KIO stuff but I don't miss it.
And I absolutely do *not* understand Activities. I know what they are, I just don't see the point of them if I already have multiple virtual desktops.
However I don't want to get too OT.
poc
On Sat, Mar 29, 2014 at 03:45:24PM -0500, Rex Dieter wrote:
Rex Dieter wrote:
g wrote:
yet, in reality, my point, which one missed, is that when it comes to web browsers and email clients, it is like baskin-robbins, there are many choices to make and that choice should be left to user. not packages that are loaded by default when a new installation is made.
Thanks, but I think it's a given that we need to install one web browser by default, and that the question is which one. Not installing any (or some how providing a choice) is not an option we are considering.
On the other hand, we *could* move the webbrowser outside of treating it as part of the desktop environment, and more as an (essential) addon application.
I am always using a bunch of web browsers and perhaps I am not alone.
So it might be an idea to have the concept of a kde-browser for local tasks where a desktop default with all the nice integration makes sense and a personal preference webbrowser for the internet.
Richard
--- Name and OpenPGP keys available from pgp key servers
g wrote:
On 03/28/14 19:47, Kevin Kofler wrote:
g wrote:
first off, this thread reminds me of a song that came out at the turn of the 70's. "War". it had a kick-ass beat, it is a protest song, but i still like it. so did every one in a disco club where i was manager and head bartender.
in war, there is the line, "War. what is it good for?".
in a similar context, "Firefox. what is it good for?".
I get the impression that you completely missed the point of that 70's song…
oh?
was it not a protest of the Vietnam "police action", aka, war?
My point is that the "What is it good for?" question is a rhetorical one, and the implication is that war isn't good for anything.
Yet you aren't trying to imply that Firefox is good for nothing, are you? ;-)
Kevin Kofler
PS:
Markus Slopianka wrote:
Disclaimer: I contributed German translations to all three projects but I do not consider myself an active contributor to either.
Speaking of the German translation, qupzilla-1.4.4-1.fc19 has broken translations on a de_AT locale. It comes up all in English, I have to manually switch the language to de_DE in the preferences to get a German translation. The problem is that it ships the translation as de_DE.qm, should be just de.qm (and same for most or all the other languages; the _COUNTRY part makes sense only in very limited cases).
https://bugzilla.redhat.com/show_bug.cgi?id=1081279 https://github.com/QupZilla/qupzilla/issues/1272
Kevin Kofler
Please keep things civil.
I agree with Kevin (historical moment... lol). I also think that Konqi should be made default browser (as bad as it has become). I also believe that it would be a great thing if the packagers from the various distros band together and request with (unrelenting pressure - like thats gonna be worth anything) from KDE to put adequate resources to restore Konqueror to its former glory being the granddaddy to all the webkit browsers out there. I miss boasting about the speed and versatility of what was the fastest lightest and most versatile browser on the planet until the team started to adapt Safari (Mac changes) into Konqueror.
Eli
On Wednesday 26 March 2014 23:57:16 Markus Slopianka wrote:
Um, is there a reason why QupZilla http://www.qupzilla.com/ was not included or is this just an oversight? QupZilla is a Qt-based web browser that currently is better maintained than Konqueror and Rekonq together. Konqueror's UI is very cluttered, whereas Rekonq's UI is not conforming to KDE standards, eg. no menu bar (not even optional), tabs on top (IIRC not configurable), etc.).
As far as I'm aware, Plasma Active has it's own web browser, so no synergy effects between it and the Plasma Active browser are to be expected.
QupZilla OTOH visually fits quite nicely into the rest of KDE applications and it has KWallet support. It also has good extension support, including support for user scripts. I think in general QupZilla also finds the balance of configurability and ease of use that KDE people expect, whereas Konqueror and Rekonq are on opposite ends of that spectrum.
A port to the Chromium-based QtWebEngine of Qt 5 is also already under way. The latest version is packaged in Rawhide. In case you use F19 or F20 and want to easily check it out, I've packaged it under http://download.opensuse.org/repositories/home:/KAMiKAZOW:/Fedora/
Before I switched to Fedora for hardware compatibility reasons, I was conducting my own research on that matter to propose a Qt-based web browser to openSUSE. I think I went in with an open mind. Disclaimer: I contributed German translations to all three projects but I do not consider myself an active contributor to either.
Markus
On Wednesday 26 March 2014 13:49:13 Kevin Kofler wrote:
Hi,
I am going to summarize what I wrote yesterday on IRC so everyone can read it.
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons: * We do not control the packaging of Firefox. It is not even open to provenpackager! We'd be completely at the mercy of the Firefox
maintainers.
- In particular, the Fedora Firefox package will most likely NOT include
the KDE integration developed by openSUSE, ever. That means the package will integrate extremely poorly into our Plasma setup (e.g., no KDE file dialogs).
Firefox also has unwanted GNOME dependencies such as
(lib)startup-notification.
Shipping Firefox means we have to ship a third HTML engine just for
Firefox! We already have to ship KHTML and QtWebKit because KDE software requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses QtWebKit. Shipping Firefox means adding Gecko and thus pointless code duplication and more security updates for users to worry about.
Users who absolutely want Firefox can simply install it from the
repository. Or they could use one of the other spins, which (last I checked) all included Firefox (either as the one default or next to Midori). Users who do NOT want Firefox forced on them will have no option to choose from anymore if we join the monopoly.
I don't buy the argument that there is "no alternative" to Firefox.
There
are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq
and Konqueror+KWebKitPart just work on almost all websites out there. (And even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE applications wherever possible. Here, it is clearly possible. Shipping non-KDE applications is acceptable if those are specialized applications with no KDE alternative (think, e.g., Blender). A browser is not specialized, it's a core part of the desktop. And the KDE alternatives exist and work.
I also don't share the worries about Rekonq's future. The port to Qt 5 +
QtWebKitWidget is proceeding well. A switch to QWebEngine will be done only when QWebEngine will be ready, a sound decision. And if this really should become a problem in the future (i.e. AFTER F21), we can always reevaluate the default browser decision at that point.
Firefox does not use kioslaves. As such its URL support is inconsistent
with the other applications we will ship. In particular, Firefox does NOT support man:foo and info:foo URLs. IMHO, those are by far the most comfortable way to read man and info pages. It also cannot reuse things like kio_gopher, requiring a separate extension (for Gopher, that would be
OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the other kioslave-handled protocols just work.
- Firefox also has some "features" that are worrisome for Fedora as a
whole: - The anti-malware and anti-phishing protection (enabled by default!) sends a hash of every URL you visit to Google (yes, Google!).
- Firefox Health Report sends some additional data to Mozilla. It is
also
enabled by default!
- Mozilla also intends to show client-side advertisements (i.e. ones
that
are NOT part of a web page you are visiting) by default. This is both anadded annoyance (as if the ads on the web weren't bad enough!) and a privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq support ad blocking out of the box, Firefox doesn't.)
And the Firefox trademark and packaging situation are such that we have no
control over these "features", nor any future ones that get added.
So please consider these points before voting here: https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration#Defa ul t_web_browser (votes please ONLY from Plasma working group members, 4 voting members have not voted yet). If you voted for Firefox and these arguments convinced you otherwise, it's also not too late to change your mind!
Let's PLEASE let the Plasma Product be a Plasma product, not yet another Firefox product!
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Eli Wapniarski wrote:
there. I miss boasting about the speed and versatility of what was the fastest lightest and most versatile browser on the planet until the team started to adapt Safari (Mac changes) into Konqueror.
The WebKit fork has indeed made many things worse, especially when it got then ported (back) to Qt, absorbing many of the KHTML developers and leading to 2 competing HTML engines in KDE. WebKit's code is also much less cleaner than KHTML's. But these days, KHTML cannot match WebKit's JavaScript performance (on sites massively and unnecessarily abusing JavaScript) nor its support for the fancy newfangled HTML 5 "features" websites are (ab)using all over the place for no good reason. So we have to work with QtWebKit.
And what's worse: now the same thing is happening all over again! Blink has been forked from WebKit, it too is getting ported to Qt (QtWebEngine), absorbing the QtWebKit developers, and the code is even worse than WebKit's. (Sure, they "cleaned up" the #ifdef mess, but they did that by hardcoding the worst possible options: FFmpeg (with its patent issues and its monolithic structure that doesn't allow easily working around them) for multimedia, V8 (which is JIT-only and has no portable interpreter fallback) for JavaScript, etc. And they added more bloated mess of their own.)
Kevin Kofler
So in the end, the choice comes is between a browser that doesn't work as well as it should but looks like it belongs (on many different fronts), or a browser that works the way it should but doesn't quite integrate.
hmmm.
Sounds like the main desktop developers (ie gnome / kde / qt). Have not come up with an adequate solution for web browsing. That's why the vast majority of us use firefox or google chrome or both. KDE provides a way to integrate the look and feel of KDE onto the gtk based apps.
Again... I for one would be using Firefox as my main browser regardless and since it is packaged with Fedora.... Maybe...just maybe the hands should go up in the air and we should say "oh well that life" and provide Firefox because well... thats the browser people use.
Eli
On Sunday 30 March 2014 13:32:14 Kevin Kofler wrote:
Eli Wapniarski wrote:
there. I miss boasting about the speed and versatility of what was the fastest lightest and most versatile browser on the planet until the team started to adapt Safari (Mac changes) into Konqueror.
The WebKit fork has indeed made many things worse, especially when it got then ported (back) to Qt, absorbing many of the KHTML developers and leading to 2 competing HTML engines in KDE. WebKit's code is also much less cleaner than KHTML's. But these days, KHTML cannot match WebKit's JavaScript performance (on sites massively and unnecessarily abusing JavaScript) nor its support for the fancy newfangled HTML 5 "features" websites are (ab)using all over the place for no good reason. So we have to work with QtWebKit.
And what's worse: now the same thing is happening all over again! Blink has been forked from WebKit, it too is getting ported to Qt (QtWebEngine), absorbing the QtWebKit developers, and the code is even worse than WebKit's. (Sure, they "cleaned up" the #ifdef mess, but they did that by hardcoding the worst possible options: FFmpeg (with its patent issues and its monolithic structure that doesn't allow easily working around them) for multimedia, V8 (which is JIT-only and has no portable interpreter fallback) for JavaScript, etc. And they added more bloated mess of their own.)
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Am 30.03.2014 16:44, schrieb Eli Wapniarski:
So in the end, the choice comes is between a browser that doesn't work as well as it should but looks like it belongs (on many different fronts), or a browser that works the way it should but doesn't quite integrate.
Sounds like the main desktop developers (ie gnome / kde / qt). Have not come up with an adequate solution for web browsing. That's why the vast majority of us use firefox or google chrome or both. KDE provides a way to integrate the look and feel of KDE onto the gtk based apps.
Again... I for one would be using Firefox as my main browser regardless and since it is packaged with Fedora.... Maybe...just maybe the hands should go up in the air and we should say "oh well that life" and provide Firefox because well... thats the browser people use.
if that main-developers would be interested Mozilla for sure would not refuse code to make the integration better instead install addons and themes which breaks from time to time
but forget the GNOME developers here, they appear to live in their own world and are happy that FF is using GTK _______________________________________________________________
KHTML as rendering engine is dead, look how badly it renders with cms-customized webforms while any other browser agress with the developers intention over at least 10 years
that's why there are enough rendering engines and the energy should be put in pure desktop-integration and use one of the established engines in the background
On 03/26/2014 01:49 PM, Kevin Kofler wrote:
Hi,
I am going to summarize what I wrote yesterday on IRC so everyone can read it.
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
Yet firefox is the answer for just one following reason: It works.
I tried both konqueror and rekonq a long time ago and was not satisfied with them at all. Before writing this email, I tried them again. Rekonq improved, but still not good enough.
I use tabs in firefox as my todo-list (with extra addons to make sure I don't lose it). Right now I have 480+ tabs. Firefox is still working, it is fast and memory consumption is reasonable.
I tried rekonq and it crashed before I got to 50 tabs. (google search for something and open every link in a new tab). Just before it crashed it took almost half of the RAM firefox takes - with 10% of tabs (I don't know if some memory management would hit later, just describing what I've seen).
Firefox is faster - tried loading a few huge pages, rekong took 130%-200% time to load them.
Quick html5 support test (http://html5test.com/) shows html5 support in firefox is better.
Also, for user it is annoying to get "Your web browser is too old or not supported" messages too often (I got them 3 times during just a few minute test).
Anyway, if it is still possible to install Firefox from repository, I don't care. It's what I've been doing for last X years anyway. When I install Linux ( = Fedora KDE ), people are usually happy. But LibreOffice and Firefox is a must.
Seems to me this is the purity vs. usability question. It would be nice to have well integrated web browser - an application that is used most of the time ordinary user is working with a computer. Especially file dialog and kwallet integration would be nice. On the other hand, users will get much better experience with firefox. Similar as mediaplayers or codecs in fedora. We have them extra - located in rpmfusion. It's nice that our system is Pure(tm), but users usually do not care. They want to use their computer so they have to install all those Ugly and Unpure(tm) pieces anyway. It's just annoying to have to do it and some leave fedora with (wrong) impression "it does not work in fedora, but it works in ubuntu", Don't use this approach, learn from it.
Just my 2 cents.
Michal
On Mon, 2014-03-31 at 12:54 +0200, Michal Hlavinka wrote:
Quick html5 support test (http://html5test.com/) shows html5 support in firefox is better.
And Konqueror is not mentioned (though Safari is).
poc
On 03/31/2014 04:27 PM, Patrick O'Callaghan wrote:
On Mon, 2014-03-31 at 12:54 +0200, Michal Hlavinka wrote:
Quick html5 support test (http://html5test.com/) shows html5 support in firefox is better.
And Konqueror is not mentioned (though Safari is).
You have to open that page in the browser you are interested about. * Konqueror: - KHTML 19 % - WebKit 73 % * Rekonq 73 % * Firefox 81 % * Chrome 91 %
CSS3 support http://css3test.com/ : * Konqueror - KHTML 18 % - WebKit 54 % * Rekonq 54 % * Firefox 53 % * Chrome 57 %
Anyway, except KHTML, the score is not that bad (from my pov). I did not mean that it should be the most important single reason for browser selection. Just a bonus point.
On Mon, 2014-03-31 at 17:17 +0200, Michal Hlavinka wrote:
Quick html5 support test (http://html5test.com/) shows html5
support
in firefox is better.
And Konqueror is not mentioned (though Safari is).
You have to open that page in the browser you are interested about.
- Konqueror:
- KHTML 19 %
- WebKit 73 %
- Rekonq 73 %
- Firefox 81 %
- Chrome 91 %
If I open it in Chrome and compare the results for other browsers I can see results for Firefox, Safari, Opera, IE etc., all in various versions, but Konqueror does not appear. Nor is it searchable on the site. When I open it in Konqueror it does give the browser identification and a rating, but not otherwise.
poc
On 03/31/14 10:48, Patrick O'Callaghan wrote: <<>>
If I open it in Chrome and compare the results for other browsers I can see results for Firefox, Safari, Opera, IE etc., all in various versions, but Konqueror does not appear. Nor is it searchable on the site. When I open it in Konqueror it does give the browser identification and a rating, but not otherwise.
i would consider that to indicate how little html5test.com considers knoqueror as a web browser. :-)
they do not even mention knoqueror or rekonq under "other".
tho they do show, under "latest results";
405 rekonq 2.4.2 in linux 7 minutes ago
if that really accounts for anything, because it is likely from someone from this list/thread, checking.
so, i would imagine, if all in this thread and reading this thread were to hit html5test.com with konqueror and rekonq, both may/might have an influence on how both end up being displayed in the various tabs and ratings.
kind of like fixing a horse race. ;-)
also, note that there are very few linux listings. and, it seems, ubuntu is not considered as linux.
Michal Hlavinka wrote:
I use tabs in firefox as my todo-list (with extra addons to make sure I don't lose it). Right now I have 480+ tabs. Firefox is still working, it is fast and memory consumption is reasonable.
This is clear abuse of the web browser, not the common usage pattern. I'm surprised that ANY browser supports that kind of abuse. (Especially Firefox used to get criticized for excessive memory requirements by people like you opening hundreds of tabs.) I don't think this should be a requirement for our default browser.
Kevin Kofler
On 03/31/2014 08:10 PM, Kevin Kofler wrote:
Michal Hlavinka wrote:
I use tabs in firefox as my todo-list (with extra addons to make sure I don't lose it). Right now I have 480+ tabs. Firefox is still working, it is fast and memory consumption is reasonable.
This is clear abuse of the web browser, not the common usage pattern. I'm surprised that ANY browser supports that kind of abuse. (Especially Firefox used to get criticized for excessive memory requirements by people like you opening hundreds of tabs.) I don't think this should be a requirement for our default browser.
I agree that so many tabs is not an usual use case. I mentioned it just to note that even if you abuse firefox, it works. On the other hand, fifty tabs is not that much, yet rekonq (and qupzilla) both used a lot of memory and crashed.
Anyway, I just voiced my opinion that people won't be happy with konqueror nor rekonq. All (mostly Fedora) KDE users I know use Firefox or Chrome. I personally do not know anyone happy with how konqueror or rekonq work. I will continue to use firefox. I will not (co)maintain any of the mentioned browsers. You will, so you decide. I just wrote to let you know what me and other present consumers of KDE SIG's work think and use (at least those I know, some may think differently).
Michal
On Mon, Mar 31, 2014 at 08:10:25PM +0200, Kevin Kofler wrote:
Michal Hlavinka wrote:
I use tabs in firefox as my todo-list (with extra addons to make sure I don't lose it). Right now I have 480+ tabs. Firefox is still working, it is fast and memory consumption is reasonable.
This is clear abuse of the web browser, not the common usage pattern. I'm surprised that ANY browser supports that kind of abuse. (Especially Firefox used to get criticized for excessive memory requirements by people like you opening hundreds of tabs.) I don't think this should be a requirement for our default browser.
common usage pattern for me: few hundred tabs, browse untill browser inevitably crashes, restart and continue happilly again. Extensions to delete all but a few select cookies periodicaly and very frequently, certificet patrol, nocript, adblock, vimperator, greasemonkey.
Curious which plugin Michal uses to count the open tabs?
Current Firefox is quite miserable and easy to crash on Fedora - suffice to open some images of dimensions like 10000x10000 pixels and it won't take long. Both the browser and X should handle this or at least have safeguards.
Richard
--- Name and OpenPGP keys available from pgp key servers
I wrote:
The discussion of what should be the default browser on the Plasma Product has come up yesterday, and I strongly believe that Firefox is NOT the answer (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
2 more: * Firefox takes a lot more space on the live image than a browser that reuses KDE components. The firefox package is 50 MiB compressed, that's 10 times the size of Rekonq, 25 times the size of Konqueror. And that does not even include the dependencies, which you also have to add. * http://en.wikipedia.org/wiki/Brendan_Eich#Proposition_8_donation
Kevin Kofler
I had to stop and think about this for a bit...
Everyone had something valid to say. I think the important question is who is going to be your target audience for the live cd.
----------------------------------------------------- If you're talking about us, the regular subscribed to this mailinig list kde user ----------------------------------------------------- We all know about the shortcomings of Konqueror or Rekonq. And we know that we can install an alternative browser. We are all convinced as to how great kde is as a desktop environment and if we need to use the live CD we would more than likely be prepared to live with the shortcomings of the browser and install the alternative if required.
------------------------------------------------------- If you're talking about the uninitiated, those new to kde or fedora or linux or any combination of the the three. ------------------------------------------------------- The browser experience can make or break a users experience. If a new user boots up the kde live cd and finds that they are not able to fully enjoy their favorite website then many will reject what is offered by the CD. It is a hard enough sell without Flash installed (understandable given the licensing issues and Fedora's policy,) but if the browser renders in an unacceptable way, or crashes.....
Besides all that.... KDE has not worked well on older systems for a very very long time. What I mean by that, is as quick as it should. That being said and regarding relatively newer systems who uses CDs anymore. I know that it is a source of pride for Linux distros to fit in the most features in as compact a space as possible, but I have to ask, is that really relevant when it comes to KDE. Wouldn't it be better to have a live DVD, instead of a live CD. And you can then give the users of kde / plasma live a choice: Libreoffice or Calligra; Konqueror or Rekonq or Firefox. Maybe through in a few multimedia players for good measure.
Anyway.... that's my 2âµ worth
Eli
-
Eli Wapniarski -
Felix Miata -
g -
Kevin Kofler -
Markus Slopianka -
Matthew Miller -
Michal Hlavinka -
Patrick O'Callaghan -
Reindl Harald -
Rex Dieter -
Richard Z -
Timothy Murphy