In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Advantages and features include: * based on same rendering engine as qtwebengine (that qupzilla uses) * has active, well-supported upstream * some kde integration: kde file dialogs, kwallet for secrets * supports most chrome addons/extensions
Disadvantages include: * pretty new to fedora (only a few weeks) * packaging/buildsystem is... messy and fragile (not unique here, qtwebengine suffers similarly but less so) * not 100% native (like qupzilla)
-- Rex
On Sun, Aug 7, 2016 at 8:35 AM, Rex Dieter rdieter@math.unl.edu wrote:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Advantages and features include:
- based on same rendering engine as qtwebengine (that qupzilla uses)
- has active, well-supported upstream
- some kde integration: kde file dialogs, kwallet for secrets
- supports most chrome addons/extensions
Disadvantages include:
- pretty new to fedora (only a few weeks)
- packaging/buildsystem is... messy and fragile (not unique here,
qtwebengine suffers similarly but less so)
- not 100% native (like qupzilla)
My biggest concern among all the choices is the multimedia support. Fedora cannot ship a full-featured codec stack in any of its spins due to various legal issues. How do the browsers compare for the Fedora user who wants to get more codec support himself?
Neal Gompa wrote:
My biggest concern among all the choices is the multimedia support. Fedora cannot ship a full-featured codec stack in any of its spins due to various legal issues.
Means, it's not an issue specific to any browser (they all suffer similarly), so probably will be a minor issue in *this* decision-making, imo.
How do the browsers compare for the Fedora user who wants to get more
codec support himself?
That said, firefox (or any browser utilizing gstreamer) has a slight edge here, due to https://fedoraproject.org/wiki/OpenH264
but that's still not great nor a 100% solution, outside of using patented stuff from rpmfusion.org.
-- Rex
Rex Dieter ha scritto:
Neal Gompa wrote:
My biggest concern among all the choices is the multimedia support. Fedora cannot ship a full-featured codec stack in any of its spins due to various legal issues.
Means, it's not an issue specific to any browser (they all suffer similarly), so probably will be a minor issue in *this* decision-making, imo.
How do the browsers compare for the Fedora user who wants to get more
codec support himself?
That said, firefox (or any browser utilizing gstreamer) has a slight edge here, due to https://fedoraproject.org/wiki/OpenH264
but that's still not great nor a 100% solution, outside of using patented stuff from rpmfusion.org.
And Firefox is deprecating gstreamer anyway in favor of direct ffmpeg usage. So all browsers are in the same status. My personal speculation about this is that the solution. if it comes, will be the same for all browsers, but this is orthogonal to this discussion.
Ciao
On Sun, Aug 7, 2016 at 9:03 AM, Rex Dieter rdieter@math.unl.edu wrote:
Neal Gompa wrote:
My biggest concern among all the choices is the multimedia support. Fedora cannot ship a full-featured codec stack in any of its spins due to various legal issues.
Means, it's not an issue specific to any browser (they all suffer similarly), so probably will be a minor issue in *this* decision-making, imo.
That's not quite true. For example, Chromium is built with a bundled custom ffmpeg, and it's not split out into its own subpackage, meaning that there's no way to replace it without having to rebuild all of Chromium. Chromium is hard to build and harder for users to build.
Since we don't have a system-wide ffmpeg package, I assume we have the same problem with QtWebEngine, too. That affects every QtWebEngine based browser.
How do the browsers compare for the Fedora user who wants to get more
codec support himself?
That said, firefox (or any browser utilizing gstreamer) has a slight edge here, due to https://fedoraproject.org/wiki/OpenH264
but that's still not great nor a 100% solution, outside of using patented stuff from rpmfusion.org.
As of Fedora 24, Firefox does not use GStreamer. The Mozilla community decided to remove it. Apparently, no one thought it was any good.
I seem to recall that QtWebKit could be used with GStreamer. Do we have any web browsers that use QtWebKit, Qt5, and GStreamer?
On 08/07/2016 03:12 PM, Neal Gompa wrote:
On Sun, Aug 7, 2016 at 9:03 AM, Rex Dieter rdieter@math.unl.edu wrote:
Neal Gompa wrote:
My biggest concern among all the choices is the multimedia support. Fedora cannot ship a full-featured codec stack in any of its spins due to various legal issues.
Means, it's not an issue specific to any browser (they all suffer similarly), so probably will be a minor issue in *this* decision-making, imo.
That's not quite true. For example, Chromium is built with a bundled custom ffmpeg, and it's not split out into its own subpackage, meaning that there's no way to replace it without having to rebuild all of Chromium. Chromium is hard to build and harder for users to build.
Since we don't have a system-wide ffmpeg package, I assume we have the same problem with QtWebEngine, too. That affects every QtWebEngine based browser.
Well, for QtWebEngine it should be possible to add a nonfree version to rpmfusion. No need to rebuilt QupZilla. Already tested locally. We just have to find a way to coexist with Fedora package.
How do the browsers compare for the Fedora user who wants to get more
codec support himself?
That said, firefox (or any browser utilizing gstreamer) has a slight edge here, due to https://fedoraproject.org/wiki/OpenH264
but that's still not great nor a 100% solution, outside of using patented stuff from rpmfusion.org.
As of Fedora 24, Firefox does not use GStreamer. The Mozilla community decided to remove it. Apparently, no one thought it was any good.
I seem to recall that QtWebKit could be used with GStreamer. Do we have any web browsers that use QtWebKit, Qt5, and GStreamer?
Yes, there is otter-browser. But QtWebKit is obsolete and lacks several security fixes. I read about a fork of QtWebKit some weeks ago, but nothing official (yet?).
Greetings, Christian
Christian Dersch ha scritto:
Yes, there is otter-browser. But QtWebKit is obsolete and lacks several security fixes. I read about a fork of QtWebKit some weeks ago, but nothing official (yet?).
Those are the last news I read: http://lists.qt-project.org/pipermail/development/2016-June/026156.html (the thread) http://lists.qt-project.org/pipermail/development/2016-June/026282.html
Neal Gompa wrote:
That said, firefox (or any browser utilizing gstreamer) has a slight edge here, due to https://fedoraproject.org/wiki/OpenH264
but that's still not great nor a 100% solution, outside of using patented stuff from rpmfusion.org.
As of Fedora 24, Firefox does not use GStreamer. The Mozilla community decided to remove it. Apparently, no one thought it was any good.
Read the link (again). There's a firefox plugin *and* gstreamer support for openh264.
-- Rex
Neal Gompa wrote:
My biggest concern among all the choices is the multimedia support. Fedora cannot ship a full-featured codec stack in any of its spins due to various legal issues. How do the browsers compare for the Fedora user who wants to get more codec support himself?
Both Chromium and QtWebEngine really need rebuilding to pick up not only an FFmpeg with all the codecs, but also the Chromium "proprietary_codecs" build flag that affects the hardcoded list of supported codecs. (Without the flag, it uses a short hardcoded list of unencumbered codecs, with the flag, it uses a longer hardcoded list that also contains patent-encumbered ones. The decision should really be made at runtime and per codec, but that's not how things work at this time.)
There is a Chromium GStreamer backend by Samsung, but it is a quite invasive patch that is not packaged for Fedora at this time, neither in Chromium nor in QtWebEngine. As I wrote in the QupZilla thread: | I had hoped to get GStreamer support working, but that is more work to get | going, I need changes in GStreamer packaging that have not been applied | yet, and a fix for the aforementioned compile-time hardcoding (which also | affects the GStreamer backend, see | https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), and then | also testing with QtWebEngine (the GStreamer code was only ever tested | with vanilla Chromium). So this is something for the future. For now, a | rebuild of QtWebEngine with an uncensored FFmpeg in a third-party | repository is the best that can be done.
But Chromium and QtWebEngine are in the same situation there, both rely on a bundled FFmpeg. And at the application level, as Christian Dersch pointed out, QupZilla has a slight advantage because you can override the QtWebEngine library without touching the QupZilla application.
Kevin Kofler
On Sun, Aug 7, 2016 at 5:35 AM, Rex Dieter rdieter@math.unl.edu wrote:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Disclosure: I'm a extensive user of Chrome and very much tied into the Google ecosystem.
I believe first that someone needs to clarify a bit on what we're trying to do here. What is the criteria for the Fedora default browser. At a very high simplistic level, if we're wanting something Qt'ish then the answer is qupzilla... if we're looking for something that would attract more Chrome users - then it would be Chromium.
Whichever it is, we need to make sure that it is kept current. I don't want to be stuck at Chromium 52 when Chrome 53 has been released.
Another thing to keep in mind is compatibility. Check out the bug I created here: https://bugzilla.redhat.com/show_bug.cgi?id=1361404
It's related to the use of Google Music. Yes, I know that everyone might not use it, but it shows the quirkiness of the current version of Chromium in Fedora. To be fair, I did find the same issue in the current stable version of Vivaldi - but, it has since been fixed in the beta versions. As I noted in the bug report... it works perfectly fine in current version of qupzilla and the Chromium version in the russian fedora repo. This is not a slam, but the inability to identify and resolve an issue with Google Music in Chromium of all things, especially when it is working in qupzilla is a bit concerning.
As much as I'm a cheerleader for all things chrome, I wouldn't choose it to be a default without these things resolved - and saying that "Chromium is complicated" doesn't give it a pass.
Gerald B. Cox wrote:
I believe first that someone needs to clarify a bit on what we're trying to do here. What is the criteria for the Fedora default browser.
That may be part of our problem, but *to me*, the primary criteria is simply the answer to: Which browser gives the best general browsing experience on plasma?
-- Rex
On Sun, Aug 7, 2016 at 9:38 AM, Rex Dieter rdieter@math.unl.edu wrote:
I believe first that someone needs to clarify a bit on what we're trying to do here. What is the criteria for the Fedora default browser.
That may be part of our problem, but *to me*, the primary criteria is simply the answer to: Which browser gives the best general browsing experience on plasma?
ROFL... well, the answer is Chrome of course... but since that isn't possible, at this point in time, I would say Qupzilla. I'm not getting a warm and fuzzy about the current Chromium in the Fedora repository. If basic Chrome capabilities (Google Music) aren't working you are just going to frustrate people - especially those coming from Chrome - and that also raises the question of what else isn't working?
This isn't intended to be a slam to Tom, but if he doesn't yet understand what is going on then it isn't fair to him to make the browser the default and then have a bunch of people screaming because it is not working as it should.
Gerald B. Cox wrote:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Isn't Google Chrome free? (Is Firefox free?) What exactly is the advantage of Chromium over Chrome?
On 08/08/2016 12:28 PM, Timothy Murphy wrote:
Gerald B. Cox wrote:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Isn't Google Chrome free? (Is Firefox free?) What exactly is the advantage of Chromium over Chrome?
Chromium, Firefox and QupZilla are not only free as in free beer but also free as in free speach ;) Chrome is just free as in free beer as it contains nonfree stuff like Flash.
Christian Dersch wrote:
Chromium, Firefox and QupZilla are not only free as in free beer but also free as in free speach ;) Chrome is just free as in free beer as it contains nonfree stuff like Flash.
And even the code from Chromium is (re)licensed under a proprietary license in Chrome. Google can do that because they own the copyright of Chromium.
Kevin Kofler
Rex Dieter wrote:
Advantages and features include:
- based on same rendering engine as qtwebengine (that qupzilla uses)
So why not use the native adaptation (QupZilla) instead?
- has active, well-supported upstream
So do QtWebEngine and QupZilla.
- some kde integration: kde file dialogs, kwallet for secrets
QupZilla has those too, and in addition, a more native look&feel, by using Qt rather than Aura or GTK+.
- supports most chrome addons/extensions
That's the only thing that could make users prefer Chromium. I think that should not be the killer argument. The point of a web browser is still to browse the web, not to host extensions. :-)
Disadvantages include:
- pretty new to fedora (only a few weeks)
By that very same argument, the stable QupZilla 2.0.0 and QtWebEngine 5.6.0 releases were rejected as a default for Fedora 24.
- packaging/buildsystem is... messy and fragile (not unique here,
qtwebengine suffers similarly but less so)
"but less so" indeed: QtWebEngine builds less of the bundled junk than Chromium, and a lot of the gyp PITA is hidden behind a more usable qmake project.
- not 100% native (like qupzilla)
Right, and as I mentioned above, this directly affects the look&feel the user will see. Chromium does not look native at all, and probably also feels different from a Qt application to most users. Just look at the title bar, the icons, the widget style, etc.
Kevin Kofler
Kevin Kofler composed on 2016-08-07 23:37 (UTC+0200):
Rex Dieter wrote:
Advantages and features include:
- based on same rendering engine as qtwebengine (that qupzilla uses)
So why not use the native adaptation (QupZilla) instead?
- has active, well-supported upstream
So do QtWebEngine and QupZilla.
- some kde integration: kde file dialogs, kwallet for secrets
QupZilla has those too, and in addition, a more native look&feel, by using Qt rather than Aura or GTK+.
- supports most chrome addons/extensions
That's the only thing that could make users prefer Chromium. I think that should not be the killer argument. The point of a web browser is still to browse the web, not to host extensions. :-)
A high proportion of extension functionality here serves the purpose of restoring functionality (compared to Netscape/Mozilla Suite/SeaMonkey) lost or rearranged or adding requested-via-BMO but never acquired.
Disadvantages include:
- pretty new to fedora (only a few weeks)
By that very same argument, the stable QupZilla 2.0.0 and QtWebEngine 5.6.0 releases were rejected as a default for Fedora 24.
- packaging/buildsystem is... messy and fragile (not unique here,
qtwebengine suffers similarly but less so)
"but less so" indeed: QtWebEngine builds less of the bundled junk than Chromium, and a lot of the gyp PITA is hidden behind a more usable qmake project.
- not 100% native (like qupzilla)
Right, and as I mentioned above, this directly affects the look&feel the user will see. Chromium does not look native at all, and probably also feels different from a Qt application to most users. Just look at the title bar, the icons, the widget style, etc.
I'd never opened QupZilla before now. Opened in F24 without making any attempt to locate or install any option, plugins, extensions, etc., I don't see anything but disadvantages compared to FF, and very little to recommend it over Chromium: http://fm.no-ip.com/SS/Fedora/ff45vqz201chr52-f24-120.jpg
1-Like other non-Gecko, non-KHTML browsers, both cannot be made to obey DPI (meaning accurate physical sizes in their viewports are impossible unless the displays' physical DPI is exactly 96).
2-Abundant space wasted wasted making tabs easy to close by accident in both.
3-Main menubar is undiscoverable in both.
4-Search bar is too narrow in both.
5-UI text is not black (as is FF in obeying Plasma desktop settings) in QZ.
6-UI text font family is not as specified in Plasma's desktop settings (seems to be Oxygen rather than Droid) in QZ.
7-QZ Sticks new "hidden" directories in $HOME at top by capitalizing first letters.
8-Scrollbar is too narrow in both.
9-Same minimalist inadequately emboldened stick-figure icons as displeases me about Plasma 5 generally, though arguably better than the barely big enough to target FF native icons.
10-QZ (only) misreports window width.
11-Chrom's urlbar text is too small.
12-Text size buttons missing in both.
If the best user experience is really the goal, FF with a theme custom made for Plasma and Fedora is probably the best target to shoot for.
In any event, under this roof, usability trumps appearance always. #1 alone is enough to shoot down anything running on WebKit or Blink engines. The only times I've ever opened Chrom* is to compare behavior to other browsers. Too much functionality is missing to use either it for normal browsing. QZ doesn't look much better.
Felix Miata wrote:
A high proportion of extension functionality here serves the purpose of restoring functionality (compared to Netscape/Mozilla Suite/SeaMonkey) lost or rearranged or adding requested-via-BMO but never acquired.
Well, QupZilla tries to offer such functionality (e.g., ad blocking) out of the box, either built-in or as extensions included with QupZilla. There may be some things missing in 2.0.x, which is the first release series for QtWebEngine, but both QtWebEngine and QupZilla are getting new features over time.
It is also possible to develop third-party extensions against QupZilla, so if you are missing some functionality, it can be implemented, and then submitted for inclusion with QupZilla itself.
Are there any concrete extensions that you (or other users here) would like?
I'd never opened QupZilla before now. Opened in F24 without making any attempt to locate or install any option, plugins, extensions, etc., I don't see anything but disadvantages compared to FF, and very little to recommend it over Chromium: http://fm.no-ip.com/SS/Fedora/ff45vqz201chr52-f24-120.jpg
1-Like other non-Gecko, non-KHTML browsers, both cannot be made to obey DPI (meaning accurate physical sizes in their viewports are impossible unless the displays' physical DPI is exactly 96).
That is really a flaw in the HTML 5 spec, it is not fair to blame the browser for it.
2-Abundant space wasted wasted making tabs easy to close by accident in both.
IMHO, having the tab close button on the tab is much more intuitive UI. And whether you like it or not, it is also the way Breeze tabs are supposed to look like (UI consistency).
3-Main menubar is undiscoverable in both.
Doesn't Firefox default to the same UI solution (popup menu button) these days? You probably have a very old Firefox profile. Please compare default settings.
QupZilla has a preference to enable the traditional menu bar. If there is consensus that this should be the way it should look, I can enable it by default in our package. (I also prefer the traditional menu bar, and it is consistent with most other applications, though the popup button disease is slowly spreading.) It is just a boolean option to flip.
4-Search bar is too narrow in both.
Of your 3 screenshots, QupZilla is the only one whose search bar is easily discoverable. Firefox hides it in the menu bar (!!!) (that's a VERY non- standard UI; and is this even the default setting to begin with?), and Chromium hides it I don't know where (it's the worst).
Still, sadly, none of the 3 can compete with Konqueror's convenient web shortcuts feature that allowed to search with arbitrary search engines directly from the location bar (e.g., gg:foo). (That said, if you enter something that is not a URL into QupZilla's location bar, it will by default search for it in the default search engine. This behavior can be disabled in the preferences.) It should not be too hard to add web shortcuts to the QupZilla code though, if one of us is bored. :-) Given that it's Qt-based, you can probably just port the code from Konqueror, including the configuration UI. But for now, this is not an argument for any of the 3 options, given that they all don't support it.
5-UI text is not black (as is FF in obeying Plasma desktop settings) in QZ.
6-UI text font family is not as specified in Plasma's desktop settings (seems to be Oxygen rather than Droid) in QZ.
For 5, you mean bold, right? These are both the same issue. Somehow, font settings are not being picked up. This is a bug somewhere. I'll look into it. Either QupZilla hardcodes something, or the Plasma platform plugin for Qt is getting something wrong. It is clearly not what should happen.
7-QZ Sticks new "hidden" directories in $HOME at top by capitalizing first letters.
That's because the browser is called "QupZilla", not "qupzilla". :-) Also, blame your file manager that sorts case-sensitively.
That said, the stuff should probably be put into something like ~/.local/share these days. I'll take that up with upstream.
8-Scrollbar is too narrow in both.
This is a matter of taste.
9-Same minimalist inadequately emboldened stick-figure icons as displeases me about Plasma 5 generally, though arguably better than the barely big enough to target FF native icons.
If you change your Plasma icon theme (e.g., to Oxygen), QupZilla will pick that up (unless it is affected by the same bug as the fonts). The default "Linux" theme uses system icons, not hardcoded ones.
10-QZ (only) misreports window width.
That's an interesting bug, it should be filed upstream. (It's clearly a bug.)
11-Chrom's urlbar text is too small.
Indeed. QupZilla's is not. :-p
12-Text size buttons missing in both.
Most people do not use those, except by accident.
If the best user experience is really the goal, FF with a theme custom made for Plasma and Fedora is probably the best target to shoot for.
A theme cannot solve integration issues such as non-native file dialogs.
In any event, under this roof, usability trumps appearance always. #1 alone is enough to shoot down anything running on WebKit or Blink engines. The only times I've ever opened Chrom* is to compare behavior to other browsers. Too much functionality is missing to use either it for normal browsing. QZ doesn't look much better.
You are the only one who cares about #1. The HTML 5 spec says that browsers should behave the "wrong" way, so that's just how things are these days. I don't see how that should be the reason to pick a browser over another.
If you really care that much about the DPI issue, I am looking forward to your QtWebEngine patch that implements it (optionally of course, or you break HTML 5 standard compliance). :-p
Kevin Kofler
Am 08.08.2016 um 14:21 schrieb Kevin Kofler:
IMHO, having the tab close button on the tab is much more intuitive UI. And whether you like it or not, it is also the way Breeze tabs are supposed to look like (UI consistency)
one reason more for not using breeze.....
as you don't need a button for context menu (right click) you don't need one for close tabs (middle click)
Kevin Kofler composed on 2016-08-08 14:21 (UTC+0200):
Felix Miata wrote:
A high proportion of extension functionality here serves the purpose of restoring functionality (compared to Netscape/Mozilla Suite/SeaMonkey) lost or rearranged or adding requested-via-BMO but never acquired.
Well, QupZilla tries to offer such functionality (e.g., ad blocking) out of the box, either built-in or as extensions included with QupZilla. There may be some things missing in 2.0.x, which is the first release series for QtWebEngine, but both QtWebEngine and QupZilla are getting new features over time.
It is also possible to develop third-party extensions against QupZilla, so if you are missing some functionality, it can be implemented, and then submitted for inclusion with QupZilla itself.
Are there any concrete extensions that you (or other users here) would like?
These are those installed in my primary Firefox profile: Classic Theme Restorer DOM Inspector Preserve Download Modification Timestamp
Whether anything corresponding to them exists for WebKit and/or Blink browsers I have no idea. My computers are tools, not playtoys. My Mozilla browsers are already understood and configured over a decade and use, little by little, as required. Learning how to deal with new minimalist interfaces that supposedly can displace a great already working toolset is just not a priority.
I'd never opened QupZilla before now. Opened in F24 without making any attempt to locate or install any option, plugins, extensions, etc., I don't see anything but disadvantages compared to FF, and very little to recommend it over Chromium: http://fm.no-ip.com/SS/Fedora/ff45vqz201chr52-f24-120.jpg
1-Like other non-Gecko, non-KHTML browsers, both cannot be made to obey DPI (meaning accurate physical sizes in their viewports are impossible unless the displays' physical DPI is exactly 96).
That is really a flaw in the HTML 5 spec, it is not fair to blame the browser for it.
Actually it is. It was the people driving M$, WebKit and Blink that outpowered the Mozilla people getting the idiotic feature loss into the CSS spec. Mozilla only acquiesced out of the necessity for compat, and incompletely so, in order to serve those dependent on existing behavior. Meanwhile, in falling way behind the others, KHTML hasn't dumped this support, and it's still available for Konq users who can tolerate other support it lacks.
2-Abundant space wasted wasted making tabs easy to close by accident in both.
IMHO, having the tab close button on the tab is much more intuitive UI.
It's only intuitive when it fits. That screenshot was not a very representative example of life here. Upwards of 20 open tabs is normal, and there's simply not room for enough letters to be useful and a tab button.
And no matter how intuitive youngsters think it is, older people like me don't have youthful dexterity that allows a mouse pointer to remain still while an old jerky hand tries to click a relatively small target to focus it that is adjacent to an almost entirely opposite make it disappear target.
And whether you like it or not, it is also the way Breeze tabs are supposed to look like (UI consistency).
I can't offhand think of any Breeze characteristics that are an improvement over default KDE3 or KDE4 theming.
3-Main menubar is undiscoverable in both.
Doesn't Firefox default to the same UI solution (popup menu button) these days? You probably have a very old Firefox profile. Please compare default settings.
Absolutely not. Those are missing features in the others. I have lots of profiles. It's already a lot of working fixing the brokenness of too frequent UI paradigm changes.
QupZilla has a preference to enable the traditional menu bar. If there is
I looked for that right away, and couldn't find any such.
consensus that this should be the way it should look, I can enable it by
Like I said already, how it works trumps how it looks.
default in our package. (I also prefer the traditional menu bar, and it is consistent with most other applications, though the popup button disease is slowly spreading.) It is just a boolean option to flip.
Where?
4-Search bar is too narrow in both.
Of your 3 screenshots, QupZilla is the only one whose search bar is easily discoverable. Firefox hides it in the menu bar (!!!) (that's a VERY non- standard UI;
That move was precipitated by the tabs on top chromification, shortly followed by hiding the main menubar altogether, which included moving virtually all the tools from the top left to the top right of the window, regressions all.
and is this even the default setting to begin with?), and Chromium hides it I don't know where (it's the worst).
Of course it's not in the default. The defaults now are mostly usability regressions in order to make Firefox look like the minimalist browsers whose development is coerced by the pecuniary interests of huge corporations rather than by an involved user community. Browsers are intended to be *used* overwhelmingly by *users*, not website hosts or mega software or marketing corporations.
5-UI text is not black (as is FF in obeying Plasma desktop settings) in QZ.
6-UI text font family is not as specified in Plasma's desktop settings (seems to be Oxygen rather than Droid) in QZ.
For 5, you mean bold, right?
None of the UI fonts in that screenshot are bold. At 120 DPI, 10pt fonts calculate to 16.667px, which means 17px glyphs are used, and the stem weight on the Droid fonts used by FF and Chromium have apparently made the transition from 1px that smaller screen fonts are cursed with to 2px nominal that happens around 17px-18px.
The main problem with too many newer fonts is their modern minimalist look that incorporates a demi-ish stroking in their design.
De-uglification of screen fonts is simplified by raising (either logical and/or physical) screen density so that fonts of any given physical size require more px to render. With enough raise of screen density, the bytecode, anti-alias and hinting kludging becomes unnecessary. Fonts look good simply because enough pixels are used to make them look much better, even good, and with the best available screens, almost indistinguishable from printer fonts.
These are both the same issue. Somehow, font settings are not being picked up. This is a bug somewhere. I'll look into it. Either QupZilla hardcodes something, or the Plasma platform plugin for Qt is getting something wrong. It is clearly not what should happen.
Clearly.
Much as I prefer QT to other toolkits, Apple's control over it makes me wish it wasn't the only serious alternative to GTK, and wonder how much how much of Plasma shortcomings that depend on QT aren't insidious intentions of Apple.
7-QZ Sticks new "hidden" directories in $HOME at top by capitalizing first letters.
That's because the browser is called "QupZilla", not "qupzilla". :-)
Mozilla profiles aren't in ~/.Mozilla. KDE4 stuff wasn't in ~/.Kde. LibreOffice stuff isn't in ~/.LibreOffice. Gnome stuff isn't in ~/.Gnome. qupzilla-2.0.1-1.fc25.x86_64.rpm isn't QupZilla-2.0.1-1.fc25.x86_64.rpm. /usr/bin/qupzilla isn't /usr/bin/QupZilla.
Also, blame your file manager that sorts case-sensitively.
One of the few things I like about non-native filesystems is case insensitive sorting. Maybe MC has that option and I've simply never found it.
That said, the stuff should probably be put into something like ~/.local/share these days. I'll take that up with upstream.
Those look like things that probably belong as subdirs in ~/.config, which Plasma devs have made a mess out of. :-(
8-Scrollbar is too narrow in both.
This is a matter of taste.
Also a matter of u7y and a11y. It's narrower than previously, while screens have grown much wider. Why? Don't devs know people >40 use computers too? Do they know people >40 mostly can't see or control a mouse pointer like they could as teens?
12-Text size buttons missing in both.
Most people do not use those, except by accident.
Young people with good eyes, and those that don't know. It should not be by accident. Better to have the usability built in rather than make people have to figure out usability must be added on.
If the best user experience is really the goal, FF with a theme custom made for Plasma and Fedora is probably the best target to shoot for.
A theme cannot solve integration issues such as non-native file dialogs.
Oh? Maybe the native file dialogs are the problem anyway? Best file dialog I'm familiar with was written roughly 30 years ago, still usable only with OS/2 and eComStation, with AFAIK no access to either its author or its source code.
In any event, under this roof, usability trumps appearance always. #1 alone is enough to shoot down anything running on WebKit or Blink engines. The only times I've ever opened Chrom* is to compare behavior to other browsers. Too much functionality is missing to use either it for normal browsing. QZ doesn't look much better.
You are the only one who cares about #1. The HTML 5 spec says that browsers should behave the "wrong" way, so that's just how things are these days. I don't see how that should be the reason to pick a browser over another.
Everyone one is not a member of a majority. Limiting options to only those welcomed by a majority is not a positive characteristic that belongs a part of FOSS.
Other people who might care are mostly too busy fighting unnecessary impediments to use, often leaving computing entirely, or not even trying, because the impediments are just too much work to overcome to be able to find out they would care. Computers are supposed to make things easier and/or enable things otherwise impossible or impractical. That a typical PC cannot automatically and readily display an object at a specific physical size is ludicrous.
If you really care that much about the DPI issue, I am looking forward to your QtWebEngine patch
I learned decades ago that I was made to be facile in only one language. That means all the myriad of computer programming languages are in no-fly zones.
that implements it (optionally of course, or you break HTML 5 standard compliance). :-p
Mozilla found a way to offer multiple kinds of compliance, with (idiotic corporately dictated) modern standards, and with backwards compat and user expectations.
On Mon, Aug 8, 2016 at 7:32 PM, Felix Miata mrmazda@earthlink.net wrote:
Whether anything corresponding to them exists for WebKit and/or Blink browsers I have no idea. My computers are tools, not playtoys. My Mozilla browsers are already understood and configured over a decade and use, little by little, as required. Learning how to deal with new minimalist interfaces that supposedly can displace a great already working toolset is just not a priority.
Changing the browser default will not remove or otherwise make it unavailable for your installation. People who have a preference for one browser or another will still be able to use their browser of choice... quite easily in fact. I view this action as an opportunity to give some well deserved exposure to a browser that makes use of kde based technologies. Seems to me that should be part of our mission. Firefox and Chrome/Chromium are both well established and known.
Felix Miata wrote:
Doesn't Firefox default to the same UI solution (popup menu button) these days? You probably have a very old Firefox profile. Please compare default settings.
Absolutely not. Those are missing features in the others. I have lots of profiles. It's already a lot of working fixing the brokenness of too frequent UI paradigm changes.
How is it fair to compare a Firefox tuned to your liking for "over a decade" (as you wrote in another paragraph) to a QupZilla with default settings that you made almost no attempt at customizing?
QupZilla has a preference to enable the traditional menu bar. If there is
I looked for that right away, and couldn't find any such.
Either: a) right-click on a button or an empty space of the main toolbar, "Menu Bar" or: b) click on the menu popup button, View, Toolbars, Menu Bar will do it.
consensus that this should be the way it should look, I can enable it by
Like I said already, how it works trumps how it looks.
I mean the way how it should look and feel.
default in our package. (I also prefer the traditional menu bar, and it is consistent with most other applications, though the popup button disease is slowly spreading.) It is just a boolean option to flip.
Where?
See above. Or if we want to flip the default, it would be a boolean in the C++ code, but that's no longer your problem then.
None of the UI fonts in that screenshot are bold. At 120 DPI, 10pt fonts calculate to 16.667px, which means 17px glyphs are used, and the stem weight on the Droid fonts used by FF and Chromium have apparently made the transition from 1px that smaller screen fonts are cursed with to 2px nominal that happens around 17px-18px.
So this is really about different hinting settings between different toolkits? I think that what you are seeing *is* the same font family (it has been confirmed that QupZilla picks up the Plasma font settings just fine), it is just being rendered differently.
If you uploaded your screenshot as a lossless PNG rather than a very low- quality JPG, I would also be able to analyze the rendering differences in a better way. (Right now, I cannot see what, if any, anti-aliasing is being done in either case, because the JPEG artefacts eat it all up.)
Much as I prefer QT to other toolkits, Apple's control over it makes me wish it wasn't the only serious alternative to GTK, and wonder how much how much of Plasma shortcomings that depend on QT aren't insidious intentions of Apple.
Huh??? The only part of Qt that Apple had any control over was the now deprecated and community-maintained QtWebKit (where Apple was upstream). Apple controls "QT" as in QuickTime, which has absolutely nothing to do with Qt. (Apple QuickTime is proprietary software and as such not even included in Fedora.)
Kevin Kofler
Am 09.08.2016 um 13:48 schrieb Kevin Kofler:
Felix Miata wrote:
Much as I prefer QT to other toolkits, Apple's control over it makes me wish it wasn't the only serious alternative to GTK, and wonder how much how much of Plasma shortcomings that depend on QT aren't insidious intentions of Apple.
Huh??? The only part of Qt that Apple had any control over was the now deprecated and community-maintained QtWebKit (where Apple was upstream). Apple controls "QT" as in QuickTime, which has absolutely nothing to do with Qt. (Apple QuickTime is proprietary software and as such not even included in Fedora.)
+1000
Kevin Kofler composed on 2016-08-09 13:48 (UTC+0200):
Felix Miata wrote:
How is it fair to compare a Firefox tuned to your liking for "over a decade"
There's no incentive to replace an existing tool with some other tool unless it can do equally well what the old tool did and does in its current state. It may be free as in "FOSS", but relearning is not free.
(as you wrote in another paragraph) to a QupZilla with default settings that you made almost no attempt at customizing?
That isn't what I did. I went through all QZ settings I could find trying to find every possible one that would make it work, including UI layout, as much a possible like the tool I'm used to using.
QupZilla has a preference to enable the traditional menu bar. If there is
I looked for that right away, and couldn't find any such.
Either: a) right-click on a button or an empty space of the main toolbar, "Menu Bar"
That's what I did on the intelgfx F24 installation I was using at that time that produced no observable effect. It turns out what I was apparently up against was that the target areas are so tiny that I kept missing them. Eventually I got a hit in an appropriate spot.
If you uploaded your screenshot as a lossless PNG rather than a very low- quality JPG, I would also be able to analyze the rendering differences in a better way. (Right now, I cannot see what, if any, anti-aliasing is being done in either case, because the JPEG artefacts eat it all up.)
Nothing relevant to seeing that a material difference existed between them was lost by exporting to jpg to shrink the filesize.
ATM, trying compare on my latest updated F25 installation is broken: http://fm.no-ip.com/SS/Fedora/ff45ff48qz201-f25-168.jpg
1-Newly installed, so with a virgin profile, QZ won't open any web pages, and crashes trying to coerce it into doing so. The only way I can get any URL into its urlbar is to type it into prefs as home page and make QZ startup showing the home page. It's reload/stop button doesn't do anything.
2-Now that it's being built with GTK3, Firefox latest UI is unusable in Plasma, absent some available theme I don't know exists that would make it obey DE font settings.
3-Same screenshot demonstrates that what I previously mentioned about FF scrollbars being too narrow actually applies to the whole of Plasma. The scroller in the X-Server window is much too narrow, but then all button icons are too small too. Look & Feel is set to default F24. Desktop them was set to Air, but switching to F24 doesn't help. Neither does Oxygen.
On 08/09/2016 10:13 PM, Felix Miata wrote:
Kevin Kofler composed on 2016-08-09 13:48 (UTC+0200):
Felix Miata wrote:
How is it fair to compare a Firefox tuned to your liking for "over a decade"
There's no incentive to replace an existing tool with some other tool unless it can do equally well what the old tool did and does in its current state. It may be free as in "FOSS", but relearning is not free.
You don't have relearn. Continue to use Firefox even if it isn't the default browser.
<snip>
Patrick Boutilier composed on 2016-08-10 07:26 (UTC-0300):
Felix Miata wrote:
Kevin Kofler composed on 2016-08-09 13:48 (UTC+0200):
Felix Miata wrote:
How is it fair to compare a Firefox tuned to your liking for "over a decade"
There's no incentive to replace an existing tool with some other tool unless it can do equally well what the old tool did and does in its current state. It may be free as in "FOSS", but relearning is not free.
You don't have relearn. Continue to use Firefox even if it isn't the default browser.
What does that have to do with "how is it fair", or comparing supposedly comparable tools generally?
Am 10.08.2016 um 12:45 schrieb Felix Miata:
Patrick Boutilier composed on 2016-08-10 07:26 (UTC-0300):
Felix Miata wrote:
Kevin Kofler composed on 2016-08-09 13:48 (UTC+0200):
Felix Miata wrote:
How is it fair to compare a Firefox tuned to your liking for "over a decade"
There's no incentive to replace an existing tool with some other tool unless it can do equally well what the old tool did and does in its current state. It may be free as in "FOSS", but relearning is not free.
You don't have relearn. Continue to use Firefox even if it isn't the default browser.
What does that have to do with "how is it fair", or comparing supposedly comparable tools generally?
*what* is your exact problem? nobody is taking "dnf install firefox" away from you
following your logic i couldn't use Fedora because it is using networkmanager as default - who cares - it's repalaced within seconds
Reindl Harald composed on 2016-08-10 12:47 (UTC+0200):
*what* is your exact problem? nobody is taking "dnf install firefox" away from you
Several problems with changing to either Chrom* or QZ, among them:
1-Blink is under Google's thumb.
2-WebKit is under Apple's thumb.
Firefox is more like real FOSS.
My primary browser is actually SeaMonkey, but I use FF enough and it's enough like SM that it's not a problem that part of my role is support, which I can't do with either Chrom* or QZ without understanding them, including the full extent of their missing functionality and their very different common extension sets.
Were QZ a QT/Gecko browser it would probably have better potential.
Am 10.08.2016 um 17:26 schrieb Felix Miata:
Reindl Harald composed on 2016-08-10 12:47 (UTC+0200):
*what* is your exact problem? nobody is taking "dnf install firefox" away from you
Several problems with changing to either Chrom* or QZ, among them:
i asked for *your* problem
did you see a proposal to remove dnf or firefox? are you only able to use what is default installed if you are only able to use the default install - why?
1-Blink is under Google's thumb.
nobody forces you to use anything
2-WebKit is under Apple's thumb.
nobody forces you to use anything
Firefox is more like real FOSS.
in theory yes, in reality not really, Mozilla don't care what users are saying like commerical vendors and if it's just a "give me a 'configure manually' option when you get again and agin'no we decided automagic and won't change that' and it's a GTK application with shitty file dialogs and so on
My primary browser is actually SeaMonkey, but I use FF enough and it's enough like SM that it's not a problem that part of my role is support, which I can't do with either Chrom* or QZ without understanding them, including the full extent of their missing functionality and their very different common extension sets.
nobody forces you to use anything you use firefox as i do
Were QZ a QT/Gecko browser it would probably have better potential
what is a QT browser?
when you write these two letters people need to be very careful since you recently accused even the toolkit QT to be owned by Apple while you meant QuickTime which is completly unrealted to any of this topics
Felix Miata wrote:
ATM, trying compare on my latest updated F25 installation is broken: http://fm.no-ip.com/SS/Fedora/ff45ff48qz201-f25-168.jpg
1-Newly installed, so with a virgin profile, QZ won't open any web pages, and crashes trying to coerce it into doing so. The only way I can get any URL into its urlbar is to type it into prefs as home page and make QZ startup showing the home page. It's reload/stop button doesn't do anything.
QupZilla is currently broken in F25 and Rawhide due to 3 bugs in other components. This is being worked on. You can only test on F24 for now.
2-Now that it's being built with GTK3, Firefox latest UI is unusable in Plasma, absent some available theme I don't know exists that would make it obey DE font settings.
Another reason to NOT use Firefox as our default browser!
3-Same screenshot demonstrates that what I previously mentioned about FF scrollbars being too narrow actually applies to the whole of Plasma. The scroller in the X-Server window is much too narrow, but then all button icons are too small too. Look & Feel is set to default F24. Desktop them was set to Air, but switching to F24 doesn't help. Neither does Oxygen.
This shows that QupZilla is following the Plasma look&feel as it should, whereas Firefox is not complying.
Kevin Kofler
On Monday 8 August 2016 3:18:09 AM IST Felix Miata wrote:
If the best user experience is really the goal, FF with a theme custom made for Plasma and Fedora is probably the best target to shoot for.
I don't think Firefox will ever be a good choice for Plasma users. It has a fundamental problem. It's design language that will continue to move away from Plasam's design language.
Irrespective of what is shipped in Plasma spin most people use Chrome. It uses plasma file picker, kwallet intergration, and it's light theme makes it perfectly amalgate with Plasma.
I would be totally fine with Qupzilla too. Our mandate is to promote the best software and experience from Plasma and Qt technologies. I would really like to see a browser that is being actively developed. That has a future.
On Monday, August 8, 2016 3:18:09 AM CEST Felix Miata wrote:
6-UI text font family is not as specified in Plasma's desktop settings (seems to be Oxygen rather than Droid) in QZ.
I cannot reproduce this, when I change the font in system settings, QupZilla adapts them fine here after I restarted it.
Greetings, Christian
Am 29.08.2016 um 13:50 schrieb Richard Z:
On Mon, Aug 08, 2016 at 03:18:09AM -0400, Felix Miata wrote:
10-QZ (only) misreports window width.
isn't that a feature? It is one essential step to prevent browser/user fingerprinting
a really cool feature when it breaks "modern" web-applications - wtf
Richard Z wrote:
On Mon, Aug 08, 2016 at 03:18:09AM -0400, Felix Miata wrote:
10-QZ (only) misreports window width.
isn't that a feature? It is one essential step to prevent browser/user fingerprinting.
Not if it's the only browser doing it, then it can actually be a way to fingerprint it.
I am fairly sure this is not intentional and should be reported to Qt (QtWebEngine) upstream.
Kevin Kofler
On Sunday 7 August 2016 7:35:13 AM IST Rex Dieter wrote:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
I have been trying out Qupzilla since you made this topic. I think it is one awesome browser. It's as fast as Chrome. It fits better in Plasma than Chrome. It has a very clean interface.
I am really enjoying it so far. I would consider it to be a serious contender to Chrome if and when I want to move from Google's turf.
Qupzilla is certainly a very good option for Plasma spin.
On Mon, Aug 8, 2016 at 10:35 AM, Sudhir Khanger ml@sudhirkhanger.com wrote:
I am really enjoying it so far. I would consider it to be a serious contender to Chrome if and when I want to move from Google's turf.
Qupzilla is certainly a very good option for Plasma spin.
Just a followup to my other postings... since things can get lost in an e-mail thread:
There is an issue with the current chromium... it doesn't work with Google Music reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1361404 Problem does NOT occur in qupzilla - check previous postings or the bug report for more info. All other things appear to be ok - but I haven't deep dived since for me that issue alone is a showstopper. It does appear in the current vivaldi stable, but has been fixed in their latest snapshot code. I've requested more information, and hopefully it will be added.
Chromium is at ~.82 - whereas Chrome has been updated to ~.116; if something is going to be the default, it needs to be kept current in a reasonable time frame - in the same manner we do with Firefox, or qupzilla. Browsers simply cannot lag behind. Whomever is the packager of qupzilla, they definitely seem to stay on top of it. ;-)
qupzilla worked with Google Music immediately upon install - apparently it picked up pepperflash from my chrome install - extremely nice touch. With chromium, you have to manually install.
qupzilla doesn't support all the extensions and plugins that chromium does - but as Kevin mentioned it has many features built right in... and it is intended to be a lightweight browser. What really is the point of installing chromium, then going after all the non-free addons - when you could just install chrome?
No, qupzilla isn't perfect... I've been slowly going through all the functions, checking out the built in extensions... found a weird bug in the login manager concerning passwords (which had already been found and reported) - but overall, it's fast, looks great and does a decent job of showing what a QtWebEngine based browser can do.
I don't see myself as being a regular user of Chromium... yes it's great that it has finally made it into the repository, and I'm certainly trying to help identify issues during the introductory period - but I'm not going to go through hoops to install all kinds of addons when I can simply "dnf upgrade chrome".
When you pick a default, you send a message. I would think we would want to be encouraging KDE based technologies as much as possible. Chrome/Chromium doesn't need any additional marketing. Having qupzilla as the default isn't going to stop people from using Chrome - definitely not in my case. I'm too tied into it... but I do find myself testing out qupzilla and being impressed with it's features and functionality.
All the above considered, I simply don't understand how the KDE sig could vote for anything other than qupzilla.
On 7 August 2016 at 08:35, Rex Dieter wrote:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Advantages and features include:
- based on same rendering engine as qtwebengine (that qupzilla uses)
- has active, well-supported upstream
- some kde integration: kde file dialogs, kwallet for secrets
- supports most chrome addons/extensions
Disadvantages include:
- pretty new to fedora (only a few weeks)
- packaging/buildsystem is... messy and fragile (not unique here,
qtwebengine suffers similarly but less so)
- not 100% native (like qupzilla)
Sorry for being so late into the discussion. I have been using Chromium and Firefox regularly (but I didn't try anything else lately). I find the default settings of most software suboptimal, so I care mostly about configuration options.
The biggest disadvantage of Chromium to me is, it is not as configurable as Firefox. I have a feeling that the lack of configurability of Chromium makes it orthogonal to the KDE philosophy, e.g. - one cannot move the navigation icons - one cannot add a search bar, or - one cannot even make the tabs go below the address bar (The times we need vertical estate with 800x600 screens is way over)
That said I would be happy to try other alternatives, as long as they are configurable.
Thanks, Orcan
Il 07/08/2016 14:35, Rex Dieter ha scritto:
In my prior post, I included chromium in the list of browser candidates. If you're not familiar with it, it is essentially a free version of google chrome that recently made it's way into fedora package repositories.
Advantages and features include:
- based on same rendering engine as qtwebengine (that qupzilla uses)
- has active, well-supported upstream
- some kde integration: kde file dialogs, kwallet for secrets
- supports most chrome addons/extensions
Disadvantages include:
- pretty new to fedora (only a few weeks)
- packaging/buildsystem is... messy and fragile (not unique here,
qtwebengine suffers similarly but less so)
- not 100% native (like qupzilla)
-- Rex _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kde@lists.fedoraproject.org
I think many people are casting here their personal preferences instead of focusing on what should be the real point: what's the browser between Firefox, Chromium and Qupzilla that really integrates in KDE and requires the less dependencies being installed over a clean KDE spin installation?
I think the right choice between them must not force the installation of other requirements but the main QT / KF5 components. Personal considerations about missing functions should not be thrown in the discussion: if someone prefer one browser to another can easily install it over the main installation.
Trying to install Qupzilla and Chromium on my workstation (which is **not** a clean KDE installation and *I already have Firefox installed*, so probably I already have many GTK stuff installed that is required by Chromium), gives me:
# dnf install chromium Ultima verifica della scadenza dei metadati: 0:00:54 fa il Wed Aug 10 17:55:35 2016. Dipendenze risolte. ================================================================================ Package Arch Versione Repository Dim. ================================================================================ Installazione in corso: chromium x86_64 52.0.2743.82-9.fc24 updates 37 M chromium-libs x86_64 52.0.2743.82-9.fc24 updates 38 M libcanberra-gtk2 x86_64 0.30-11.fc24 fedora 30 k re2 x86_64 20160401-2.fc24 fedora 174 k u2f-hidraw-policy x86_64 1.0.2-2.fc24 fedora 22 k Riepilogo della transazione ================================================================================ Installati 5 pacchetti Dimensione totale dello scaricamento: 76 M Dimensione installata: 269 M
# dnf install qupzilla Ultima verifica della scadenza dei metadati: 0:02:07 fa il Wed Aug 10 17:55:35 2016. Dipendenze risolte. ================================================================================ Package Arch Versione Repository Dim. ================================================================================ Installazione in corso: protobuf x86_64 2.6.1-4.fc24 fedora 356 k qt5-qtwebengine x86_64 5.6.1-3.fc24 updates 28 M qtlockedfile-qt5 x86_64 2.4-21.20150629git5a07df5.fc24 fedora 35 k qtsingleapplication-qt5 x86_64 2.6.1-28.fc24 fedora 43 k qupzilla x86_64 2.0.1-1.fc24 updates 2.5 M re2 x86_64 20160401-2.fc24 fedora 174 k
Riepilogo della transazione ================================================================================ Installati 6 pacchetti
Dimensione totale dello scaricamento: 31 M Dimensione installata: 105 M
Given these outputs I vote for Qupzilla because it does not require GTK stuff and it weights less than a half compared to Chromium (I'm thinking to live images).
Mattia
On Wed, Aug 10, 2016 at 9:05 AM, Mattia Verga mattia.verga@tiscali.it wrote:
Given these outputs I vote for Qupzilla because it does not require GTK stuff and it weights less than a half compared to Chromium (I'm thinking to live images).
I completely agree with your assessment. I certainly hope that the people who voted for Firefox explain their rationale. If I'm missing something, I would like to understand it. I can't fathom, considering the circumstances, how someone could choose Firefox other than it is their personal preference.
Gerald B. Cox wrote:
I completely agree with your assessment. I certainly hope that the people who voted for Firefox explain their rationale. If I'm missing something, I would like to understand it. I can't fathom, considering the circumstances, how someone could choose Firefox other than it is their personal preference.
I find the last sentence completely incomprehensible. Why do you use KDE? Why do you drive your particular make of car? Surely not because it is someone else's preference? Except perhaps the wife.
I use Firefox (mainly) and Google Chrome. I use chromecast with my TV a lot (mainly with filmon because that is free) and enables me to watch English TV when in Italy. Can chromecast be used with any other browser? (The word "free" seems to be given a curious interpretation here. Like most normal people, I mean "does not cost anything".)
One reason I use Firefox is because Live Bookmarks can easily be installed in the Bookmarks Toolbar. I use this to access RSS feeds and also PHP programs I have written. I've found both of these difficult if not impossible in Chrome.
Admittedly I have very low standards, but to me Firefox and Chrome look perfectly OK in KDE. I also suspect that the amount of development of these 2 browsers is never going to be matched by a home-grown KDE program. I suspect the latter is always going to be trying to catch up.
Incidentally, I doubt if the choice of default browser will make much difference to most Fedora users. I imagine that the first step most people take when a new Fedora comes out is to install the browser that is their "personal preference".
Am 11.08.2016 um 23:59 schrieb Timothy Murphy:
Gerald B. Cox wrote:
I completely agree with your assessment. I certainly hope that the people who voted for Firefox explain their rationale. If I'm missing something, I would like to understand it. I can't fathom, considering the circumstances, how someone could choose Firefox other than it is their personal preference.
I find the last sentence completely incomprehensible
really?
Why do you use KDE? Why do you drive your particular make of car? Surely not because it is someone else's preference? Except perhaps the wife
it's not about your shed of car
i personally don't give a damn about other browsers than Firefox at the moment, but the topic is about the default browser of the kde-spin which sould have at least dependencies as possible, best desktop integratoon as possible compared with general usabilty and not my *personal* preference
*maybe* all KDE distributions shoukd throw out Firefox and if it's only to get upstream give a dman about desktop integration instead punish me with the shitty GTK/GNOME file dialogs
On Friday 12 August 2016 12:05:39 A.M. IST Reindl Harald wrote:
i personally don't give a damn about other browsers than Firefox at the moment, but the topic is about the default browser of the kde-spin which sould have at least dependencies as possible, best desktop integratoon as possible compared with general usabilty and not my *personal* preference
So you use Firefox, but you want others to use something else. Bizarre.
Am 12.08.2016 um 00:36 schrieb Timothy Murphy:
On Friday 12 August 2016 12:05:39 A.M. IST Reindl Harald wrote:
i personally don't give a damn about other browsers than Firefox at the moment, but the topic is about the default browser of the kde-spin which sould have at least dependencies as possible, best desktop integratoon as possible compared with general usabilty and not my *personal* preference
So you use Firefox, but you want others to use something else. Bizarre.
no you don't just understand the basics of a distribution adn what makes a kde-spin different to a gnome-spin and i fear you completly refuse trying to understand it
On Thu, 2016-08-11 at 22:59 +0100, Timothy Murphy wrote:
I use Firefox (mainly) and Google Chrome.
I mainly use Chrome and sometimes FF, but same difference. I will not use a browser that doesn't support LastPass though I'm perfectly aware that it's not free. We each have our own needs.
As to the default browser installed with KDE, I frankly don't care as long as I can change it.
poc
On 11/08/16 16:57, Patrick O'Callaghan wrote:
On Thu, 2016-08-11 at 22:59 +0100, Timothy Murphy wrote:
I use Firefox (mainly) and Google Chrome.
I mainly use Chrome and sometimes FF, but same difference. I will not use a browser that doesn't support LastPass though I'm perfectly aware that it's not free. We each have our own needs.
As to the default browser installed with KDE, I frankly don't care as long as I can change it.
poc
This is what I would say. Don't care what is the default as long as I can use what I want. I use some KDE software and some GTK software. The best tool wins.
I also add, supports or has very good privacy to start with.
Firefox is slipping on the privacy front in the trend to make it like Chrome. It has removed privacy features in the past few months and that has raised flags with my kids and myself. In some discussions on this it was because it made browsing the web harder and the features are available via plugins. I have yet to find a plugin to provide the same level of privacy that was within Firefox.
Depending on what I am doing, I want a browser I can fully lock down on cookies, web site tracking, scripts and ads. Other times to get a web site to work, I will use a different browser in a different account.
On Thu, Aug 11, 2016 at 2:59 PM, Timothy Murphy gayleard@eircom.net wrote:
I find the last sentence completely incomprehensible. Why do you use KDE? Why do you drive your particular make of car? Surely not because it is someone else's preference? Except perhaps the wife.
Folks, Rex requested that this this thread be reserved for voting... I opened another thread where we can discuss this. I'll respond there...
-
Christian Dersch -
Felix Miata -
Gerald B. Cox -
Kevin Kofler -
Luigi Toscano -
Mattia Verga -
Neal Gompa -
Orcan Ogetbil -
Patrick Boutilier -
Patrick O'Callaghan -
Reindl Harald -
Rex Dieter -
Richard Z -
Robin Laing -
Sudhir Khanger -
Timothy Murphy