Kevin Kofler composed on 2016-08-08 14:21 (UTC+0200):
Felix Miata wrote:
> A high proportion of extension functionality here serves the
> 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)
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
It is also possible to develop third-party extensions against
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)
These are those installed in my primary Firefox profile:
Classic Theme Restorer
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
> I'd never opened QupZilla before now. Opened in F24 without
> 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:
> 1-Like other non-Gecko, non-KHTML browsers, both cannot be made
> 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
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
IMHO, having the tab close button on the tab is much more intuitive
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
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
days? You probably have a very old Firefox profile. Please compare default
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
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
Like I said already, how it works trumps how it looks.
default in our package. (I also prefer the traditional menu bar, and
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
discoverable. Firefox hides it in the menu bar (!!!) (that's a VERY non-
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,
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
> 5-UI text is not black (as is FF in obeying Plasma desktop
> 6-UI text font family is not as specified in Plasma's desktop
> (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.
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
That's because the browser is called "QupZilla", not
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
> made for Plasma and Fedora is probably the best target to shoot for.
A theme cannot solve integration issues such as non-native file
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
> In any event, under this roof, usability trumps appearance
> 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
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
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
If you really care that much about the DPI issue, I am looking
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
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/