[surf] next release

Post by Enno Boland (Gottox)
Hi!
I'm going to release 0.3 this or next week, depending on how much time
I can investigate. Please recheck tip and give feedback, as there are
some bigger changes.
* persistant/concurrent cookies are working (hopefully)
* removing urlbar/searchbar and using dmenu instead
* if the window is shrinked below a defined size, the zoom factor is
automaticly decreased. This is usefull on small screens and tiling
window manager.
* searching works from an XProperty now.
* get downloads working again.
regards
Enno

Hello,
Sounds fine, but what was the reason to include dmenu instead of just
GtkEntries? Are there some plans to put bookmarks inside dmenu choices,
or you just don't like GtkStuff? What made you make this decision? Just
curious.
Regards,
Ted

--
===========================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

pancake

2009-10-21 10:06:29 UTC

I dunno, but dmenu lacks edition/pasting, the only reason i can imagine
to use dmenu is to autocomplete from bookmarked or visited urls. I didn't
tried it yet, but I'm curious about if its better or worse way to enter
urls.

Anselm R Garbe

2009-10-21 10:19:42 UTC

Post by pancake
I dunno, but dmenu lacks edition/pasting, the only reason i can imagine
to use dmenu is to autocomplete from bookmarked or visited urls. I didn't
tried it yet, but I'm curious about if its better or worse way to enter
urls.

I think it's a good decision to use dmenu. This allows automatically
caching the url entered and present it the next time.
If this decision remains stable in surf, I'm willing to accept the
vertical menu patch in vanilla dmenu.

Kind regards,
Anselm

Tadeusz Sośnierz

2009-10-21 10:28:49 UTC

Well, in 0.2, using GtkEntry it was alredy working like this: while
visiting surf.suckless.org, pressing C-g you had
'http://surf.suckless.org' in the entry field, ready to
copy/paste/edit/whatever. Of course you can use dmenu to keep the cache
of more than one url, but I'm sure it can be also done via
GtkEntryCompletion or how is it called. Also, I doubt if piping this
urls from surf to dmenu and vice versa will be even faster and lighter
than GtkEntry. Atm I don't see one reason to use dmenu this way.

What is more, the searchbar. In 0.2, you opened it, typed 'surf',
pressed enter, but the 'surf' remained there, so you just pressed enter
once again, no need to open a search bar and type it once again.

Still if there are really some good reasons for using dmenu instead of
GtkEntry, I'd likely hear them.

Regards,
Ted

--
===========================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Dieter Plaetinck

2009-10-21 12:35:19 UTC

On Wed, 21 Oct 2009 11:19:42 +0100

Post by Anselm R Garbe
If this decision remains stable in surf, I'm willing to accept the
vertical menu patch in vanilla dmenu.

that would be awesome <3

Dieter

PS: uzbl also relies on dmenu with vertical patch and that probably
won't change

Julien Steinhauser

2009-10-21 10:55:47 UTC

Hello!
About the downloads, I believe that most users have to move downloaded files
from ~/.surf/dl before doing anything with them.
What about externalize the downloading task to a simple script
which make you choose the destination first?
It could simplify surf's code?

Right-clicking on the link and copy it is the preminaliry task of the user.

The script named cdd for "choose download directory" depends only on wget
and on suckless tools (and sort if you like)

In this script lsd is suckless lsx with S_ISDIR instead of S_ISREG on line 28
You just stop directory navigation and start the download with escape.
I apologize for my scripting style...

#!/bin/sh
dir=`lsd $PWD | sort | dmenu -p $PWD`
[ -z $dir ]
if [ $? = 1 ]; then
cd $dir && cdd ; else
wget --user-agent=usetheoneyoulike `sselp`
fi

attached an lsd tarball

Peter John Hartman

2009-10-21 12:53:18 UTC

Hi,

Two brief notes.

(1) * removing urlbar/searchbar and using dmenu instead

I'm not sure if this is so attractive, since dmenu does not support x paste
(without a patch) and one always finds oneself (or at least I do) cutting
and pasting into the searchbar. The ultimate solution, it seems to me, is
to have dmenu support x paste in vanilla. This strikes me as superior to an
"in-surf" solution (which uses GtkWhatever) for a number of reasons.
(a) It keeps the code simple (on the surf side that is; dmenu will need
to change).
(b) Other web-based activities (smart prefixes in particular)
could benefit from a dmenu + x paste. For example, I have a
surf-googlesearch.sh script which runs dmenu after parsing my user input
from dmenu. It would be nice to x paste into the dmenu rather than
typing out a given google search (e.g. when one is searching someone's
odd name.)
(c) In general, I like the xprop interface and allowing applications other
than surf to interact with surf (which is what your new _SURF_FIND feature
allows--which is great--which is why we need dmenu to get patched!)

(2) * get downloads working again.

I think it is enough to just have a way of grabbing the url and then letting
the user launch an extrinsic application. It looks as if 0.3 (tip) does
this much now.

Thanks for the work,
Petre

Anselm R Garbe

2009-10-21 12:59:30 UTC

Post by Peter John Hartman
(1) * removing urlbar/searchbar and using dmenu instead
I'm not sure if this is so attractive, since dmenu does not support x paste
(without a patch) and one always finds oneself (or at least I do) cutting
and pasting into the searchbar. The ultimate solution, it seems to me, is
to have dmenu support x paste in vanilla. This strikes me as superior to an
"in-surf" solution (which uses GtkWhatever) for a number of reasons.
(a) It keeps the code simple (on the surf side that is; dmenu will
need
to change).
(b) Other web-based activities (smart prefixes in particular)
could benefit from a dmenu + x paste. For example, I have a
surf-googlesearch.sh script which runs dmenu after parsing my user
input
from dmenu. It would be nice to x paste into the dmenu rather than
typing out a given google search (e.g. when one is searching
someone's
odd name.)
(c) In general, I like the xprop interface and allowing applications
other
than surf to interact with surf (which is what your new _SURF_FIND
feature
allows--which is great--which is why we need dmenu to get patched!)

There is sselp(1) at http://tools.suckless.org/sselp which reads
current selection and prints it to stdout, hence enables you to
integrate it into dmenu's cache or calling surf `sselp` directly.
There shouldn't be a real need to paste something interactively into
surf or dmenu really.

Kind regards,
Anselm

Peter John Hartman

2009-10-21 13:17:52 UTC

Post by Peter John Hartman
(1) * removing urlbar/searchbar and using dmenu instead
I'm not sure if this is so attractive, since dmenu does not support x paste
(without a patch) and one always finds oneself (or at least I do) cutting
and pasting into the searchbar. Â The ultimate solution, it seems to me, is
to have dmenu support x paste in vanilla. Â This strikes me as superior to an
"in-surf" solution (which uses GtkWhatever) for a number of reasons.
Â Â Â Â (a) It keeps the code simple (on the surf side that is; dmenu will
need
Â Â Â Â to change).
Â Â Â Â (b) Other web-based activities (smart prefixes in particular)
Â Â Â Â could benefit from a dmenu + x paste. Â For example, I have a
Â Â Â Â surf-googlesearch.sh script which runs dmenu after parsing my user
input
Â Â Â Â from dmenu. Â It would be nice to x paste into the dmenu rather than
Â Â Â Â typing out a given google search (e.g. Â when one is searching
someone's
Â Â Â Â odd name.)
Â Â Â Â (c) In general, I like the xprop interface and allowing applications
other
Â Â Â Â than surf to interact with surf (which is what your new _SURF_FIND
feature
Â Â Â Â allows--which is great--which is why we need dmenu to get patched!)

What about cases in which one wishes to both type a few words and then paste? For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where the first part is something
I type in by hand and the second part is something I want to just "paste" in? The same argument
could be launched with respect to the find feature (which now utilizes dmenu).

Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"?

Peter

Julien Steinhauser

2009-10-21 14:24:55 UTC

Post by Peter John Hartman
What about cases in which one wishes to both type a few words and then paste? For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where the first part is something
I type in by hand and the second part is something I want to just "paste" in? The same argument
could be launched with respect to the find feature (which now utilizes dmenu).
Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"?
Peter

sselp does it also in case you wish to paste "and" write.
Select something, then run echo `sselp` | dmenu, tab, space
and what you write after that follows your selection,
terminate dmenu and all is printed out.

Peter John Hartman

2009-10-21 14:32:32 UTC

Fair enough; but the functionality still seems a bit stifling, doesn't it? Particular problems
I would see with this (in terms of "workflow") are as follow.

Let's use the simple example of the surf-find function which now uses dmenu.

(1) You have to know in advance if you want to paste into the input field or not (on your proposal).
But sometimes we don't want what is in our x selection buffer to show up as an option in the find.
For example, if I have a huge chunk of code in my x selection buffer, but I want to find someone's
name. But sometimes we do want what is in our x selection buffer to show up as a option in find.
Hence, we have to know in advance on your proposal, which strikes me as bad.

(2) You can't easily just type something, then paste, then keep typing something (on your proposal).
In fact, you can't type something and then paste either, as the paste selection disappears after
you start typing. This again seems like a limitation.

These considerations suggest that perhaps a patch to dmenu should be re-evaluated for inclusion in
vanilla?

Yours,
Peter

Anselm R Garbe

2009-10-21 14:42:08 UTC

Post by Peter John Hartman
What about cases in which one wishes to both type a few words and then
paste? For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my
selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where
the first part is something
I type in by hand and the second part is something I want to just "paste"
in? The same argument
could be launched with respect to the find feature (which now utilizes dmenu).
Or maybe you have something else in mind when you talk of "integrating
into dmenu's cache"?
Peter

Fair enough; but the functionality still seems a bit stifling, doesn't it?
Particular problems I would see with this (in terms of "workflow") are as
follow.
Let's use the simple example of the surf-find function which now uses dmenu.
(1) You have to know in advance if you want to paste into the input field or
not (on your proposal).
But sometimes we don't want what is in our x selection buffer to show up as
an option in the find.
For example, if I have a huge chunk of code in my x selection buffer, but I
want to find someone's name. But sometimes we do want what is in our x
selection buffer to show up as a option in find.
Hence, we have to know in advance on your proposal, which strikes me as bad.
(2) You can't easily just type something, then paste, then keep typing
something (on your proposal).
In fact, you can't type something and then paste either, as the paste
selection disappears after
you start typing. This again seems like a limitation.
These considerations suggest that perhaps a patch to dmenu should be
re-evaluated for inclusion in
vanilla?

Well I'd be fine to support ^p in order to paste selection until "\n"
into dmenu if that helps.

Kind regards,
Anselm

Anselm R Garbe

2009-10-21 14:42:47 UTC

Post by Peter John Hartman
What about cases in which one wishes to both type a few words and then
paste? For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my
selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where
the first part is something
I type in by hand and the second part is something I want to just "paste"
in? The same argument
could be launched with respect to the find feature (which now utilizes dmenu).
Or maybe you have something else in mind when you talk of "integrating
into dmenu's cache"?
Peter

Fair enough; but the functionality still seems a bit stifling, doesn't it?
Particular problems I would see with this (in terms of "workflow") are as
follow.
Let's use the simple example of the surf-find function which now uses dmenu.
(1) You have to know in advance if you want to paste into the input field or
not (on your proposal).
But sometimes we don't want what is in our x selection buffer to show up as
an option in the find.
For example, if I have a huge chunk of code in my x selection buffer, but I
want to find someone's name. But sometimes we do want what is in our x
selection buffer to show up as a option in find.
Hence, we have to know in advance on your proposal, which strikes me as bad.
(2) You can't easily just type something, then paste, then keep typing
something (on your proposal).
In fact, you can't type something and then paste either, as the paste
selection disappears after
you start typing. This again seems like a limitation.
These considerations suggest that perhaps a patch to dmenu should be
re-evaluated for inclusion in
vanilla?

Well I'd be fine to support ^p in order to paste selection until "\n"
into dmenu if that helps.

Or more generically having some control-key interface that calls a
script and reads a line and puts that as input.

Kind regards,
Anselm

Peter John Hartman

2009-10-21 14:50:25 UTC

Post by Peter John Hartman
What about cases in which one wishes to both type a few words and then
paste? Â For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my
selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where
the first part is something
I type in by hand and the second part is something I want to just "paste"
in? Â The same argument
could be launched with respect to the find feature (which now utilizes dmenu).
Or maybe you have something else in mind when you talk of "integrating
into dmenu's cache"?
Peter

sselp does it also in case you wish to paste "and" write.
Select something, then run echo `sselp` |Â dmenu, tab, space
and what you write after that follows your selection,
terminate dmenu and all is printed out.

Fair enough; but the functionality still seems a bit stifling, doesn't it?
Â Particular problems I would see with this (in terms of "workflow") are as
follow.
Let's use the simple example of the surf-find function which now uses dmenu.
(1) You have to know in advance if you want to paste into the input field or
not (on your proposal).
But sometimes we don't want what is in our x selection buffer to show up as
an option in the find.
For example, if I have a huge chunk of code in my x selection buffer, but I
want to find someone's name. Â But sometimes we do want what is in our x
selection buffer to show up as a option in find.
Hence, we have to know in advance on your proposal, which strikes me as bad.
(2) You can't easily just type something, then paste, then keep typing
something (on your proposal).
In fact, you can't type something and then paste either, as the paste
selection disappears after
you start typing. Â This again seems like a limitation.
These considerations suggest that perhaps a patch to dmenu should be
re-evaluated for inclusion in
vanilla?

Well I'd be fine to support ^p in order to paste selection until "\n"
into dmenu if that helps.

Or more generically having some control-key interface that calls a
script and reads a line and puts that as input.
Kind regards,
Anselm

Like Shift-Insert? :-) Or have I misunderstood your proposal?

Peter

pancake

2009-10-21 14:49:29 UTC

I always use shift+insert or middleclick for pasting, what's the unix
way to paste?
^p is already supported in surf, and mozilla load pages if you paste
them in the
web canvas...so which is the 'correct' one? :)

And yeah i didn't mention ^C^V because I never use them and can break other
keybindings of the underlying app. Like the unix-editing for textentries
on gtk
apps, because ^W is the default keybinding for closing windows on Gnome
apps.

Post by Peter John Hartman
What about cases in which one wishes to both type a few words and then
paste? For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my
selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where
the first part is something
I type in by hand and the second part is something I want to just "paste"
in? The same argument
could be launched with respect to the find feature (which now utilizes dmenu).
Or maybe you have something else in mind when you talk of "integrating
into dmenu's cache"?
Peter

Fair enough; but the functionality still seems a bit stifling, doesn't it?
Particular problems I would see with this (in terms of "workflow") are as
follow.
Let's use the simple example of the surf-find function which now uses dmenu.
(1) You have to know in advance if you want to paste into the input field or
not (on your proposal).
But sometimes we don't want what is in our x selection buffer to show up as
an option in the find.
For example, if I have a huge chunk of code in my x selection buffer, but I
want to find someone's name. But sometimes we do want what is in our x
selection buffer to show up as a option in find.
Hence, we have to know in advance on your proposal, which strikes me as bad.
(2) You can't easily just type something, then paste, then keep typing
something (on your proposal).
In fact, you can't type something and then paste either, as the paste
selection disappears after
you start typing. This again seems like a limitation.
These considerations suggest that perhaps a patch to dmenu should be
re-evaluated for inclusion in
vanilla?

Well I'd be fine to support ^p in order to paste selection until "\n"
into dmenu if that helps.
Kind regards,
Anselm

Anselm R Garbe

2009-10-21 15:02:30 UTC

I always use shift+insert or middleclick for pasting, what's the unix way to
paste?
^p is already supported in surf, and mozilla load pages if you paste them in
the
web canvas...so which is the 'correct' one? :)
And yeah i didn't mention ^C^V because I never use them and can break other
keybindings of the underlying app. Like the unix-editing for textentries on
gtk
apps, because ^W is the default keybinding for closing windows on Gnome
apps.

In dmenu we don't need to worry about other apps, because dmenu grabs
the keyboard and during the time until ungrabbing it we can override
any key combination we like. That's why I propose having a Key
interface in dmenu like in dwm that can be used to execute a command
to insert at current text position and good is. I prefer ^p to
Shift-Insert by default.

Kind regards,
Anselm

Peter John Hartman

2009-10-21 15:04:48 UTC

I always use shift+insert or middleclick for pasting, what's the unix way to
paste?
^p is already supported in surf, and mozilla load pages if you paste them in
the
web canvas...so which is the 'correct' one? :)
And yeah i didn't mention ^C^V because I never use them and can break other
keybindings of the underlying app. Like the unix-editing for textentries on
gtk
apps, because ^W is the default keybinding for closing windows on Gnome
apps.

Ctl-p is fine by me as long as it is established in config.h (i.e.\ as long as the user has
an easy chance at over-riding it).

Peter

Dieter Plaetinck

2009-10-21 17:08:54 UTC

On Wed, 21 Oct 2009 11:04:48 -0400 (EDT)

Post by pancake
I always use shift+insert or middleclick for pasting, what's the
unix way to paste?
^p is already supported in surf, and mozilla load pages if you
paste them in the
web canvas...so which is the 'correct' one? :)
And yeah i didn't mention ^C^V because I never use them and can
break other keybindings of the underlying app. Like the
unix-editing for textentries on gtk
apps, because ^W is the default keybinding for closing windows on
Gnome apps.

In dmenu we don't need to worry about other apps, because dmenu
grabs the keyboard and during the time until ungrabbing it we can
override any key combination we like. That's why I propose having a
Key interface in dmenu like in dwm that can be used to execute a
command to insert at current text position and good is. I prefer ^p
to Shift-Insert by default.
Kind regards,
Anselm

Ctl-p is fine by me as long as it is established in config.h (i.e.\
as long as the user has an easy chance at over-riding it).
Peter

what about commandline flags? dmenu --bind ^p /path/to/script.sh --bind
shift-insert /path/to/other-script.sh

i like the general idea, though i'm not sure if it's worth the hassle
(bloat?).

Dieter

Colin Shea

2009-10-21 18:39:34 UTC

Post by Dieter Plaetinck
On Wed, 21 Oct 2009 11:04:48 -0400 (EDT)

In dmenu we don't need to worry about other apps, because dmenu
grabs the keyboard and during the time until ungrabbing it we can
override any key combination we like. That's why I propose having a
Key interface in dmenu like in dwm that can be used to execute a
command to insert at current text position and good is. I prefer ^p
to Shift-Insert by default.
Kind regards,
Anselm

Ctl-p is fine by me as long as it is established in config.h (i.e.\
as long as the user has an easy chance at over-riding it).
Peter

what about commandline flags? dmenu --bind ^p /path/to/script.sh --bind
shift-insert /path/to/other-script.sh
i like the general idea, though i'm not sure if it's worth the hassle
(bloat?).
Dieter

A config.h approach seems best here, dmenu already does that for defaults
and
it could be inconsistent if the calling app chose demnu's bindings rather
than
dmenu choosing for itself.

Dieter Plaetinck

2009-10-21 14:38:51 UTC

On Wed, 21 Oct 2009 16:24:55 +0200

Post by Peter John Hartman
What about cases in which one wishes to both type a few words and
then paste? For example, when I want to do a smart prefix search
(via dmenu) on Bob McCrue (who sits in my selection buffer) but I
also want to do something like "University of Wherever" + "Bob
McCrue" where the first part is something I type in by hand and the
second part is something I want to just "paste" in? The same
argument could be launched with respect to the find feature (which
now utilizes dmenu).
Or maybe you have something else in mind when you talk of
"integrating into dmenu's cache"?
Peter

and what if you want to have first the string you type yourself, and
then the pasted stuff?

i also think paste support in dmenu would be nice.

Dieter

Anselm R Garbe

2009-10-21 14:29:55 UTC

What about cases in which one wishes to both type a few words and then
paste? For example, when I want
to do a smart prefix search (via dmenu) on Bob McCrue (who sits in my
selection buffer) but I also
want to do something like "University of Wherever" + "Bob McCrue" where the
first part is something
I type in by hand and the second part is something I want to just "paste"
in? The same argument
could be launched with respect to the find feature (which now utilizes dmenu).
Or maybe you have something else in mind when you talk of "integrating into dmenu's cache"?

If you use dmenu for querying wikipedia, asking google, or whatever I
think all you want is a usual prefix and then type in the rest of your
query. I agree that dmenu's text editing is limited and not equally
powerful to a usual text edit field. But perhaps this proves to be an
advantage when used for a while, let's see what we think after using
it for some time. Often we might conclude less is more.

Kind regards,
Anselm

Peter John Hartman

2009-10-21 13:21:47 UTC

Post by Peter John Hartman
(1) * removing urlbar/searchbar and using dmenu instead
I'm not sure if this is so attractive, since dmenu does not support x paste
(without a patch) and one always finds oneself (or at least I do) cutting
and pasting into the searchbar. Â The ultimate solution, it seems to me, is
to have dmenu support x paste in vanilla. Â This strikes me as superior to an
"in-surf" solution (which uses GtkWhatever) for a number of reasons.
Â Â Â Â (a) It keeps the code simple (on the surf side that is; dmenu will
need
Â Â Â Â to change).
Â Â Â Â (b) Other web-based activities (smart prefixes in particular)
Â Â Â Â could benefit from a dmenu + x paste. Â For example, I have a
Â Â Â Â surf-googlesearch.sh script which runs dmenu after parsing my user
input
Â Â Â Â from dmenu. Â It would be nice to x paste into the dmenu rather than
Â Â Â Â typing out a given google search (e.g. Â when one is searching
someone's
Â Â Â Â odd name.)
Â Â Â Â (c) In general, I like the xprop interface and allowing applications
other
Â Â Â Â than surf to interact with surf (which is what your new _SURF_FIND
feature
Â Â Â Â allows--which is great--which is why we need dmenu to get patched!)

And FWIW (sorry to double post) xclip -o | xclip -sel clip seems to do the same thing that ssel
is meant to do.

Peter

Uriel

2009-10-21 21:47:36 UTC

Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.

uriel

hiro

2009-10-21 21:54:17 UTC

But the source looks so neat in the browser... :(

This list is not worth reading any more.

Post by Uriel
Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.
uriel

Kurt H Maier

2009-10-21 22:15:19 UTC

Post by hiro
But the source looks so neat in the browser... :(
This list is not worth reading any more.

what keymap or MUA are you using that makes it easier to whine
constantly than unsubscribe

--
# Kurt H Maier

pancake

2009-10-22 12:42:49 UTC

The source looks better in vim (R)

This list is write-only and sometimes read is permitted.

The problem is that I find no way to get the source of the page from
the webkit API. This is why surf implements this by using the API to
watch the source. And this is also producing a page reload. So you can
keep browsing in source mode if you like which is probably unexpected.

About downloads, te only issue to get it right is the cookies, so I
would like to be able to get the cookie for a session to use with wget
or curl.

Btw I still find necessary the contextual menu to get URL of image,
URL of link .. Download in a separated window/client/app.

Displaying highlighted code on a surf with predefined CSS is weird.

Post by hiro
But the source looks so neat in the browser... :(
This list is not worth reading any more.

Post by Uriel
Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.
uriel

Kai Hendry

2009-10-22 12:50:36 UTC

Post by pancake
The source looks better in vim (R)

I am not 100% sure Webkit does this, though Firefox certainly does.
view-source fixes some problems in HTML, so when you copy and paste
Web content, it's likely to be actually valid or tidied.

`vim http://suckless.org` is good, though I think view-source: could
be enabled for the above reason.

pancake

2009-10-22 14:30:33 UTC

Your way cannot use cookies or keep sessions. The most interesting
HTML sources are usually after a login page

Post by Kai Hendry

Post by pancake
The source looks better in vim (R)

I am not 100% sure Webkit does this, though Firefox certainly does.
view-source fixes some problems in HTML, so when you copy and paste
Web content, it's likely to be actually valid or tidied.
`vim http://suckless.org` is good, though I think view-source: could
be enabled for the above reason.

s***@cs.tu-berlin.de

2009-10-22 13:37:05 UTC

Post by pancake
The source looks better in vim (R)

Post by pancake
About downloads, te only issue to get it right is the cookies, so I
would like to be able to get the cookie for a session to use with wget
or curl.

Post by pancake
Btw I still find necessary the contextual menu to get URL of image, URL
of link .. Download in a separated window/client/app.

+0.5:

0.5 goes for vimperator keysequence ;y<hintselection>

--
stanio_

Julien Steinhauser

2009-10-22 16:50:39 UTC

Post by pancake
Btw I still find necessary the contextual menu to get URL of image, URL
of link .. Download in a separated window/client/app.

I totally agree, it was a good feature that I would also welcome back.

At the moment the two lower items of the context menu :
Paste URI and Copy URI are doing pretty much the same as ctrl-y ctrl-p but are
IMHO not as convenient as the keybindings, replacing these two items
with something like "Download linked file" and "Copy link" would be more usefull.

Peter John Hartman

2009-10-22 19:09:33 UTC

Post by pancake
Btw I still find necessary the contextual menu to get URL of image, URL
of link .. Download in a separated window/client/app.

I totally agree, it was a good feature that I would also welcome back.
Paste URI and Copy URI are doing pretty much the same as ctrl-y ctrl-p but are
IMHO not as convenient as the keybindings, replacing these two items
with something like "Download linked file" and "Copy link" would be more usefull.

I second this. It took me a moment to realize not only that said Paste
URI/Copy URI items didn't do what you propose and then to realize that, as
far as a quick glance to the codebase allowed, surf has no way of doing
this. But it is an obvious need: sometimes you want to cut into x buffer
the link's url without actually navigating to the site, e.g.\ when you want
to navigate to the site via wget or some other agent.

Yours,
Peter

markus schnalke

2009-10-22 17:07:52 UTC

Post by pancake
The problem is that I find no way to get the source of the page from
the webkit API. This is why surf implements this by using the API to
watch the source.

The right way is to get the download problem solved and then download
the source.

meillo

pancake

2009-10-23 06:28:53 UTC

Is stupid to make two http queries because the second one doesn't have
to contain the same as the first one.

Think on a page doing some random contents at every refresh. Think on
referers while refreshing a page. Think on losing the network link
after getting the page rendered.

I hate to not being able to save the page that it's in front of me
because the network is down.

Post by markus schnalke

Post by pancake
The problem is that I find no way to get the source of the page from
the webkit API. This is why surf implements this by using the API to
watch the source.

The right way is to get the download problem solved and then download
the source.
meillo

Anselm R Garbe

2009-10-22 07:08:09 UTC

Post by Uriel
Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.

I disagree with downloads, because several stuff can't be download
without dealing with a valid session and it is a pain to download
stuff that requires session info using wget.

I have no strong feeling about source viewing, doesn't need to be
build-in, but since it's already implemented by webkit the source
viewing and profiling info of WebKit might be worth being made
accessible through surf, it'll help those who have to debug some web
stuff from time to time or that are masochists about analysing JS and
overall download performance similar to firebug. Usually no external
tool can provide this information correctly.

Kind regards,
Anselm

Peter John Hartman

2009-10-22 12:11:54 UTC

Post by Uriel
Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.

I disagree with downloads, because several stuff can't be download
without dealing with a valid session and it is a pain to download
stuff that requires session info using wget.
I have no strong feeling about source viewing, doesn't need to be
build-in, but since it's already implemented by webkit the source
viewing and profiling info of WebKit might be worth being made
accessible through surf, it'll help those who have to debug some web
stuff from time to time or that are masochists about analysing JS and
overall download performance similar to firebug. Usually no external
tool can provide this information correctly.
Kind regards,
Anselm

I agree with Anselm. An in-suff download solution is needed for precisely
the reason he gives.

Peter

Dieter Plaetinck

2009-10-22 12:20:44 UTC

On Thu, 22 Oct 2009 08:11:54 -0400 (EDT)

Post by Uriel
Surf should *not* handle downloads or display source, this are
clearly and obviously best handled by external tools and there is
zero reason for them to be part of any browser.

I disagree with downloads, because several stuff can't be download
without dealing with a valid session and it is a pain to download
stuff that requires session info using wget.
I have no strong feeling about source viewing, doesn't need to be
build-in, but since it's already implemented by webkit the source
viewing and profiling info of WebKit might be worth being made
accessible through surf, it'll help those who have to debug some web
stuff from time to time or that are masochists about analysing JS
and overall download performance similar to firebug. Usually no
external tool can provide this information correctly.
Kind regards,
Anselm

I agree with Anselm. An in-suff download solution is needed for
precisely the reason he gives.
Peter

what consitutes a "session" ? it's something that is maintained
serverside and the only way to "stay in it" is usually one or more of:
- keeping and sending cookie data
- keeping the same ip (and maybe user agent)
- requesting the urls they tell you to

afaik both curl and wget can use existing cookie storages on your hard
disk (and can use the useragent you tell them to), so don't really see
the problem.

Dieter

Charlie Kester

2009-10-22 16:09:25 UTC

Post by Dieter Plaetinck
what consitutes a "session" ? it's something that is maintained
- keeping and sending cookie data
- keeping the same ip (and maybe user agent)
- requesting the urls they tell you to
afaik both curl and wget can use existing cookie storages on your hard
disk (and can use the useragent you tell them to), so don't really see
the problem.

It seems to me that the problems being discussed in this subthread arise
because the "browser" combines two very distinct concerns:

- managing the http traffic to and from the website, which includes the
administrative details pertaining to the session

- rendering the documents obtained from the website

Perhaps we should be thinking about separating them?

Tadeusz Sośnierz

2009-10-22 16:15:58 UTC

It seems to me that the problems being discussed in this subthread arise
- managing the http traffic to and from the website, which includes the
administrative details pertaining to the session
- rendering the documents obtained from the website
Perhaps we should be thinking about separating them?

Then we will end up with some shit like uzbl - the browser which cannot
browse the web.

Regards

--
===========================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Dieter Plaetinck

2009-10-22 16:27:02 UTC

On Thu, 22 Oct 2009 18:15:58 +0200

Post by Dieter Plaetinck
what consitutes a "session" ? it's something that is maintained
- keeping and sending cookie data
- keeping the same ip (and maybe user agent)
- requesting the urls they tell you to
afaik both curl and wget can use existing cookie storages on your
hard disk (and can use the useragent you tell them to), so don't
really see the problem.

It seems to me that the problems being discussed in this subthread
- managing the http traffic to and from the website, which includes
the administrative details pertaining to the session
- rendering the documents obtained from the website
Perhaps we should be thinking about separating them?

Then we will end up with some shit like uzbl - the browser which
cannot browse the web.
Regards

it can browse the web just fine, thank you very much.
thanks for the kind words, but let's not go offtopic here.

markus schnalke

2009-10-22 17:14:19 UTC

Then we will end up with some shit like uzbl - the browser which cannot
browse the web.

You should know, it's not uzbl's fault, so don't blame it!

meillo

P.S.
Usually it's simple: If it can't be done right, one should think about
not using it at all. ... /me thinks about it.

Antoni Grzymala

2009-10-22 17:13:47 UTC

Post by Charlie Kester
Perhaps we should be thinking about separating them?

Then we will end up with some shit like uzbl - the browser which cannot
browse the web.

Why not? Just curious, haven't been using any of those yet.

--
[a]

s***@cs.tu-berlin.de

2009-10-22 17:14:10 UTC

Post by Tadeusz SoÅnierz
Then we will end up with some shit like uzbl - the browser which cannot
browse the web.

What web do you have there? It must be a strange one. I haven't used any
other X browser at home for months (except for testing surf). Please
consider to try to localise the problem in the system consisting of you,
the browser, and the web. And then report again.

--
stanio_

Tadeusz Sośnierz

2009-10-22 17:30:24 UTC

Post by s***@cs.tu-berlin.de

Post by Tadeusz SoÅnierz
Then we will end up with some shit like uzbl - the browser which cannot
browse the web.

Well, looks like I have to apologize. For some unknown reason I was
thinking that uzbl is handling link-clicking through some external
scripts, but I just cloned the git version and looks like I was wrong.
Sorry for my trolling, mea culpa.
Regards

--
===========================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Anselm R Garbe

2009-10-22 16:18:12 UTC

I'm not against providing a nice integration of external tools like
wget into surf, however I have seen downloads that were triggered by
some JavaScript and making that work with an external tool sounds like
a challenge (unless you don't hack into webkit's resource handler
layer). That's why I think having both (built-in default) and
possibility for seamless integration of external tool would be best.
I'd go that far to keep external tool integration that simple to avoid
dealing with session propagation.

Kind regards,
Anselm

Claudio M. Alessi

2009-10-23 09:02:37 UTC

Post by Charlie Kester
It seems to me that the problems being discussed in this subthread arise
- managing the http traffic to and from the website, which includes the
administrative details pertaining to the session
- rendering the documents obtained from the website
Perhaps we should be thinking about separating them?

That's exactly what I was thinking about after reading the Anselm post. I'm
pretty sure this is the way to go. We need a "core browser" which is just
indipendent from the viewer. Well, it isn't right to call it "browser" but I
don't find a better name ATM. Then you can use whatever tool you want to do
each thing as you like, better and easily.

Regards,
Claudio M. Alessi.

--
JID: smoppy AT gmail.com
WWW: http://cma.teroristi.org

hiro

2009-10-23 14:12:08 UTC

Should do a 9p file server with some kind of cookie and session cache,
also precache.

Post by Claudio M. Alessi

Moritz Wilhelmy

2009-10-23 21:30:32 UTC

Post by hiro
Should do a 9p file server with some kind of cookie and session cache,
also precache.

using 9p for surf sounds great. This way it should be simple to share data between multiple surf windows
Regards

markus schnalke

2009-10-22 16:56:47 UTC

It it's something that bumps the required Webkit version up, then I
disagree.

IMO the main problem with uzbl/surf is that very new versions of Webkit,
which are often not included in operating system distributions, are
required. If it is possible to hold the version number down, then it
would be nice to do so.

meillo

Uriel

2009-10-24 04:20:21 UTC

Post by Uriel
Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.

I disagree with downloads, because several stuff can't be download
without dealing with a valid session and it is a pain to download
stuff that requires session info using wget.

Wget can use the browser's cookies, so in theory this should not be a
problem, but you are probably right that I underestimated how
braindamaged the web is and there might be sites where making this
work would be tricky.

Post by Anselm R Garbe
I have no strong feeling about source viewing, doesn't need to be
build-in, but since it's already implemented by webkit the source
viewing and profiling info of WebKit might be worth being made
accessible through surf, it'll help those who have to debug some web
stuff from time to time or that are masochists about analysing JS and
overall download performance similar to firebug. Usually no external
tool can provide this information correctly.

That might be the case, but none of those things are the job of a web
browser, and if somebody
wants to do that kind of work, they can install some braindead
browsers that supports all that crap. And just because webkit
'implements' most of it is no excuse, the cost is not just in code,
but in complexity of interface. Something as insignificant and lame as
source viewing is added to surf, and we already have got people
reporting problems with it.

Also 'view source' is an instance of a much more general issue:
passing the contents of the current page to an external program. This
should be supported as this fits well with the core function of a
browser, displaying the source of a page does not.

To put a more concrete example: perhaps somebody wants to look at the
source using less(1), or rio's win, or perhaps the user just wants to
save (cat > foo.html) the source, or god know what, maybe one wants to
pass the source to a script that extracts the img links from the
source and downloads them, or billion other possibilities all of which
should be supported but should in no way be built into surf.

uriel

Post by Anselm R Garbe
Kind regards,
Anselm

Anselm R Garbe

2009-10-24 07:45:32 UTC

Post by Uriel

Post by Uriel
Surf should *not* handle downloads or display source, this are clearly
and obviously best handled by external tools and there is zero reason
for them to be part of any browser.

I disagree with downloads, because several stuff can't be download
without dealing with a valid session and it is a pain to download
stuff that requires session info using wget.

That might be the case, but none of those things are the job of a web
browser, and if somebody
wants to do that kind of work, they can install some braindead
browsers that supports all that crap. And just because webkit
'implements' most of it is no excuse, the cost is not just in code,
but in complexity of interface. Something as insignificant and lame as
source viewing is added to surf, and we already have got people
reporting problems with it.
passing the contents of the current page to an external program. This
should be supported as this fits well with the core function of a
browser, displaying the source of a page does not.
To put a more concrete example: perhaps somebody wants to look at the
source using less(1), or rio's win, or perhaps the user just wants to
save (cat > foo.html) the source, or god know what, maybe one wants to
pass the source to a script that extracts the img links from the
source and downloads them, or billion other possibilities all of which
should be supported but should in no way be built into surf.

I agree.

Kind regards,
Anselm

Kris Maglione

2009-10-24 07:55:35 UTC

Post by Uriel

Post by Anselm R Garbe
I disagree with downloads, because several stuff can't be download
without dealing with a valid session and it is a pain to download
stuff that requires session info using wget.

No, I think you're right about this one. Surf can make
provisions for an external downloader to have whatever info it
needs. The cookies file should be enough in most cases. The
entire cookie header for the domain could also be put into an
environment variable for the downloader. So should the
user-agent string and the referrer. The only possible snagging
point is POST data, which could go into an environment variable,
but as it might be quite large, it might have to go into a
temporary file instead.

Post by Uriel
passing the contents of the current page to an external program. This
should be supported as this fits well with the core function of a
browser, displaying the source of a page does not.

I agree. Not only is it useful to be able to pipe the current
page to external programs, built-in source viewers tend to suck.
It's a lot easier to just use your favorite text editor in most
cases.

--
Kris Maglione

A most important, but also most elusive, aspect of any tool is its
influence on the habits of those who train themselves in its use. If
the tool is a programming language this influence is, whether we like
it or not, an influence on our thinking habits.
--Edsger W. Dijkstra

Jessta

2009-10-24 08:38:11 UTC

I quite like the idea of a http session manager, that holds session
data and a page cache, that other programs can make requests to. It
might also help with how I used to use tabs to cache pages in advance
of viewing them.

--
=====================
http://jessta.id.au

Uriel

2009-10-24 19:35:36 UTC

While this is a nice idea (this is what webfs does in Plan 9), in
practice is a huge pain, and the design of the web violates layering
so much as to make such a design very tricky and painful. Plus writing
an http client that will handle all the crap out there is *really*
hard (you can count the reliable client implementations of http 1.1
with the fingers of one hand, of course we could use curl or some
other lib, but that is just one more external dependency.)

The chrome folks have managed to build something quite similar to
this, but they have huge development (and specially testing)
resources. This is another reason why I still think building surf on
top of the chromium infrastructure is a much better idea than using
webkit directly.

uriel

Post by Jessta
I quite like the idea of a http session manager, that holds session
data and a page cache, that other programs can make requests to. It
might also help with how I used to use tabs to cache pages in advance
of viewing them.
--
=====================
http://jessta.id.au

Charlie Kester

2009-10-24 22:01:35 UTC

writing an http client that will handle all the crap out there is
*really* hard

Why is this the goal?

Why, when I want to browse a sane website like suckless.org, for
example, should I have to use a browser containing a bunch of convoluted
code designed to handle the kind of "crap" you mean? I'd like to be
able to use a browser that, because it's only intended for use with
non-crappy sites, can be written in a way that's simpler, less buggy and
more secure.

If I'm browsing a suckless webpage in a suckless browser and click a
link to a page that sucks, perhaps the right thing to do is to open that
page in an external browser (which probably also sucks)?

Couldn't we have something like mime types for websites, reflecting
their use (or non-use) of various "crap" and associating them with
appropriately-written browsers?

Uriel

2009-10-25 06:45:53 UTC

writing an http client that will handle all the crap out there is
*really* hard

Then go use abaco.

The rest of us need a browser that can deal with crap, because 99.99%
of the websites out there run on http servers that suck, and produce
html/js/flash/whatever which consists of mountains of fermented
diseased elephant feces.

Post by Charlie Kester
If I'm browsing a suckless webpage in a suckless browser and click a
link to a page that sucks, perhaps the right thing to do is to open that
page in an external browser (which probably also sucks)?
Couldn't we have something like mime types for websites, reflecting
their use (or non-use) of various "crap" and associating them with
appropriately-written browsers?

We have gone over this a billion times: the web intrinsically *sucks*,
get over it, and stop trying to wish it away, it doesn't work.

uriel

Anselm R Garbe

2009-10-25 10:14:47 UTC

Post by Uriel
The chrome folks have managed to build something quite similar to
this, but they have huge development (and specially testing)
resources. This is another reason why I still think building surf on
top of the chromium infrastructure is a much better idea than using
webkit directly.

I have looked into chromium several times during last months for
reasons that aren't related to suckless.org. I agreed in the beginning
of surf to make it chromium based, but during the time (basically the
more I looked into the chromium source and build system) I more and
more conclude that chromium should be avoided. A recent debug build of
chromium resulted in 10GB (!!!) overhead on my disk with a 450MB (!!!)
chrome executable on Linux (stripped it was about 70MB (!!!)). The
source tarball containing some svn history of chromium is 700MB -- if
you ask me when comparing that to webkitgtk, webkit looks lean. So to
summarise I don't think that making surf based on chromium is a good
idea after all, even if some details and design decisions in chromium
are nice. But it is definately not the suckless way and I also think
we lack enough man power to maintain a rip-off of chromium for surf
and keeping it in sync (esp. because there is no real documented
chromium API, but there is a sort of ok;ish documented webkitgtk API).

Kind regards,
Anselm

s***@cs.tu-berlin.de

2009-10-24 11:25:51 UTC