aboutsummaryrefslogtreecommitdiffhomepage
path: root/docs/TODO
blob: f626fcd1ae60cea49185005f3e9789cb404527e6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
what if fifo/socket doesn't exist, or exists but nothing working behind it (anymore)?
-> useful for both cookie handler and event manager
-> implementing in uzbl-core needs refactoring of handler args, or some edge-case workarounds 
   (mason-l's proposal was not too bad: basically make cookie stuff more cookie specific.
   we don't need a generic talk_to_socket. 3 vars: cookie_handler, cookie_handler_socket and 
   cookie_handler_launcher. act depending on which vars are set)
-> for now, assume that we don't need to check for crashes, just make sure there is the initial socket/fifo -> can be done in uzbl-browser script


== event-messages specific ==
* throw out all old code
* document the event handling mechanism, all events, how to get started with sample event handler
* add key_release callback and event
* remove all binding ('bind = ' etc.) stuff and port to new system
* VARIABLE_SET for all types (but probably not useful for custom vars)
* port keycmd to evt handler.  we can now more cleanly send BackSpace instead of keycmd_bs and so on
* port the concept of modes and all related variables
* uzbl -> uzbl-core, uzbl-browser script like 'uzbl | $XDG.../event_manager.py'
* event manager dynamic config system that configures itself based on events from uzbl (eg to set vars in "uzbl slaves" such as this, set custom vars in uzbl which we react to)
* remove chain command
* scalability -> 1 event manager per n uzbl-browser instances -> mkfifo and redirect uzbl-core stdout to fifo in uzbl-browser
* event manager -> everything based on per instance basis (associative array with uzbl instance name as key)
* why the need of queues in mason-l branch?


= keybinding features =
* use a datadriven config format to allow simple implementations in different languages.
* allow binding all 'normal' keys ('a', 'Z', '_', '1', '@', '{', ...)
* allow binding all 'special' keys and modkeys ('Space', 'BackSpace', 'Alt_L', 'Escape')
* we could receive anything from /usr/include/X11/keysymdef.h (minus the 'XK_')
* support keypresses and keyreleases
* maybe: finegrained definitions of when releases can happen during a bigger command.  this may be an overcomplication (YAGNI?)
* maybe: after triggering, support resetting keycmd not to '', but something else. eg after 'gbbs' has triggered, set keycmd to 'bbs search' or something
  thoughts: do we send fake key events to uzbl (xdotool?) or more a way to set the keycmd inside the event handler?
            maybe not use a command but a static definition in the bind configs
            it may be cumbersome to support special chars here, so lets not overcomplicate this
* since we use key_press and release events, we don't need to support modmasks, we can "know" the state of any key, even non-modifier keys can be used as "fake" modkeys!
* port old behaviors:
  * `<string>` ends with underscore: the command will only be invoked after pressing return/enter, `%s` in the `<command>` string will be replaced by this text. (optional) (old `bind o _ = uri %s`)
    -> we can now use Literal 'Enter' keysym. we could have the convention that any bind who ends with 'Enter' which gets extra text, will do the replacement thing.
  * `<string>` ends with an asterisk: similar behavior as with an underscore, but also makes the binding incremental (i.e. the command will be invoked on every keystroke). (old `bind /*  = search %s` )
    -> we'll come up with a special marker. [!Enter] or whatever.
  * `<string>` ends on a different character: you need to type the full string, which will trigger the command immediately, without pressing enter/return. (old  `bind ZZ  = exit`)
    -> this should be the default.

== proposed workflow ==
in event_handler.py:
 * incoming key.length > 1 (this should separate all special cases like F11, Alt_L etc from normal chars) -> put '[' and ']' around it
   this allows to separate [F11] from a sequence of literal 'F', '1' '1'.
 * to bind literal [, it should be escapable with '\' (which itself is also escapable. eg '\\' for literal '\')
 * In most implementations, you'll want to:
   if [BackSpace] && keycmd == '' -> go back or whatever. otherwise remove last char from keycmd
 * this gives us the ' ' character for free. what to do with it?
   ideas:
   * use it as token for key_release event: 'z ' would mean: bind something on release of 'z', but we could also use a special marker like [release:<char>] for this (where <char> itself can also contain [] )
   * use it a separator for "combo's" (like xbindkeys does)

= proposed implementations =
option1: always assume combo's (simultaneous keypresses)
' ' -> combo separator
'a  ' -> bind something to key_release of 'a'

abc -> press a b c at same time
a b c -> press string 'abc'

option2: combo's are explicit (dieters preference):
'+' -> define combo (make + escapable)
'a ' -> key_release a

'a+b+c' -> press a b c at same time.
'abc' -> string 'abc'
'a+b+cfoo' -> a b c at same time, then 'foo'
'a+(bc)' -> 'bc' with 'a' as fake modkey (make '()' escapable)
'a+b a+c' -> same (though you could temporarily release a between pressing 'b' and 'c' if you want)
'[Space]+foo' -> press space while typing 'f', then type 'oo' (make '[]' escapable)
'[Alt_L]+[Backspace]' -> press alt while hitting backspace
'[Alt_L][Backspace]' -> hit alt, then backspace
'[Alt_L][Backspace] ' -> hit alt, then backspace then release backspace
'z' and 'z ' -> bind things on press and release of 'z'

= key handling (example event_handler.py) examples to implement =
* on escape:
if insert mode: set_insert_mode(uzbl.behave.always_insert_mode); update_title
else: clear_keycmd(); update_title; dehilight(uzbl.gui.web_view, NULL, NULL);
* demonstrate separate key_press and key_release (eg press 'z' to zoom in, on release reset zoom to what it was before. use "locking boolean" as discussed on irc)
* port the Modkey concept
* BackSpace -> keycmd_bs

* Insert: insert from clipboard -> keycmd + update_title
* shift+Insert: insert from primary -> keycmd + update_title
* handle Return and/or KP_Enter



More or less in order of importance/urgency

* improve cookie handler.
* a variable that holds the page state: loading, pending, seen. this can be shown in titlebar/statusbar and used for multiple instances management
* allow to tag , to group instances together
* store uri/tag/name/state in xorg window properties
* split up uzbl.c into multiple files
* shortcuts to focus other instances (see docs/multiple-instances-management)

* recognize -h with GOption?
* implement getting feedback from socket
* scrolling: make page up and page down configurable.
* show % of location in statusbar/title if page doesn't fit entirely on view.
* conditionals in format strings: eg if(SELECTED_URI) { "-> SELECTED_URI" } or another smart way to achieve the same.
* make default window size configurable, and optional if this is not too much work
* on uzbl.org commits overview: add date+time and repository
* how to handle different content types? (text-plain, image/png, application/pdf,... maybe a map of content-type to uzbl/command
  xdg already has a spec for this i think
  different "opening" modes (open as configured vs ask before opening)
  integration with download and new window thingies?
* blinking cursor when not in insert mode is confusing.  i suggest dimming it's color if possible
* open in new window -> uzbl: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
* check that in new version pageup etc works also in command
* tab key to jump between input fields should probably work in both insert and command mode
* do not delete fifo/socket if they exist already. rather give error and don't create one.
* optional logging of http requests&responses with ip/hostname and port. -> how to implement? handler? stdout? (through a socket so you know what corresponds to what?)
* bench/optimize fifo vs socket performance. measure delays.  minimize forks. does glib use a shell? how does it detect the shebang line?
* "remember account settings" support. but how? configure post data per site? regex match eg '^bbs.archlinux.org' ?
* http_proxy env var not recognized. libproxy (used by libsoup) should handle this http://mail.gnome.org/archives/libsoup-list/2009-February/msg00018.html
* support ssl. do ssl certificate & exception management similar to how we do cookies
* improve DCOMMIT macro.  what if WC is dirty? what if user downloaded tarball without .git?
* DARCH is not correct (should be at runtime)
* keybinds to open "next" or "previous" by looking for next/prev links and/or looking for numbers in the uri we can inc/decrement
* settings iterating "state generator" so we can "open in new window" again.
* handler for (broken) ssl certs.
* handlers for mailto: and maybe other thingies?
* make sample scripts less depending on bash, but more posix sh.
* proxy_url is not a good var name. it's not a url.
* regex style page searching? so you can do 'or' and 'and' things. flags like case sensitive etc.
* check for real command name, not just the first letter.
* Allow the spacebar to be binded to a command
* let users attach handlers to the most common events/signals in uzbl.
  great use case: automatically calling formfiller for certain sites, doing stuff at uzbl startup, etc
* document:
  stylesheet overridding
  formfiller
  full duplex socket
  ^X and such binds
  link following
  scrolling in %
  webkit inspector usage
  scroll commands can take %s, eg scroll 100% for pages
  chaining of actions, print (and other actions that aren't documented yet)
  overriding variables (such as -u)
  variable expansion (@var, @{var}, where do they get expanded? can users have their own vars?, should we merge this with the replacement we do for useragent/window title etc?)
  how %s works for the js command


SOMEDAY:
figure out caching with webkit and in general how we can speed up everything
figure out how webkit intercepts key input
make "disable insert mode" (esc key) configurable
keywords don't work for external commands. is this a problem?
* pass a bit less arguments by default, use the socket to query for them instead, or export the stuff through environment variables, or export them as xorg window properties