Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Andrew Hills

On 10/25/14 13:41, F Hssn wrote:

Following suckless's minimal philosophy, I'd be interested to find out
if someone has done analysis on how an even minimal browser could be
developed in terms of SLOC, since webkit (r172694) stands at ~2
million lines, 75% of which is C++, while webkitgtk-1.10.2 is ~1
million, 90% C++. I used cloc. I'm surprised webkitgtk is smaller than
latest webkit.


Do you really want to write your own Javascript engine?




[dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for unsupported unicode chars

2014-10-25 Thread dequis
Hi suckless! First, thanks for st. Been using it for a long while,
still impressed at how it gets a lot of stuff right - stuff that urxvt
failed miserably at. There's only one issue that has been bothering me
particularly.


The issue itself:

Unicode characters added since unicode 5.2 (released in 2009, the
latest revision[1] is 7.0) are not supported by the wcwidth()
implementation of glibc, and as a result, they behave weirdly in st.
The man page of wcwidth() specifies that -1 is returned for invalid
unicode characters. I found a stack overflow question[2] about this
same issue.


How st handles it:

I made a gif[3] showing its behavior.

It just offsets the columns by the value returned by wcwidth,
expecting either 1 or 2, not -1. So each unsupported unicode character
behaves like a printable backspace.

Picked U+0524[4] for the tests. The st on the top shows the current
behavior, the st on the bottom is my patched version. The first two
lines typed in the gif are spaces followed by that character. Third
line is the letter 'a' just to show how it overlaps.

Then I used a tmux keybinding that is supposed to scan for URLs, but
the main effect here is refreshing the terminal contents, which makes
those characters vanish. That z^H is a typo, ignore that.


My patch:

Just wcwidth(...) -> abs(wcwidth(...))

In other words: if wcwidth returns -1, interpret that as a column
width of 1. It's a bit dirty and lazy, but it works wonderfully for
most characters.

I'm not sure what the "correct" solution would be, but it's definitely
not something as simple as this - would mean fixing the libc to
support unicode up to 7.0, or implementing our own version of it.

Opinions?


[1]: http://www.fileformat.info/info/unicode/version/index.htm
[2]: 
http://stackoverflow.com/questions/16371418/why-does-wcwidth-return-1-with-a-sign-that-i-can-print-on-the-terminal
[3]: http://i.imgur.com/MDzMJJH.gif
[4]: http://www.fileformat.info/info/unicode/char/0524/index.htm
From 810937df2c8a693deb26ac278c73f0147353079b Mon Sep 17 00:00:00 2001
From: dequis 
Date: Sat, 25 Oct 2014 23:07:38 -0300
Subject: [PATCH] Fix issues with wcwidth() returning -1 for unsupported
 unicode chars

Unicode characters added since unicode 5.2 are not supported by the
wcwidth() implementation of glibc, and as a result, they behave weirdly
in st. The man page of wcwidth() specifies that -1 is returned for
invalid unicode characters.

This patch wraps the wcwidth() calls with abs() to ensure that a column
size of 1 is used for unknown unicode characters.
---
 st.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/st.c b/st.c
index 23dd7f1..12af1ab 100644
--- a/st.c
+++ b/st.c
@@ -2576,7 +2576,7 @@ tputc(char *c, int len) {
 		unicodep = ascii = *c;
 	} else {
 		utf8decode(c, &unicodep, UTF_SIZ);
-		width = wcwidth(unicodep);
+		width = abs(wcwidth(unicodep));
 		control = ISCONTROLC1(unicodep);
 		ascii = unicodep;
 	}
@@ -3440,7 +3440,7 @@ xdraws(char *s, Glyph base, int x, int y, int charlen, int bytelen) {
 xp, winy + frc[i].font->ascent,
 (FcChar8 *)u8c, u8cblen);
 
-		xp += xw.cw * wcwidth(unicodep);
+		xp += xw.cw * abs(wcwidth(unicodep));
 	}
 
 	/*
-- 
2.1.2



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Quentin Rameau
Seems like you deviated a bit from the thread subject.



Re: [dev] Macbook retina and dwm

2014-10-25 Thread Alex Pilon
> On Sun, 26 Oct 2014 01:00:05 +0300 Dimitris Zervas  wrote:
> > I though about system wide font enlargement or passing other
> > resolution to X11 (possible?).
>
On Sun, Oct 26, 2014 at 12:41:15AM +0200, FRIGN wrote:
> You are close. The _real_ way to do it is set the DPI in xorg.conf

Or avoid touching that and put something like the following in
~/.x{initrc,profile} or the like:

xrandr --output DP-1 --dpi $DPI


pgpgzSgND9heO.pgp
Description: PGP signature


Re: [dev] Macbook retina and dwm

2014-10-25 Thread FRIGN
On Sun, 26 Oct 2014 01:00:05 +0300
Dimitris Zervas  wrote:
>

Refer to this:
https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI


-- 
FRIGN 



Re: [dev] Macbook retina and dwm

2014-10-25 Thread FRIGN
On Sun, 26 Oct 2014 01:00:05 +0300
Dimitris Zervas  wrote:

> Any ideas?
> I though about system wide font enlargement or passing other resolution to 
> X11 (possible?).

You are close. The _real_ way to do it is set the DPI in xorg.conf and enlargen 
the default
font size. That's exactly what Apple does with HiDPI.

Cheers

FRIGN

-- 
FRIGN 



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Daniel Camolês
2014-10-25 19:56 GMT-02:00 Wolfgang Corcoran-Mathe
:
>Any _popular_
> reboot would have to require people to change very little about
> their habits, and to do no hard thinking about the nature of the
> Web--if possible, no thinking at all.

It doesn't need to be popular at first; it needs to be correct and
simple and solve the problems at hand.



[dev] Macbook retina and dwm

2014-10-25 Thread Dimitris Zervas
Hello,

I just bought my macbook pro retina 13".
I am running Gentoo fairly well (a bit power hungry, I am open to suggestions, 
especially fan control).
The main problem is the resolution. If I downscale with xrandr, it does bitmap 
scales so the fonts are horrible.
Any ideas?
I though about system wide font enlargement or passing other resolution to X11 
(possible?).



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Wolfgang Corcoran-Mathe

Quoth Daniel Camolês on Sat, Oct 25 2014 16:29 -0200:

When the choice you have is between 500k or 2 million lines of
code, it hurts to call anything suckless. I think the web needs
a serious reboot.

[snip]

But when it comes to application distribution... I know that we
have ssh and mainframe terminal applications, but those are not
something most people are willing to use.


Are you talking about what 'most people' want when you speak of a
reboot?

Because I doubt whether people who are afraid of _SSH_ (of all
things) will choose a suite of less-sucking web applications if
they can pervert Firefox into doing everything. Any _popular_
reboot would have to require people to change very little about
their habits, and to do no hard thinking about the nature of the
Web--if possible, no thinking at all.

--
Wolfgang Corcoran-Mathe



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Teodoro Santoni
On Sat, Oct 25, 2014 at 06:12:29PM -0200, Daniel Camolês wrote:
> The problem is not with this specific organization.

I meant w3c as w3crap, as in all things www-related (sons of sgml, js, css, 
rdf, ...), not as the consortium, which imho isn't that much evil either: it 
has only the misfortune to aim to work on scripting languages and data 
representation in ways that imply you have to create disgusting nightmares of 
mad code to run it. Sorry if I put that wrong.

--
Teodoro Santoni



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Daniel Camolês
>> Am I alone? Is there any hope out there?
>
> TL;DR: Imho, there is none. W3c is the total opposite of suckless software.

The problem is not with this specific organization. Design by
committee is the source of the evil. Everybody wants to put a shiny
new feature in there. Also, you never want to break backwards
compatibility  but you always need to do so a lot because the initial
design was poor. So you add piles and piles of mess to compensate for
that.

> In either paths (interpret w3crap or deprecate it)

I think interpreting w3crap will just generate piles of shit as you
said. Breaking compatibility would be essential.



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Teodoro Santoni
On Sat, Oct 25, 2014 at 04:29:58PM -0200, Daniel Camolês wrote:
> [snip]
> I dream with the day when the Internet will be built
> around a model simple and generic enough that a reasonable programmer
> will be able to code a complete "browser" in a month of work or so.
> 
> Am I alone? Is there any hope out there?

TL;DR: Imho, there is none. W3c is the total opposite of suckless software.

Let's start by the simple fact that this technology is based on sgml dialects 
and something you could call visual java.
I can see only two strategies to make it suck less (in the suckless point of 
view, so the flexibility is maximum, it can fuck up your program and it's most 
likely user's fault or his/her responsibility to hack and patch it): kick NS 
plugins, cross-platform treatment of platform-specific things (like the codecs 
used for ) out of the 
code base and introducing better ways, nearer to what you see than what you 
get, to customize what you get from a given page (than JS userscripts and 
extensions, think about elinks scripting addons with an api that allows you to 
hack the DOM without workarounds like piping the page, or about w3m with a 
real GUI); and/or treat web pages as packages or apps, being able to compile 
them and even create overlays and repositories.
Both the approaches are stupid, given the goals of w3 pages: the first is 
inconsistent and incredibly prone to Thompson hacks, the second is totally the 
opposite of what HTML is after the v4.
What can we save? Either if it's by scripting or patching the source code, a 
suckless user shell for web pages (let's be honest: if we have to talk about 
web browser, thus developing something that renders more or less the same than 
firefox or chrome, one can only write a big pile of bloat just like 
gecko/blink/webkit, but in C) has to ship with a simpler and less 
standard-prone API for manipulating what happens on the screen when parsing a 
DOM, and maybe should have a static compiler for javascript, to C or to the 
scripting language for the "browser".
That would break, however, the classic workflow a user has with a browser.
This is a rant based on "mantaining the status quo but having something that 
doesn't coredump on google maps", one can instead do something lesser dumb 
and adding the modern capabilities to dumb terminal logic.

Nothing impedes to create extensions to VT1XX, for images, GL, videos, and 
replace cgi things with, for example, 9p-style interaction. Or 
replacing the actual html, css and js files in webservers with tcl scripts or 
things like that. Something you would download, with its corresponding media 
files, and feed to a wish shell or similar software.

In either paths (interpret w3crap or deprecate it) lots of work may be 
involved. And may end with another shitty bloated system. We are talking about 
taking over the world wide web, after all, lol.

--
Teodoro Santoni



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Kartik Agaram
> No, that was not what I was talking about. In this browser discussion,
> I am not interested in ways to understand complexity as your proposed
> solution. I think the fact that the browser needs to be this huge is a
> signal that things are very, very wrong, and a new solution for
> application distribution needs to come.

I'm still struggling to communicate this idea (everywhere, not just
here). The browser is complex because it relies on eighteen layers of
dependencies rather than just one. And the layers of dependencies are
caused by wanting some fuzzy sense of backwards compatibility rather
than digging into exactly what services one requires. That is my
candidate answer to your question of what is "very, very wrong" and
what the new solution to distribution needs to be. I hope that
white-box tests will allow more fine-grained code sharing without
worrying about compatibility. That will eliminate compounding drag
across many layers of dependencies.

This may be more radical than you expect. But the truth is often not reassuring.

"A prematurely frozen library doesn't just force people to live with
it. People react to it by wrapping it in a cleaner interface. But then
they prematurely freeze the new interface, and it starts accumulating
warts and bolt-on features just like the old one. Now you have two
interfaces. Was forking the existing interface really so much worse an
alternative? How much smaller might each codebase in the world be
without all the combinatorial explosion of interfaces wrapping other
interfaces" -- http://akkartik.name/post/libraries2



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Daniel Camolês
2014-10-25 16:59 GMT-02:00 Kartik Agaram :
>> Am I alone? Is there any hope out there?
>
> I'm working on this problem. I think the solution is white-box testing
> from the ground up, so that software encodes not just the rules about
> what to do but the specific scenarios that the programmer considered.

No, that was not what I was talking about. In this browser discussion,
I am not interested in ways to understand complexity as your proposed
solution. I think the fact that the browser needs to be this huge is a
signal that things are very, very wrong, and a new solution for
application distribution needs to come. I am not trying to understand
the current browser's code nor looking for ways to deal with huge
messes. I can't believe the the web and the browser are the better
solution for this problem.



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Brandon Mulcahy
On Sat, Oct 25, 2014 at 04:29:58PM -0200, Daniel Camolês wrote:
> When the choice you have is between 500k or 2 million lines of code,
> it hurts to call anything suckless. I think the web needs a serious
> reboot. It started out as a markup language for presentation-only, and
> then it was morphed through a convoluted series of additions into an
> application distribution plataform. The browser is the dumb terminal
> of our days. Today the web browser is the most awful piece of software
> I need to use. I dream with the day when the Internet will be built
> around a model simple and generic enough that a reasonable programmer
> will be able to code a complete "browser" in a month of work or so.
> 
> Am I alone? Is there any hope out there?

I remember reading something Russ Cox said about plan9port being created
because it would be easier to port all the Plan 9 userland to Unix than to
port a full-featured web browser to Plan 9.




Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Kartik Agaram
> Am I alone? Is there any hope out there?

I'm working on this problem. I think the solution is white-box testing
from the ground up, so that software encodes not just the rules about
what to do but the specific scenarios that the programmer considered.
Because we only encode rules and not intentions we paint ourselves
into corners where it's always easier to add more layers of code than
it is to rework existing layers. But this is hard to do with the
existing stack, because unix was invented before we appreciated the
power of tests, and it makes it too hard to write tests for blocking
IO, or for the 'find' command, or for what happens when a program runs
out of memory or disk. What we need is a simple OS and a comprehensive
library of fakes
(https://en.wikipedia.org/wiki/Mock_object#Mocks.2C_fakes_and_stubs)
for all OS concepts. This is what I'm working on.

http://akkartik.name/about
http://akkartik.name/post/readable-bad
https://news.ycombinator.com/item?id=8308881
https://news.ycombinator.com/item?id=8309344
https://news.ycombinator.com/item?id=8327008
https://news.ycombinator.com/item?id=8375219
http://www.ribbonfarm.com/2014/04/09/the-legibility-tradeoff



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread Daniel Camolês
When the choice you have is between 500k or 2 million lines of code,
it hurts to call anything suckless. I think the web needs a serious
reboot. It started out as a markup language for presentation-only, and
then it was morphed through a convoluted series of additions into an
application distribution plataform. The browser is the dumb terminal
of our days. Today the web browser is the most awful piece of software
I need to use. I dream with the day when the Internet will be built
around a model simple and generic enough that a reasonable programmer
will be able to code a complete "browser" in a month of work or so.

Am I alone? Is there any hope out there?

Document distribution seems easy. Hyperlinking was an wonderful idea,
but it's not complicated. But when it comes to application
distribution. By application distribution I mean, when we want to
develop and maintain software in a central location and enable several
users with a generic client to use it. I know that we have ssh and
mainframe terminal applications, but those are not something most
people are willing to use.

Answering your question about netsurf, I think the point is that it
doesn't currently run javascript. I think that is good thing, but most
site developers in the world doesn't. Also, netsurf developers also
intend to implement javascript at some point. But today for a lot of
sites you have to stick with one of the three main rendering engines.

2014-10-25 15:41 GMT-02:00 F Hssn :
> On Thu, Oct 23, 2014 at 6:54 AM, Quentin Rameau  wrote:
>> Hi, I tried to port surf for the webkit2 (WebKitGTK 2.6 / GTK3), here
>> is the code:
>> git://quinq.eu.org/surf2
>> There will be some bugs, feel free to try it, feedback welcomed.
>
> Noob question (joined the list a couple months ago),
>
> Since surf, uzbl, jumanji etc are minimal browsers in terms of UI's,
> is the GTK version of webkit (as opposed to directly using Webkit)
> used primarily for providing widget functionality to HTML? (so that
> widgets can be embedded in a webpage).
>
> Following suckless's minimal philosophy, I'd be interested to find out
> if someone has done analysis on how an even minimal browser could be
> developed in terms of SLOC, since webkit (r172694) stands at ~2
> million lines, 75% of which is C++, while webkitgtk-1.10.2 is ~1
> million, 90% C++. I used cloc. I'm surprised webkitgtk is smaller than
> latest webkit.
>
> Furthermore, since webkit is C++, I found (through wikipedia) a
> project called netsurf, which is a browser written in C (~0.5 million
> total, 50% is C). I wonder if anyone has considered that.
>
> Thanks and regards,
> FH
>



Re: [dev] surf rewrite for WebKit2GTK

2014-10-25 Thread F Hssn
On Thu, Oct 23, 2014 at 6:54 AM, Quentin Rameau  wrote:
> Hi, I tried to port surf for the webkit2 (WebKitGTK 2.6 / GTK3), here
> is the code:
> git://quinq.eu.org/surf2
> There will be some bugs, feel free to try it, feedback welcomed.

Noob question (joined the list a couple months ago),

Since surf, uzbl, jumanji etc are minimal browsers in terms of UI's,
is the GTK version of webkit (as opposed to directly using Webkit)
used primarily for providing widget functionality to HTML? (so that
widgets can be embedded in a webpage).

Following suckless's minimal philosophy, I'd be interested to find out
if someone has done analysis on how an even minimal browser could be
developed in terms of SLOC, since webkit (r172694) stands at ~2
million lines, 75% of which is C++, while webkitgtk-1.10.2 is ~1
million, 90% C++. I used cloc. I'm surprised webkitgtk is smaller than
latest webkit.

Furthermore, since webkit is C++, I found (through wikipedia) a
project called netsurf, which is a browser written in C (~0.5 million
total, 50% is C). I wonder if anyone has considered that.

Thanks and regards,
FH



Re: [dev] [surf] user certificates

2014-10-25 Thread Quentin Rameau
Hi,

in WebKit2 API, there is
webkit_web_context_allow_tls_certificate_for_host() [1]. Maybe that
can help you.
But I think that certificates aren't directly handled by WebKit and
you should manage them with other tools for your users.

[1]: 
http://webkitgtk.org/reference/webkit2gtk/2.4.2/WebKitWebContext.html#webkit-web-context-allow-tls-certificate-for-host

On Mon, May 5, 2014 at 10:18 PM, Markus Teich
 wrote:
> Heyho,
>
> how to implement user certificates? I did not find any hint in the 
> documentation
> of webkit-gtk or libsoup… :(
>
> --Markus
>