Fifth: A New Web Browser Based On WebKitFLTK

[curaga]

It would have been ready two months sooner, but Cairo had a serious bug (scrolling some pages would segfault, also affects FF and other webkit browsers), it took this long to get a Cairo release, and I couldn't exactly depend on unreleased libs.

ah, really? I dont think so.
Funny how this guy advertises his missing stuff with "its not a bug its a feature!", same goes for his quote:
.. are you kidding me?

No. The appification of the web is a completely wrong direction. JS is slow, and using it for more and more complex tasks that should be native is simply stupid. The same applies for video and 3d, putting them in a browser merely adds overhead and limitations.

If you disagree, you're welcome to use FF or Chrome.

@Ibidem, Delgarde

Yes, it works on Youtube. And unlike youtube-dl, it cannot be blocked. As long as the site exposes HTML5 video, a browser will always be able to download it.

Some porn sites are incompatible so far because they add an overlay, this can be fixed by changing the buttons' CSS, hasn't been a high priority so far. Mplayer doesn't support https, and some youtube videos are served over https, so those can only be downloaded (or played if you use a different player with https support).

But I do have to say that the numbers he's using for RAM seem to be virtual memory - shared libs, which is arbitrary and garbage unless you turned off overcommit.

pmap -d explicitly excludes shared libs, try it on any process. Shared lib pages are not writable, shared lib data is, but so is static lib data. It's true it's not perfect as thread stacks are fully counted, but that means ~7mb per thread (8mb stack minus estimated 1mb needed), and no browser uses more than 10-20 threads, most use less than you have cores. Thus the maximum measurement error is ~140mb (depends on how many threads are used), not enough to explain the Otter/Arora RAM use. It's the best measurement I've found so far, way more accurate than top/other methods measuring RSS/VSZ.

However, fltk is quite possibly the most hilariously bad choice of gui toolkit he could have used.

Yeah I think that's why the screen shots of the project site look so win95?

FLTK is a lot lighter than gtk, and way more so vs Qt. To me function comes over form.

It reminds me of old opera 9.x

Yep, Opera 9.64 is to me the best browser so far, in terms of user interface; I explicitly targeted it. Opera 10 / current FF / current Chrome are worse in usability, making changes for changes' sake.

[Emdek]

So we got a direct competitor... :-)

Compared to the other Free Software Opera replacement browser, Otter,
Fifth is lighter, and carries some features that cannot be implemented
in Otter. Otter relies on the Qt-exposed APIs, and as such, can not
spoof many things unless Qt starts exposing that functionality, for
one. Likewise, the SSL functionality and custom HTML widgets require
code changes inside Webkit, which the Otter project will not do due to
the reliance on Qt.

It's true for now, but we could simply fork QtWebKit if it would make sense (recompiling such beast as WebKit frequently is pain and there are other less visible disadvantages too).
It can change in future, as QtWebKit is already deprecated while QtWebEngine is far from being ready to replace it.
Also please note that we won't focus on single backend (although obviously default will be always more complete than alternatives).

And while FLTK is lighter than other toolkits it also will require more work to get features already available in Qt.
Also lighter toolkit won't help much as WebKit itself is memory hungry...

Anyway, we should try to cooperate in at least some areas as it seems that our goals are not identical anyway.

[curaga]

Nice comments on opennet.ru.
--

Hi Emdek

Yes, Otter and Fifth might be able to share code, and cooperate otherwise. I remember pointing you to my url blocker lib, but I see Otter implemented URL blocking in a different way much later. Bookmark importing also differs, Otter has code to do so while Fifth ships with a separate awk script. But there may be many other areas which could work.

Did you check the benchmark? Otter starts up fast, but uses RAM like no tomorrow. How Webkit is configured can make a big difference.

PS: your forum is down.

[Emdek]

@curaga, hello.

Sharing code without modifications could be hard, as we use Qt classes extensively...
That content blocking library was considered but we decided to go with AdBlock compatible rules, the same approach as other Qt based browsers.

Did you check the benchmark? Otter starts up fast, but uses RAM like no tomorrow. How Webkit is configured can make a big difference.

For sure content blocking currently eats a lot of memory but that could be improved.
It would be nice to be able to mess with WebKit directly, but with limited manpower it's too early for that, we need to invest more work into UI first.
Please note that while WebKit is currently our primary and only backend we are investigating alternatives (Gecko bindings seems most usable, comparing to currently very limited API offered by QtWebEngine), we need to decide first if it is worth to invest more in WebKit1 as its future is uncertain (Apple will go WebKit2 sooner or later).

Own fork, while having numerous advantages, is nightmare in longterm, it needs to be maintained which would take a lot work, to sync useful changes from upstream and keep features removed there (Apple removed some stuff after Blink was created...).
And someone has to maintain and extend it after Apple will abandon WebKit1...

[halo9en]

Yep, Opera 9.64 is to me the best browser so far, in terms of user interface; I explicitly targeted it. Opera 10 / current FF / current Chrome are worse in usability, making changes for changes' sake.

This. A thousand times this.

[TheOne]

maybe a good fit for the slow raspberry pi

[cb88]

Yep, Opera 9.64 is to me the best browser so far, in terms of user interface; I explicitly targeted it. Opera 10 / current FF / current Chrome are worse in usability, making changes for changes' sake.

Perhaps you could build a version that draws the *this is too much crap line* at a different place... I personally think being able to play videos in a video tag is important enough a feature that it is a must have.... I can see how you would want to not include it on a basis of lightweightness/speed. but on the other hand it doesn't go against your non-app/native only philosophy.

In any case I've been hoping someone would build a nice FLTK browser for a long time thanks again.

[pandev92]

download a video without know if the video is good or bad, is a stupid thing

[raulb]

This sounds interesting. I love these kind of lightweight no nonsense projects, with a developer who is clearly focused on one goal. They usually result in some seriously optimised projects.

I have been enjoying Alpine Linux of late, it too is lightweight, zippy and extremely functional with a couple of nifty tricks. Can't wait to try this out when I get some time to try to build it.

[pal666]

-Download/Stream works for youtube, if the screenshots can be trusted.
I've had no luck viewing youtube except via youtube-dl (I use Alpine Linux, so flash won't work, gnash doesn't compile, etc.)

i have luck viewing youtube via both ff and chrome. i use real distro (fedora), so gnash does compile, but neither gnash nor adobe flash is installed. chrome has builtin plugin though.
but all this does not matter because i also have download buttons for youtube via ff plugin. it does not need new browser, it needs having some brains