uzbl. A browser that adheres to the unix philosophy.

dusanx · 2009-04-24 17:59:23

* statusbar? (the bar you see in pretty much every gtk program at the bottom. eg firefox)
consumes too much space (if always visible) for the little it is used. (+ you can put only 1 message in it at a time!)
-> option 1: no statusbar at all. when hovering over a link (or pressing key to preview the url without changing page) -> show url in tooltip on page.
-> option 2: toggle visibility of statusbar on/off when hovering over a link. since it's at the bottom I don't think it will disturb too much.

option 3: no statusbar at all, hover link is visible in window title, see my source. Tooltips would be annoying IMO.

* viewing progress/state of pageload? most programs use statusbar for this.
-> option 1: titlebar can show a percentage when it's loading a new page.
-> option 2: toggle a statusbar everytime we start loading a new page.

Definitely #1.

* uri bar -> yes, even though we can write stuff to the fifo, it can still be convenient to change the url manually and stuff, so a widget in uzbl itself is good.

My vote goes to hidden bottom 'status bar like' edit. Can be used for navigation, search etc. Becomes visible on key press, hides as soon as input is finished.

* tabs -> yes. you don't have to use them, but you can.

Boooo. We need no stinking tabs Who will agree how tabs should look -> we need tabs skinning etc.

* back/forward/.. buttons? -> no: use keyboard shortcuts.

You can take this from my fork right now. We need to agree how to configure hotkeys later.

* searching in a page? not sure.. maybe we can abuse the statusbar for that too.
eg toggle it on when the user wants to search for something and then do searching in some vim-like fashion.
we don't need a gtk text entry widget, just a feedback display of what the current command is.

See above

all of the above goes in 1 bar at the top of the program. there should be a key to toggle visibility of it and one to toggle visibilety + focus on the entrybar at once.

This may be too radical change, not sure how much I like it.

btartsa · 2009-04-24 18:20:16

rson451 wrote:

It's already got a name.

I kind of got the feeling that this would end up more that one project at some point. Whatever.

dusanx · 2009-04-24 18:40:28

We will need no edit/status bar at all. I will use dmenu for search/url change tomorrow.

rson451 · 2009-04-24 18:55:44

I like the idea of taking the junk that is normally stuffed in the status bar and prepending it to the window title. Very nifty way to save real estate.

Shunpike · 2009-04-24 19:03:58

rson451 wrote:

I like the idea of taking the junk that is normally stuffed in the status bar and prepending it to the window title. Very nifty way to save real estate.

Yeah but if (like me) you don't have window titles ? There should be an option to see it somewhere else

Dieter@be · 2009-04-24 19:08:11

Well, I look at it like this:
1) you stuff it in the window title -> you _need_ to see the window title
2) you stuff it in a statusbar -> you can disable window borders and/or fullscreen the application.

In both cases you see 1 "bar" with stuff in it.

Btw dusanx your code looks okay, I'm gonna try If I can make something vim-like of it, because that's the interface i prefer, not finger twisting modkey+someotherkey combo's

something like:

u : change uri and go to it
r : refresh
i : enter insert mode so you can type text in html forms
b : back
f :forward

etc etc

dusanx · 2009-04-24 19:40:07

Dieter@be wrote:

1) you stuff it in the window title -> you _need_ to see the window title
2) you stuff it in a statusbar -> you can disable window borders and/or fullscreen the application.
In both cases you see 1 "bar" with stuff in it.

True, I am using dwm so I always see active window title at the screen top.
I think that we need:
1. exactly same text in title and status bars.
2. hidestatus switch
3. hidescrollbars switch

This way we have all variants covered.

Btw dusanx your code looks okay, I'm gonna try If I can make something vim-like of it, because that's the interface i prefer, not finger twisting modkey+someotherkey combo's
something like:
u : change uri and go to it
r : refresh
i : enter insert mode so you can type text in html forms
b : back
f :forward
etc etc

Nice

I could not check what html component has focus so if you use plain 'b' for back and try to type your username (that contains 'b') in any edit field you will trigger back. That's why I had to add alt modifier.

Dieter@be · 2009-04-24 19:54:32

I just committed:
- reading settings from a config file
- logging to a history file (if set in config file).

now we just need to get the fifo stuff working and we can do dmenu scripts to go to pages from history
http://github.com/Dieterbe/uzbl/commit/ … 4a5a0a8776

dusanx wrote:

I could not check what html component has focus so if you use plain 'b' for back and try to type your username (that contains 'b') in any edit field you will trigger back. That's why I had to add alt modifier.

That's why i would use 'i' to go in "insert" mode. eg in insert mode your keys are just passed on without being interpreted. until you press esc.

Last edited by Dieter@be (2009-04-24 19:56:14)

dusanx · 2009-04-24 20:09:48

Dieter@be wrote:

I just committed:
- reading settings from a config file
- logging to a history file (if set in config file).

Great. Hmm, how do I take part of your code? Copy/paste or there is better way?

now we just need to get the fifo stuff working and we can do dmenu scripts to go to pages from history
http://github.com/Dieterbe/uzbl/commit/ … 4a5a0a8776
dusanx wrote:
I could not check what html component has focus so if you use plain 'b' for back and try to type your username (that contains 'b') in any edit field you will trigger back. That's why I had to add alt modifier.
That's why i would use 'i' to go in "insert" mode. eg in insert mode your keys are just passed on without being interpreted. until you press esc.

Be careful with insert mode and hard-coded shortcuts. I am using vim but I want alt+A and alt+R for back/forward. Using colemak so they are convenient. I don't want to need to switch to insert mode and use esc in browser. Can we do some smart configuration?

Dieter@be · 2009-04-24 20:18:48

dusanx wrote:

Dieter@be wrote:
I just committed:
- reading settings from a config file
- logging to a history file (if set in config file).
Great. Hmm, how do I take part of your code? Copy/paste or there is better way?

Well, if you have forked me on github, and cloned your github uzbl to your local pc, then I think you have listed me in your branches/remotes. (type git branch and git remote to see). If not, have a look at the guides on http://github.com/guides/home. Anyway, if you have me under your branches/remotes, do a git fetch and there should be a way to pull in individual commits. I don't know the exact commands for that.

dusanx wrote:

Dieter@be wrote:
dusanx wrote:
I could not check what html component has focus so if you use plain 'b' for back and try to type your username (that contains 'b') in any edit field you will trigger back. That's why I had to add alt modifier.
That's why i would use 'i' to go in "insert" mode. eg in insert mode your keys are just passed on without being interpreted. until you press esc.
Be careful with insert mode and hard-coded shortcuts. I am using vim but I want alt+A and alt+R for back/forward. Using colemak so they are convenient. I don't want to need to switch to insert mode and use esc in browser. Can we do some smart configuration?

yeah, i want all keyboard shortcuts to be configurable.

sentientswitch · 2009-04-24 21:16:12

* statusbar? (the bar you see in pretty much every gtk program at the bottom. eg firefox)
consumes too much space (if always visible) for the little it is used. (+ you can put only 1 message in it at a time!)
-> option 1: no statusbar at all. when hovering over a link (or pressing key to preview the url without changing page) -> show url in tooltip on page.
-> option 2: toggle visibility of statusbar on/off when hovering over a link. since it's at the bottom I don't think it will disturb too much.

Have one status bar like vimperator, it can show this kind of info. It could also be set to only appear when in use if you so desire.

* viewing progress/state of pageload? most programs use statusbar for this.
-> option 1: titlebar can show a percentage when it's loading a new page.
-> option 2: toggle a statusbar everytime we start loading a new page.

This can be done in the vimperator-like bar

* uri bar -> yes, even though we can write stuff to the fifo, it can still be convenient to change the url manually and stuff, so a widget in uzbl itself is good.

There would be a command to bring up the current uri, editable, in the vimp bar.

* tabs -> yes. you don't have to use them, but you can.

If the idea of one instance per page is being abandoned then yes. I think it'd be nice to use 1 instance/page with a controller application wrapping it up and providing tab functionality, it'd be useful in case of crashes of a single tab for example. The vimp bar/tabs would be in the controller and would interact with each instance via fifo.

* back/forward/.. buttons? -> no: use keyboard shortcuts.

+1

* searching in a page? not sure.. maybe we can abuse the statusbar for that too.
eg toggle it on when the user wants to search for something and then do searching in some vim-like fashion.
we don't need a gtk text entry widget, just a feedback display of what the current command is.

vimp bar again

* scrollbar? no: use keyboard shortcuts. we should however have some info about the page length and where we are.
-> option 1: put a percentage in the window title
-> option 2: everytime you hit a key to change position, temporarily make a statusbar visible and put the percentage in the statusbar.
what will we do with pages who are too wide? horizontal scrolling?

vimp bar can contain an indicator just like vim does.

all of the above goes in 1 bar at the top of the program. there should be a key to toggle visibility of it and one to toggle visibilety + focus on the entrybar at once.

+1 (but I'd prefer it at the bottom )

HashBox · 2009-04-24 22:12:56

Dieter@be wrote:

I'll look at your guys fifo code tonight. I'm also thinking about how to get data in and out the program. A fifo is afaik only half duplex, so for things like querying the current url I wonder how we should implement that.

I started looking into this last night, and I've been thinking about an approach I might take with my branch, and that is to maybe drop FIFOs all together and use stdin and stdout, and possibly hook that up directly to a javascript repl, so that you're able to query nearly anything and get a response. You would still be able to redirect a FIFO into the stdin as far as I know so it could be usable from outside scripts, and you could redirect stdout to a file or wherever was needed.
My idea is to learn how to use GtkSocket and GtkPlug so I can make a wrapper UI that can spawn these browser windows as tabs, and communicate with them through stdin and stdout. Seems quite efficient to me. A smaller uzblctrl app could be made to send javascript commands to a fifo in a simple way as it is now (forward, back, http://uri, etc).

Barrucadu · 2009-04-24 22:39:29

I'll have a play with implementing a command/mode line for complete keyboard control.

I like the JavaScript extensibility and the GtkSocket/GtkPlug ideas.

Nezmer · 2009-04-24 22:57:53

sentientswitch wrote:

* tabs -> yes. you don't have to use them, but you can.
If the idea of one instance per page is being abandoned then yes. I think it'd be nice to use 1 instance/page with a controller application wrapping it up and providing tab functionality, it'd be useful in case of crashes of a single tab for example. The vimp bar/tabs would be in the controller and would interact with each instance via fifo.

Agreed .
That's one of the advantages Google Chrome bragged about .

nsf · 2009-04-25 03:34:09

I like the project. It's already usable for reading offline documentation.
For example I have a huge directory ~/offline with a lot of docs.
Then I add a menu entry to my openbox with something like: uzbl --uri file:///home/nsf/offline/pango-html-1.22.4/index.html
And it works! Starts up really fast.

Update:
Also it will be a great project for newbie webkit programmers. Because tiny examples like this one are the best.. always..

Last edited by nsf (2009-04-25 03:44:00)

Dieter@be · 2009-04-25 06:27:02

HashBox wrote:

Dieter@be wrote:
I'll look at your guys fifo code tonight. I'm also thinking about how to get data in and out the program. A fifo is afaik only half duplex, so for things like querying the current url I wonder how we should implement that.
I started looking into this last night, and I've been thinking about an approach I might take with my branch, and that is to maybe drop FIFOs all together and use stdin and stdout, and possibly hook that up directly to a javascript repl, so that you're able to query nearly anything and get a response. You would still be able to redirect a FIFO into the stdin as far as I know so it could be usable from outside scripts, and you could redirect stdout to a file or wherever was needed.
My idea is to learn how to use GtkSocket and GtkPlug so I can make a wrapper UI that can spawn these browser windows as tabs, and communicate with them through stdin and stdout. Seems quite efficient to me. A smaller uzblctrl app could be made to send javascript commands to a fifo in a simple way as it is now (forward, back, http://uri, etc).

The problem witth stdout (correct me if I'm wrong, maybe i'm missing somethnig) is you need to "hook" something up to it (pipe) when you start the process. so you're getting lots of output, and it's hard to know when the string comes you're interested in (maybe we could use prefixes).
Is there a way to do this: the program has already been launched, and then you want to say "ok now i'm gonna send something to it's stdin and listen to it's stdout and when I have what I want i'm done". ? afaik not.
Actually, I'm wondering: which information do we really need to pull from uzbl?. We can get the current url easily, because it will be the last entry in the history log file. anything else?
The GtkSocket and GtkPlug stuff looks interesting indeed.

dusanx · 2009-04-25 06:38:23

I will try to add 'open in new window' and maybe few more functions today. Few sites want to open hyperlink in another tab/window and that's where uzbl does nothing now.

We also need home folder specified in settings file -- uri command line switch should work as before but home key should go to home url specified in settings file.

We also need open in new tab/window switch. I don't want tabs but we need to keep code universal.

Dieter@be: I can also make key handling with insert or not functionality but I don't want us to duplicate jobs. Let's specify:

-What keys/functions we need
-What app lacks
-Who will do what

dusanx · 2009-04-25 07:04:54

Dieter@be:

When I go to my fork queue on github and want to integrate your changes they all fail?

Dieter@be · 2009-04-25 07:09:11

dusanx wrote:

I will try to add 'open in new window' and maybe few more functions today. Few sites want to open hyperlink in another tab/window and that's where uzbl does nothing now.

ok, but this will be keyboard controlled right? (vimperator style)

dusanx wrote:

We also need home folder specified in settings file -- uri command line switch should work as before but home key should go to home url specified in settings file.

with home folder you mean home page? the actual home directory of the user can be get with getenv("HOME"). (actually i want to use the xdg basedir spec so it will be getenv("XDG_CONFIG_HOME") and similar.

dusanx wrote:

We also need open in new tab/window switch. I don't want tabs but we need to keep code universal.

right.

dusanx wrote:

Dieter@be: I can also make key handling with insert or not functionality but I don't want us to duplicate jobs. Let's specify:
-What keys/functions we need
-What app lacks
-Who will do what

what app needs: pretty much everything listed on http://github.com/Dieterbe/uzbl/blob/b8 … 8e1/README
with "key handling with insert or not functionality" do you mean vim-style?. That would be nice though barrucadu said he was giving it a shot already.
here is a list to get you started.

u : change uri and go to it
r : refresh
i : enter insert mode so you can type text in html forms (esc to escape and go back in command mode)
b : back
f :forward

I can/will work on commandline arguments, and have a better look at the fifo code from barrucadu and friends.
i was also thinking about working more on config file handling (and configuring keyboard shortcuts) but if someone wants this task, just ask. it's pretty easy but someone has to do it
I'm also doing some performance testing on huge dummy history files and dmenu stay tuned.

dusanx wrote:

Dieter@be:
When I go to my fork queue on github and want to integrate your changes they all fail?

uhm.. sorry don't know.

note to all forkers: my master is branch is my "stable", which aims to always be a uzbl that's actually usable. experimental is where I do my new fancy stuff. once I get something decent working there I merge it into master. So you can start off from my master branch to have a "stable starting point" (this is what most have done already), and merge in changes as they become available.

Last edited by Dieter@be (2009-04-25 07:12:22)

XFire · 2009-04-25 07:11:44

Will the config file reside in ~/.config/uzbl or in the main home directory or ~/.uzbl ?

Last edited by XFire (2009-04-25 07:11:53)

Dieter@be · 2009-04-25 07:13:07

XFire wrote:

Will the config file reside in ~/.config/uzbl or in the main home directory or ~/.uzbl ?

in XDG_CONFIG_HOME/uzbl, which is ~/.config/uzbl on most systems. (see xdg basedir spec)

dusanx · 2009-04-25 07:36:17

Dieter@be wrote:

dusanx wrote:
I will try to add 'open in new window' and maybe few more functions today. Few sites want to open hyperlink in another tab/window and that's where uzbl does nothing now.
ok, but this will be keyboard controlled right? (vimperator style)

No, keys are different topic and fairly easy to implement. What I meant was function that catches 'open in new window' signal, both from the right click menu and href target=new on html pages. When we have proper function we can call it from key press event of course.

dusanx wrote:
We also need home folder specified in settings file -- uri command line switch should work as before but home key should go to home url specified in settings file.
with home folder you mean home page? the actual home directory of the user can be get with getenv("HOME"). (actually i want to use the xdg basedir spec so it will be getenv("XDG_CONFIG_HOME") and similar.

Lol too early here. Yup, I meant home page.

dusanx wrote:
Dieter@be: I can also make key handling with insert or not functionality but I don't want us to duplicate jobs. Let's specify:
-What keys/functions we need
-What app lacks
-Who will do what
what app needs: pretty much everything listed on http://github.com/Dieterbe/uzbl/blob/b8 … 8e1/README
with "key handling with insert or not functionality" do you mean vim-style?. That would be nice though barrucadu said he was giving it a shot already.
here is a list to get you started.
u : change uri and go to it
r : refresh
i : enter insert mode so you can type text in html forms (esc to escape and go back in command mode)
b : back
f :forward
I can/will work on commandline arguments, and have a better look at the fifo code from barrucadu and friends.
i was also thinking about working more on config file handling (and configuring keyboard shortcuts) but if someone wants this task, just ask. it's pretty easy but someone has to do it
I'm also doing some performance testing on huge dummy history files and dmenu stay tuned.

Yes, I can do this. B, is it ok with you?

dusanx wrote:
Dieter@be:
When I go to my fork queue on github and want to integrate your changes they all fail?
uhm.. sorry don't know.
note to all forkers: my master is branch is my "stable", which aims to always be a uzbl that's actually usable. experimental is where I do my new fancy stuff. once I get something decent working there I merge it into master. So you can start off from my master branch to have a "stable starting point" (this is what most have done already), and merge in changes as they become available.

No problem. Can you also use merge when you use my code? If we fail to sync properly we will all have to use copy/paste and then we don't need git at all.

What about idea to have same text in title and status bars with switch to hide status? You have basic code in my source. I think that's important feature.

dusanx · 2009-04-25 07:51:28

I was thinking and can't find any need for status bar editing. Status bar is ok as title bar replacement if you don't have title bar and that's all.
Also we may need simpler fifo handling:

#1 User wants to open history or bookmarks page or manually type new url

Uzbl starts dmenu. Dmenu can have listing that has combined bookmarks and history. You can also type anything you want (new url) that is not on the list. Uzbl waits for returned stream and navigates there. Should be easy since dmenu is uzbl spawned process. No need for any complicated stream handling. We can have covered all navigation related edits in one simple dmenu call.

#2 Search

Uzbl starts dmenu with either empty list or search history list. Simple.

Did I missed any edit variant?

Dieter@be · 2009-04-25 08:19:42

dusanx wrote:

No problem. Can you also use merge when you use my code? If we fail to sync properly we will all have to use copy/paste and then we don't need git at all.

Yep, if I find usefull things I'll merge

dusanx wrote:

What about idea to have same text in title and status bars with switch to hide status? You have basic code in my source. I think that's important feature.

I would just use a flag to switch between them, so stuff doesn't get shown twice. But, I still like the idea of showing a little bar with a vim-like display to change url etc. (can be made invisible 99.9% of the time)

Barrucadu · 2009-04-25 08:28:56

Woo, I have a working mode line thingy

Arch Linux

#101 2009-04-24 17:59:23

Re: uzbl. A browser that adheres to the unix philosophy.

#102 2009-04-24 18:20:16

Re: uzbl. A browser that adheres to the unix philosophy.

#103 2009-04-24 18:40:28

Re: uzbl. A browser that adheres to the unix philosophy.

#104 2009-04-24 18:55:44

Re: uzbl. A browser that adheres to the unix philosophy.

#105 2009-04-24 19:03:58

Re: uzbl. A browser that adheres to the unix philosophy.

#106 2009-04-24 19:08:11

Re: uzbl. A browser that adheres to the unix philosophy.

#107 2009-04-24 19:40:07

Re: uzbl. A browser that adheres to the unix philosophy.

#108 2009-04-24 19:54:32

Re: uzbl. A browser that adheres to the unix philosophy.

#109 2009-04-24 20:09:48

Re: uzbl. A browser that adheres to the unix philosophy.

#110 2009-04-24 20:18:48

Re: uzbl. A browser that adheres to the unix philosophy.

#111 2009-04-24 21:16:12

Re: uzbl. A browser that adheres to the unix philosophy.

#112 2009-04-24 22:12:56

Re: uzbl. A browser that adheres to the unix philosophy.

#113 2009-04-24 22:39:29

Re: uzbl. A browser that adheres to the unix philosophy.

#114 2009-04-24 22:57:53

Re: uzbl. A browser that adheres to the unix philosophy.

#115 2009-04-25 03:34:09

Re: uzbl. A browser that adheres to the unix philosophy.

#116 2009-04-25 06:27:02

Re: uzbl. A browser that adheres to the unix philosophy.

#117 2009-04-25 06:38:23

Re: uzbl. A browser that adheres to the unix philosophy.

#118 2009-04-25 07:04:54

Re: uzbl. A browser that adheres to the unix philosophy.

#119 2009-04-25 07:09:11

Re: uzbl. A browser that adheres to the unix philosophy.

#120 2009-04-25 07:11:44

Re: uzbl. A browser that adheres to the unix philosophy.

#121 2009-04-25 07:13:07

Re: uzbl. A browser that adheres to the unix philosophy.

#122 2009-04-25 07:36:17

Re: uzbl. A browser that adheres to the unix philosophy.

#123 2009-04-25 07:51:28

Re: uzbl. A browser that adheres to the unix philosophy.

#124 2009-04-25 08:19:42

Re: uzbl. A browser that adheres to the unix philosophy.

#125 2009-04-25 08:28:56

Re: uzbl. A browser that adheres to the unix philosophy.

Board footer