[surf] few bugs

[Tadeusz Sośnierz]

Hello,
Few reports from me:
1) Don't know what's the reason, but typing address like
'www.google.com,' (with the comma at the end) is causing surf to act
weird.
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.

Regards,
Ted

[Jacob Todd]

Post by Tadeusz Sośnierz
Hello,
1) Don't know what's the reason, but typing address like
'www.google.com,' (with the comma at the end) is causing surf to act
weird.

What would you expect it todo, you added a comma to a url. And saying 'is
causing surf to act weird' is very vague. What did it cause surf to do?

[Tadeusz Sośnierz]

Post by Jacob Todd

Post by Tadeusz Sośnierz
Hello,
1) Don't know what's the reason, but typing address like
'www.google.com,' (with the comma at the end) is causing surf to act
weird.

What would you expect it todo, you added a comma to a url. And saying 'is
causing surf to act weird' is very vague. What did it cause surf to do?

Well, as far as I can see, looks like surf is trying to display an error
and load the page at the same time, which goes in a loop. I believe the
error itself would be nice, still it isn't very urgent thing, as no one
sane types , at the end of an url on purpose. And full urls with commas
in the middle work well, so it's not really annoying.

Regards,
Ted

[Moritz Wilhelmy]

What about full urls with commas at the end?
example: http://foo.com/bla/bar/asdf,
or even http://bleh.com/?foo=a,s,
Same behaviour?

Regards,
Moritz

Post by Tadeusz Sośnierz

Post by Jacob Todd

Post by Tadeusz Sośnierz
Hello,
1) Don't know what's the reason, but typing address like
'www.google.com,' (with the comma at the end) is causing surf to act
weird.

What would you expect it todo, you added a comma to a url. And saying 'is
causing surf to act weird' is very vague. What did it cause surf to do?

Well, as far as I can see, looks like surf is trying to display an error
and load the page at the same time, which goes in a loop. I believe the
error itself would be nice, still it isn't very urgent thing, as no one
sane types , at the end of an url on purpose. And full urls with commas
in the middle work well, so it's not really annoying.
Regards,
Ted
--
===========================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

[Tadeusz Sośnierz]

Post by Moritz Wilhelmy
What about full urls with commas at the end?
example: http://foo.com/bla/bar/asdf,
or even http://bleh.com/?foo=a,s,
Same behaviour?
Regards,
Moritz

Nah, Some of the adresses look ok, some are making silly reactions.
Anyway, as long as it does not affect the usual browsing it's not a
tragedy. The url entering issue is far more annoying I must say.
Regards,
Ted

[Evan Gates]

Post by Tadeusz Sośnierz
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\""

This way if the user hits escape, dmenu returns 1, and xprop isn't executed.

-emg

[Tadeusz Sośnierz]

Post by Evan Gates

Post by Tadeusz Sośnierz
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\""
This way if the user hits escape, dmenu returns 1, and xprop isn't executed.
-emg

There is a typo in your string, it should go like:
"uri=\"`echo -n | dmenu`\" && xprop -id $1 -f $0 8s -set $0 \"$uri\""
Thanks for your help though, works like a charm.
Regards,
Ted

[markus schnalke]

Post by Evan Gates

Post by Tadeusz Sośnierz
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

[Tadeusz Sośnierz]

Post by markus schnalke
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

Agreed. As now the looks like the only place in which surf uses xprop is
actually this uri and find handling. It's not really useful for setting
the address remotely, as we have better or worse patches for bookmarks,
we can open new surf instances in tabbed, etc.
Regards,
Ted

[Dieter Plaetinck]

On Thu, 29 Oct 2009 20:04:57 +0100

Post by Tadeusz Sośnierz

Post by markus schnalke
The quoted mail makes me share my thoughts on surf's xprop
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

Agreed. As now the looks like the only place in which surf uses xprop
is actually this uri and find handling. It's not really useful for
setting the address remotely, as we have better or worse patches for
bookmarks, we can open new surf instances in tabbed, etc.
Regards,
Ted

i always think of 'uzbl & surf' as 'wmii and dwm'.

basically they both encourage you to write things to interact/integrate
with, but wmii and uzbl recommend doing it with separate programs by
providing interfaces such as fifo/socket/virtual filesystem etc.

whereas dwm and surf recommend you to change the source code to provide
the behaviour you want.

both are fine approach, both have pros and cons and both appeal to
different people.
but IMHO they both provide a means to change the behavior of the program
as a whole

(note i haven't actually looked at surf's source code yet, but i
suspect that's how it works)

Dieter

[Julien Steinhauser]

Post by Dieter Plaetinck
On Thu, 29 Oct 2009 20:04:57 +0100

Post by Tadeusz Sośnierz

Post by markus schnalke
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

Agreed. As now the looks like the only place in which surf uses xprop
is actually this uri and find handling. It's not really useful for
setting the address remotely, as we have better or worse patches for
bookmarks, we can open new surf instances in tabbed, etc.
Regards,
Ted

i always think of 'uzbl & surf' as 'wmii and dwm'.
basically they both encourage you to write things to interact/integrate
with, but wmii and uzbl recommend doing it with separate programs by
providing interfaces such as fifo/socket/virtual filesystem etc.
whereas dwm and surf recommend you to change the source code to provide
the behaviour you want.
both are fine approach, both have pros and cons and both appeal to
different people.
but IMHO they both provide a means to change the behavior of the program
as a whole
(note i haven't actually looked at surf's source code yet, but i
suspect that's how it works)
Dieter

How long is the spawn function in surf?
I'd say ~ less than two weeks in tip and not yet in stable.
So it seems normal that it doesn't give yet a lot of script,
let's see how it will be later.

Before the spawn function was in surf, it was harder.
But now I can clean all the crapy scripts I had for surf.
Don't have to launch surf with -x anymore just to make it write his id
somewhere until I get it in a cumbersome way.

Just have to use the spawn function with the winid argument
or the xprop when I need it.

It is as simple as :
#define ADDBMK { .v = (char *[]){ "/bin/sh", "-c", \
"bookmark $0", winid, NULL } }

{ MODKEY, GDK_b, spawn, ADDBMK },

If I need the id in my sh script, $1 in the script gives it to me,
whatever surf window I have launched the script from.

For more complex task, I understand that one wishes also other interface
but I'm also sure that the actual possibility aren't fully exploited yet.