uzbl. A browser that adheres to the unix philosophy.

dusanx · 2009-04-25 08:29:50

Dieter@be wrote:

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)

If you use edit instead of dmenu you can't have bunch of useful history/bookmarked links easily accessible You can simulate this with combo box but that's too much different from the initial specification. You are drifting towards regular browser and that's what we wanted to avoid at the first place

Dieter@be · 2009-04-25 08:33:59

dusanx wrote:

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?

I think there are the following use cases:
1) "hey I get a 404/access denied, let's see if I can strip away the last '/foo' part and see what i get"
2) "hey I wonder what happens if I change this part of the url to something else" (eg 001.html to 002.html or docs/mysql4/grant to docs/mysql5/grant)
3) I want to go to page that's in my history
4) I want to go to a bookmark.

My initial goal was not to let uzbl spawn dmenu, though now you mention it this may be a good approach.
However, I do want an "interface" (socket/fifo/uzblctrl...) to uzbl, because then you change the behavior of it at runtime. configuring uzbl to spawn a script is less flexible, because after uzbl is running there's not much you can change.
So since I want this anyway, we might as well use it and let not uzbl spawn the dmenu script, but rather bind it with xbindkeys or similar.

Also, especially for case #2, I was thinking a built in vim-like editor would be more useful then the dmenu interface (where you can go back and forth only 1 character at a time). But hmm building in a vimlike url editor would not be very unix-philospy-like, you're right about that. If anything, we should keep the whole "url changing" out of uzbl and improve editing inside dmenu (to be more efficient) if necessary.

dusanx wrote:

If you use edit instead of dmenu you can't have bunch of useful history/bookmarked links easily accessible You can simulate this with combo box but that's too much different from the initial specification. You are drifting towards regular browser and that's what we wanted to avoid at the first place

It was not about "instead", it was about having a built in uri-changer (vim-style) + extra scripts to also change the url from outside (with dmenu and the likes). see above.

Barrucadu, what do you think about this?
I'm thinking it may be better to write a patch for dmenu to have more efficient editing (if needed), and keep all uri editing outside of uzbl.
Since with xbindkeys you need to use modifier keys, we should maybe configure the external scripts in the uzbl config file and trigger them with a simple key (eg 'h' to start which ever script is defined to load a page from history), that way you can still press simple keys (no shortcuts of more then 1 key) and we can move all uri editing logic out of uzbl (unix philosophy ftw!)

Last edited by Dieter@be (2009-04-25 08:41:51)

dusanx · 2009-04-25 08:39:32

Dieter@be wrote:

But hmm building in a vimlike url editor would not be very unix-philospy-like you're right about that. If anything, we should keep the whole "url changing" out of uzbl and improve editing inside dmenu if necessary.

Thanks, this is exactly what I wanted to point out It's so easy to get caught in 'lets add one more thing' loop.

Dieter@be · 2009-04-25 08:43:23

dusanx wrote:

Dieter@be wrote:
But hmm building in a vimlike url editor would not be very unix-philospy-like you're right about that. If anything, we should keep the whole "url changing" out of uzbl and improve editing inside dmenu if necessary.
Thanks, this is exactly what I wanted to point out It's so easy to get caught in 'lets add one more thing' loop.

You're right. please reread my post above yours. I updated some stuff, let me know what you think.

dusanx · 2009-04-25 08:54:13

Dieter@be wrote:

I'm thinking it may be better to write a patch for dmenu to have more efficient editing (if needed), and keep all uri editing outside of uzbl.
Since with xbindkeys you need to use modifier keys, we should maybe configure the external scripts in the uzbl config file and trigger them with a simple key (eg 'h' to start which ever script is defined to load a page from history), that way you can still press simple keys (no shortcuts of more then 1 key) and we can move all uri editing logic out of uzbl (unix philosophy ftw!)

Oh Yes!

Dmenu has fantastic search already, start this test line in any folder with files:
ls | dmenu ${1+"$@"} -p 'URL:'

Only thing that's missing is switch to set initial 'typed' text. If we can pull or add this we have covered 'want to slightly change current url' case.

Edit: partial search (not at the item beginning) works too

Last edited by dusanx (2009-04-25 08:55:52)

Barrucadu · 2009-04-25 08:55:51

Yes, I think that's the best approach - keeping things out of uzbl and using dmenu or something. I only really added the mode line into mine because I wanted somewhere to type commands without having to open a terminal (as I don't have it installed, dmenu didn't occur to me). I think a nice compromise would be internal keybindings (as defining a system-wide shortcut of 'b' would be a bit silly).

I'll have a think about how best to handle keybindings / renaming commands (not everyone will want the same commands as everyone else) and add something to the config file structure.

dusanx · 2009-04-25 09:04:24

Barrucadu wrote:

I think a nice compromise would be internal keybindings (as defining a system-wide shortcut of 'b' would be a bit silly).

I was just thinking the same.

I'll have a think about how best to handle keybindings / renaming commands (not everyone will want the same commands as everyone else) and add something to the config file structure.

I can do this if you all agree. I will take a day but I can prepare:

-Insert mode or not
-Key bindings for: back, forward, home (configurable of course, in both insert or non-insert mode)

This can be used as a stub for adding few more keys...

Barrucadu · 2009-04-25 09:10:23

dusanx wrote:

I can do this if you all agree. I will take a day but I can prepare:
-Insert mode or not
-Key bindings for: back, forward, home (configurable of course, in both insert or non-insert mode)
This can be used as a stub for adding few more keys...

Ok, I'll do command aliases then, so people don't have to recompile just because they don't like that my branch uses "z+" for zoom in. This is how I thought of defining commands in the config file:

[alias]
back     = b
forward  = f
zoom in  = z+
zoom out = z-
refesh   = r
stop     = s

The command names would therefore be the 'proper' names on the left of the = sign, and the command struct would include a list of aliases (char *aliases[256] ?), which would also be checked as well as the command name in the parse_command function. My branch also includes a way to repeat commands by sticking a number on the end of the command, which means I could/should add support for aliases like this:

back2 = B

Though I'm not sure how easy that is to do with the current method of parsing the config file (is there a way to get keys starting with a certain value?), so I may have to do this:

back = 2,B

Which means I'll need to add support for escaping commas…

edit: A bit of reading revealed I can use things like "back2 = B", so I'll use that method.

Last edited by Barrucadu (2009-04-25 09:18:41)

Dieter@be · 2009-04-25 09:18:18

Well, I just committed a sample config that demonstrates how i think it should work.
the mentioned scripts can be found in the "extra" dir in the experimental branch and are very basic shell scripts.

sample config wrote:

# example uzbl config. in a real config, we should obey the xdg spec
# if history_file is not set, then no history logging is performed.
# bindings_internal denote keys to trigger actions internally in uzbl
# bindings_external denote keys to trigger scripts outside uzbl
[behavior]
history_file = /tmp/uzbl.history
download_handler = ./extra/download.sh
[bindings_internal]
n = next
f = follow_link_here
F = follow_link_new_tab
w = follow_link_new_window
[bindings_external]
b = ./extra/insert_bookmark.sh
u = ./extra/load_url_from_history.sh
U = ./extra/load_url_from_bookmarks.sh

[network]

dusanx wrote:

Only thing that's missing is switch to set initial 'typed' text. If we can pull or add this we have covered 'want to slightly change current url' case.

indeed. I don't think it can be done by default with dmenu. You can however print the last uri from the history file (== current uri) and make it first option in dmenu, if you start dmenu it will hilight this item by default, then you can press tab to load it in the "search field", where you can edit it. Still one key press too many however seems like a simple patch in dmenu.

dusanx · 2009-04-25 09:19:08

Ok, I will check how dwm handles keys since there is already keybinding covered. I will not touch configuration but will use memory array at the beginning.

dusanx · 2009-04-25 09:21:19

Dieter@be wrote:

indeed. I don't think it can be done by default with dmenu. You can however print the last uri from the history file (== current uri) and make it first option in dmenu, if you start dmenu it will hilight this item by default, then you can press tab to load it in the "search field", where you can edit it. Still one key press too many however seems like a simple patch in dmenu.

This is great idea until we think of how to populate edit without using tab

droog · 2009-04-25 09:34:36

so i thought:
The "window manager" should handle everything but none do.
It must hard to build an ideal browser imagining these featureful WM's that don't exist.

give it tabs, give it vi keys or give it death.

Barrucadu · 2009-04-25 09:36:14

Tabs would make the control interface more difficult

dusanx · 2009-04-25 09:40:41

Dieter@be wrote:

[bindings_internal]
n = next
f = follow_link_here
F = follow_link_new_tab
w = follow_link_new_window
[bindings_external]
b = ./extra/insert_bookmark.sh
u = ./extra/load_url_from_history.sh
U = ./extra/load_url_from_bookmarks.sh

This is good but I want to make it more universal, something like
a)
follow_link_here = f

or

b)
follow_link_here = [Alt][Ctrl]f

so we can use any key combination.

Not sure about repeating but we can use something like this:
-when you type numbers _and_ then you type command, command is executed n times.
-when you type 'b' for back, app goes one step back.
-when you type '2' 0' 'b' app goes 20 steps back.

No need to define anything else than initial 'b' this way. Is this OK?

dusanx · 2009-04-25 09:42:19

We need no stinkin' tabs

droog · 2009-04-25 09:46:52

dusanx wrote:

We need no stinkin' tabs

hah i can compile the 50 example webkit gtk browsers that are everywhere and get this functionality.
but no one does, wonder why?

droog · 2009-04-25 09:53:08

If you want an unix browser use elinks imo, if you want to make something useful use tabs and vi keys but thats just my opinion.

Dieter@be · 2009-04-25 09:53:09

I conducted a little experiment..
assume that you visit 100 pages each day (probably an understatement), you log all of them, and they are each 80 characters long.
It would take 6250 days (17 years) to get to a 50MB history file.
If you want to know how well dmenu performs on such a file, read: http://dieter.plaetinck.be/poor_mans_dmenu_benchmark
Something to worry about 10 years from now

droog · 2009-04-25 09:59:47

dmenu is not a web browser tabbing throwoff.

Last edited by droog (2009-04-25 10:00:24)

Dieter@be · 2009-04-25 10:00:57

dusanx wrote:

Dieter@be wrote:
[bindings_internal]
n = next
f = follow_link_here
F = follow_link_new_tab
w = follow_link_new_window
[bindings_external]
b = ./extra/insert_bookmark.sh
u = ./extra/load_url_from_history.sh
U = ./extra/load_url_from_bookmarks.sh
This is good but I want to make it more universal, something like
a)
follow_link_here = f
or
b)
follow_link_here = [Alt][Ctrl]f
so we can use any key combination.
Not sure about repeating but we can use something like this:
-when you type numbers _and_ then you type command, command is executed n times.
-when you type 'b' for back, app goes one step back.
-when you type '2' 0' 'b' app goes 20 steps back.
No need to define anything else than initial 'b' this way. Is this OK?

The question is, do we need this?
I never go 20 steps back. Usually 1/2 or maximum 3. I don't mind pressing 'b' up to 3 times after each other.
I don't think we need quantity modifiers for anything.
Also I prefer vim-like keys. I hate pressing shortcuts of a modkey+some other key.
After all, we have 26 letters in the alphabet, so that means 26 possible commands (52 if you count uppercase versions). that should cover our bases I think.

dusanx · 2009-04-25 10:06:28

Dieter@be wrote:

dusanx wrote:
Dieter@be wrote:
[bindings_internal]
n = next
f = follow_link_here
F = follow_link_new_tab
w = follow_link_new_window
[bindings_external]
b = ./extra/insert_bookmark.sh
u = ./extra/load_url_from_history.sh
U = ./extra/load_url_from_bookmarks.sh
This is good but I want to make it more universal, something like
a)
follow_link_here = f
or
b)
follow_link_here = [Alt][Ctrl]f
so we can use any key combination.
Not sure about repeating but we can use something like this:
-when you type numbers _and_ then you type command, command is executed n times.
-when you type 'b' for back, app goes one step back.
-when you type '2' 0' 'b' app goes 20 steps back.
No need to define anything else than initial 'b' this way. Is this OK?
The question is, do we need this?
I never go 20 steps back. Usually 1/2 or maximum 3. I don't mind pressing 'b' up to 3 times after each other.
I don't think we need quantity modifiers for anything.
Also I prefer vim-like keys. I hate pressing shortcuts of a modkey+some other key.
After all, we have 26 letters in the alphabet, so that means 26 possible commands (52 if you count uppercase versions). that should cover our bases I think.

Barrucadu wants quantity modifiers, you both want insert mode, I want key modifiers and no insert mode... I think it's easy to cover all cases. We all want different and I think that's good for further app usability.

Dieter@be · 2009-04-25 10:19:58

dusanx wrote:

Dieter@be wrote:
The question is, do we need this?
I never go 20 steps back. Usually 1/2 or maximum 3. I don't mind pressing 'b' up to 3 times after each other.
I don't think we need quantity modifiers for anything.
Also I prefer vim-like keys. I hate pressing shortcuts of a modkey+some other key.
After all, we have 26 letters in the alphabet, so that means 26 possible commands (52 if you count uppercase versions). that should cover our bases I think.
Barrucadu wants quantity modifiers, you both want insert mode, I want key modifiers and no insert mode... I think it's easy to cover all cases. We all want different and I think that's good for further app usability.

I see. any specific reason you prefer non-vim style interface? I personally hate multi-key shortcuts.
Implementation wise , I think this can be done like this:
1) have vim-style action keys like in my sample config, with i/esc to go in/out insert mode.
2) make an option always_insert_mode which you can set to 1. this disables the going out of insert mode from the esc key.
3) allow user to define a modifier key so you perform the actions from #1 from inside insert mode by pressing modkey + key as defined in #1.
That way it's relatively easy I think to implement both interaction models, and in the config file format we can keep it a "1 item = 1 value" syntax.
About the quantity modifiers: I really don't see the use. Barrucadu do you really find this a must? Are there use cases for them inside a browser?

Last edited by Dieter@be (2009-04-25 10:20:35)

Barrucadu · 2009-04-25 10:33:27

It's not really a must, but I think it could be a nice feature.

On a different note, this code segfaults the instant at the "char* value =…" line. If anyone can figure out why that'd be very helpful.

  GError *error = 0;
  char   *keys  = g_key_file_get_keys (config, "alias", NULL, &error);
  
  if (error)
    { 
      printf("Error: %n\n", error);
    }
  else
    { 
      printf("Loading aliases\n");
      while (keys != NULL &&  (*keys) != NULL)
        { 
          char* value = g_key_file_get_value (config, (gchar *)"alias", (*keys), NULL);
          add_command_alias((*keys), value);
          ++keys;
        }
    }

Last edited by Barrucadu (2009-04-25 10:34:28)

dusanx · 2009-04-25 10:36:32

Dieter@be wrote:

I see. any specific reason you prefer non-vim style interface? I personally hate multi-key shortcuts.

I love vim keys but they are not ideal for me while browsing. I am often using kbd only but sometimes need to use mouse -> mouse in right hand, alt+a and alt+s (r untill I use colemak) under left hand.

Edit: Plus this is dwm-ish my lift hand is there anyway.

Implementation wise , I think this can be done like this:
1) have vim-style action keys like in my sample config, with i/esc to go in/out insert mode.
2) make an option always_insert_mode which you can set to 1. this disables the going out of insert mode from the esc key.
3) allow user to define a modifier key so you perform the actions from #1 from inside insert mode by pressing modkey + key as defined in #1.
That way it's relatively easy I think to implement both interaction models, and in the config file format we can keep it a "1 item = 1 value" syntax.
About the quantity modifiers: I really don't see the use. Barrucadu do you really find this a must? Are there use cases for them inside a browser?

Agreed with everything, this is way simpler than I had planned

I will have proper code no later than tomorrow morning.

Can we try to assemble list of all key functions? Here is mine:

-back
-forward
-home
...

I have not included follow in same or next buffer commands, they are optimistic at this moment

Last edited by dusanx (2009-04-25 10:40:08)

Dieter@be · 2009-04-25 10:40:31

Hey guys, do you use irc? I created a channel on freenode. #uzbl
I think communication will be much better if we can chat in real time.

Arch Linux

#126 2009-04-25 08:29:50

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

#127 2009-04-25 08:33:59

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

#128 2009-04-25 08:39:32

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

#129 2009-04-25 08:43:23

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

#130 2009-04-25 08:54:13

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

#131 2009-04-25 08:55:51

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

#132 2009-04-25 09:04:24

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

#133 2009-04-25 09:10:23

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

#134 2009-04-25 09:18:18

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

#135 2009-04-25 09:19:08

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

#136 2009-04-25 09:21:19

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

#137 2009-04-25 09:34:36

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

#138 2009-04-25 09:36:14

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

#139 2009-04-25 09:40:41

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

#140 2009-04-25 09:42:19

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

#141 2009-04-25 09:46:52

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

#142 2009-04-25 09:53:08

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

#143 2009-04-25 09:53:09

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

#144 2009-04-25 09:59:47

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

#145 2009-04-25 10:00:57

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

#146 2009-04-25 10:06:28

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

#147 2009-04-25 10:19:58

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

#148 2009-04-25 10:33:27

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

#149 2009-04-25 10:36:32

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

#150 2009-04-25 10:40:31

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

Board footer