You are not logged in.
Why don't you just use o?
Sorry I wasn't clear, I just meant mimicing the behavior of asking for an argument if one isn't given, not the actual opening of an url.
For example, to borrow a friend's use-case, a script to view a set of subreddits might look like:
#!/bin/bash
if ! [ "$DWB_ARGUMENT" ]; then
echo "prompt subreddits:" > "$DWB_FIFO"
DWB_ARGUMENT=$(<"$DWB_OUT_FIFO")
fi
reddits=$(echo $DWB_ARGUMENT | sed 's/[+, ]/+/g')
echo "open http://reddit.com/r/$reddits"
...using a theoretical 'prompt' command and some theoretical "$DWB_OUT_FIFO" for getting data out of dwb requested by a prior command (in this case 'prompt').
Not sure if FIFOs can be done that way, or if this makes any sense at all, but the point would just be to have a userscript that one way or another gets its argument.
One could imagine something more specific to this use-case, like:
#!/bin/bash
# dwb: Control r <arg>
reddits=$(echo $DWB_ARGUMENT | sed 's/[+, ]/+/g')
echo "open http://reddit.com/r/$reddits"
...where the '<arg>' (or whatever) on the keybinding line tells dwb that the userscript requires an argument, so if one is not given then it should be prompted for (like the 'open' command does).
Offline
This is not possible in dwb, in general this would be possible with fifos but i don't think that i will ever implement it. I thought about it about a year ago but i decided against it, instead i decided to implement the javascript api which has some advantages, it produces less overhead because it doesn't spawn a new process, it gives you access to gobject-properties, also the execution time of javascript scripts is much faster than that of bash scripts, i think it is also faster than any other scripting language that communicates over a fifo with dwb, it only might be slower if you do heavy calculations in the script. The main reason why 'webjavascript' is slow is that dom-access slows scripts down but userscripts don't have access to the dom. One disadvantage of course is that most people don't like javascript.
Offline
There is no builtin possibility to change the color of about:blank. You can change the background color with a custom user stylesheet by setting the the body's background color, or with the following userscript
#!javascript signals.connect("documentLoaded", function (wv) { if (wv.uri == "about:blank") { wv.inject("document.body.style.background = '#000';"); } });
Thanks portix.
Offline
I keep getting this error message when i try to load facebook, don't know if it's an error on my end or what.
Error parsing message: too many header bytes seen; overflow detected
Same here,as i said on IRC to.Happens only on facebook.Portix said its cookies related .. on luakit i didnt had this problem.A quick fix its to use sanitize function,and clear all data..
Offline
TheLemonMan wrote:I keep getting this error message when i try to load facebook, don't know if it's an error on my end or what.
Error parsing message: too many header bytes seen; overflow detected
Same here,as i said on IRC to.Happens only on facebook.Portix said its cookies related .. on luakit i didnt had this problem.A quick fix its to use sanitize function,and clear all data..
Thanks for the hint. Anyway you can solve the problem without wiping all your data with this oneliner
cd ~/.config/dwb/default && mv cookies cookies.bak && grep -v facebook cookies.bak > cookies && rm cookies.bak
Offline
cd ~/.config/dwb/default && mv cookies cookies.bak && grep -v facebook cookies.bak > cookies && rm cookies.bak
Tnx for the idea to i hope it will do the trick
Offline
Luakit's cookie handling is completely different from dwb's cookie handling. It seems that dwb does something wrong but i don't know when i have time to work on cookie handling. Oddly it only seems to happen on facebook and i don't have a facebook account and also won't create an account.
Have you tried to only allow session cookies on facebook?
Offline
This is not possible in dwb, in general this would be possible with fifos but i don't think that i will ever implement it. I thought about it about a year ago but i decided against it, instead i decided to implement the javascript api which has some advantages, it produces less overhead because it doesn't spawn a new process, it gives you access to gobject-properties, also the execution time of javascript scripts is much faster than that of bash scripts, i think it is also faster than any other scripting language that communicates over a fifo with dwb, it only might be slower if you do heavy calculations in the script. The main reason why 'webjavascript' is slow is that dom-access slows scripts down but userscripts don't have access to the dom. One disadvantage of course is that most people don't like javascript.
Very interesting. Thanks for the info! Guess I'll finally need to become more competent in javascript.
Offline
Extensions in /usr/share/dwb/extensions don't seem to be picked up for me, or at least the formfiller extension was not found when I created a userscript containing extensions.load("formfiller"). I had to link the formfiller extension into ~/.local/share/dwb/extensions/.
The javascript api documentation seems to say that extensions will be searched for in /usr/share/dwb/extensions. The code in dwb's extensions.js seems to suggest this as well. Why is it not happening?
Offline
I cannot reproduce this, dwb first searches for extensions in ~/.local/share/dwb/extensions and then in /usr/share/dwb/extensions. Can you paste the output if you start dwb from a terminal?
Offline
I'm trying to get the external editor feature to work with urxvt/vim. The command I am using is "urxvtc -e vim dwb_uri" A blank vim opens up in urxvt, but when I type something in and then :wq nothing happens. Am I doing something wrong?
Offline
The external editor will not work with urxvtc. dwb waits for the editor's process to exit before it injects the text into the textarea/textinput but urxvtc immediately detaches from the parent process so dwb doesn't know when the editor is closed. If you want to use urxvt together with vim you have to use urxvt, not urxvtc.
Offline
Ahh, sweet. Working great now. Thanks.
Offline
I cannot reproduce this, dwb first searches for extensions in ~/.local/share/dwb/extensions and then in /usr/share/dwb/extensions. Can you paste the output if you start dwb from a terminal?
So this is interesting... for me, dwb looks in the system directory only if a ~/.local/share/dwb directory exists.
If ~/.local/share/dwb exists (with nothing in it), dwb outputs:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
DWB EXTENSION: extension formfiller: Successfully loaded and initialized.
If ~/.local/share/dwb does not exist:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
==> DEBUG [MESSAGE] : In file /home/dabrado/.config/dwb/userscripts/load-formfiller
Offline
Offline
Awesome, thanks.
Offline
Offline
Confirmed. Thanks!
Offline
Certain websites--especially news sites--spike dwb's CPU usage up to 100%. Any idea why, and whether this can be fixed? Sometimes there's a noticeable lag on the website causing the CPU spike, sometimes not. And usually it also causes my laptop's fan to start running furiously.
Here is one site where it happens: http://www.tor.com/blogs/2011/06/norvig … ture-of-ai. On this site, there's no lag or anything, yet my fan start spinning and htop reports 100% CPU usage, until I close the tab.
Last edited by brianb (2012-07-25 14:01:33)
Offline
Certain websites--especially news sites--spike dwb's CPU usage up to 100%. Any idea why, and whether this can be fixed? Sometimes there's a noticeable lag on the website causing the CPU spike, sometimes not. And usually it also causes my laptop's fan to start running furiously.
Same here, but it seems to me now that this is a problem in general with webkit browsers. I've tried the problematic websites with luakit, surf, etc. and I have the same behaviour. Could you try that, Brian? Maybe I'm just seeing things.
Manolo
Offline
Could you try that, Brian? Maybe I'm just seeing things.
I just opened that same tor link in both dwb and luakit. htop reports 99.0% CPU usage for dwb, and 0.0% for luakit. :-/
Offline
Maybe I'm just adding noise here: although I do see very high CPU usage with dwb in certain websites, it's hardly ever 100%. Besides, that tor link behaves OK for me here -- so you should probably just disregard my comment.
Last edited by manolomartinez (2012-07-25 15:42:03)
Offline
Hi, I've been using your browser for a while, but just today something started happening - When I click a link that starts with http:// in, for example, Skype, it opens the link AND opens another tab, where it seems to google-search the letters HTTP.
So essentially, it loads the word http as a search, and the link I clicked...
Is there a fix for that, or is that something on my end?
EDIT:
In fact, this only seems to happen for Skype!
Weird, I'll have a hunt around
Last edited by Reded (2012-07-25 19:33:43)
"Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying "End-of-the-World Switch. PLEASE DO NOT TOUCH", the paint wouldn't even have time to dry."
Offline
Do you have addressbar-dns-lookup enabled? You can first try to disable it, this setting isn't a good idea anyway so this will probably be removed in the future.
Offline