[2009-10-29 10:42] Evan Gates <evan.ga...@gmail.com> > >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 flexibility. 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. meillo
