Re: [dev] [ANN] sabotage 2011-04-30, a musl+busybox based distribution

From: pancake <>
Date: Wed, 04 May 2011 17:27:26 +0200

On 05/04/11 16:31, Nick wrote:
> One thing you should know about netsurf is that there are
> a few different frontends which work on linux. You're
> looking at the GTK one, which is naturally heavier on
> dependencies. The other major one is a 'framebuffer'
> frontend, which is a generic api which can hook into x or
> directfb.
i dont see the point of using libglade for the gtk backend... it's just
the reason why it depends on libxml and this is probably the main
bottleneck for loading the gtk UI...
> I think their RISC OS frontend is the most mature, though;
> the underlying html rendering code is nicer than the linux
> GUI code.
i dont really care about riscos.. and gtk is not *linux gui* . gtk runs
on osx, w32 and others. not only X11 backends. and i dont think the
browser runs better in riscos because of the underlaying libraries.
because in gtk you can do it better than they did it.

> On Wed, May 04, 2011 at 04:19:25PM +0200, pancake wrote:
>> 1) keyboard support sucks (no way to change between tabs, and no way
>> to switch between text fields, links, ... with tab)
>> 2) dependencies:
>> Depends On : libmng librsvg curl libglade lcms libjpeg>=7
>> libwapcaplet libcss
> I think glade is specific to the GTK client, and some of
> those others may be too. But generally that's a pretty
> compact list for a web browser.
glade sucks. it's something to be extermined. the only reason to have a
runtime compilable UI interface is in proprietary software where you can
hack on it and change functionalities without having the source.. but in
free software apps its just a step backwards.

that's why i use gtkon when i have to do something graphically.
>> I don't get the point of not distributing netsurf as a library... it
>> would be great if this project was just producing a standalone
>> library and a simple client implementation.
> netsurf is basically a client implementation of a few
> different libraries; see
> A simple client
> based on some of these should be do-able.
uhm... i see.. but the rendering part is found inside netsurf.. not in a
separated library.. and i dont see the point to have new libraries to
uncompress gif, jpeg, ... why there's not a single library to handle all
those file formats? they are mature enought and not changing for a long
time... i always find it sucky to have to link against libjpeg, libpng,
libtiff, libgif, libmng, lib.... to be able to open images on any
program. and each library uses a different API to work with the images..

I would love to see a simple and fast image uncompressing library with a
standard API for all them. if we just add support for compressing we can
write simple tools to convert between file formats and change background
images or write a nicer slock.

and im sure jpg+png+gif can fit in less than 2000 LOC.
>> 3) where's the javascript? most modern websites works only with
>> javascript. there'r tons of libraries to run it.. maybe you will
>> say: "js sucks".. but the web is made of it, and you can't ignore
>> it.
> I suppose that depends on what kind of web you use. I don't
> use js very heavily, and would be happy enough to have
> another slow, buggy browser for the times it's needed. But
> yes, js support is in progress, apparently. No idea of the
> status of it.
well.. i dont tend to depend on javascript until you realize some stuff
is generated in place by some json that comes every N seconds to have a
content updated in real time. (maps, etc..)
>> 4) possibility to filter or ban ads? (custom js fun? custom css stuff?)
> I use privoxy for this; browser independant and generally a
> local proxy seems like the right place to do this sort of
> stuff.
yeah..this is a good solution... but

Another thing that i miss here is the support to drag and zoom like in a
touchscreen, using scrollbars on such devices it sucks. and imho this
browser should run in a pocket device pretty nicely with just this fix.

Received on Wed May 04 2011 - 17:27:26 CEST

This archive was generated by hypermail 2.2.0 : Wed May 04 2011 - 17:24:04 CEST