Re: [dev] [surf] xprop (was: few bugs)

From: markus schnalke <>
Date: Thu, 29 Oct 2009 19:59:17 +0100

[2009-10-29 10:42] Evan Gates <>
> >2) When you choose your URI (C-g by default) and then abort it
> >pressing [esc] or something, the document is trying to be loaded anyway,
> >with empty address. It's a bit too much for the setprop() macro (or is
> >it?), but I think some function may check the input from dmenu and set
> >it only if it's not empty.
> Change the
> "xprop -id $1 -f $0 8s -set $0 \"`echo -n | dmenu || exit 0`\""
> to
> "uri=\"`echo -n | dmenu`\" && "xprop -id $1 -f $0 8s -set $0 \"$uri\""

The quoted mail makes me share my thoughts on surf's xprop interface:

At first, it seems pretty nice how surf communicates with the outside.
But on closer looks, I dislike the xprop stuff more and more.

What is shown above does surely not look nice; it's pretty obscure when
you compare it to most of the suckless software we know.

You may say that this does not matter much, as you only once need to
find out how it has to be done.

But -- and this my main point -- the xprop interface is a break on
unleashing the leverage of surf!

Uzbl may not be as small as surf, it's ``command language'' on the
interface may be a bit too big, but it does one thing right where surf
fails: It *encourages* to combine it with other programs!

Surf is able to interface all kinds of programs through xprop, but not
in an easy/flexible enough way. The large number of user scripts that
extend uzbl is not the result of the larger community, but the result of
the interface that makes you want to write ``handler'' scripts.

Instead of staying hooked to xprop, surf should create a fifo for input
and write stuff to stdout in order to make it easier/more flexible to
combine it with helper scripts. This would improve surf much.

Here (possibly) more code leads to less complexity combined with more

It's not enough to just offer possibilities; important is to encourage
to use them ... by design. In this point surf fails, whereas uzbl does
it right.

Received on Thu Oct 29 2009 - 18:59:17 UTC

This archive was generated by hypermail 2.2.0 : Thu Oct 29 2009 - 19:00:03 UTC