cleanup of (old/outdated) docs

3 files changed, 7 insertions, 73 deletions

diff --git a/docs/config-syntax b/docs/config-syntax
index 30cf91f..9894401 100644
--- a/docs/config-syntax
+++ b/docs/config-syntax
@@ -1,42 +1,5 @@
-Configuration setting at startup and changing at runtime happens through one of these:
-- stdin at startup (TODO: see if we can keep listening while running) (write command to it + "\n")
-- fifo (write command to it + "\n")
-- socket (uzblctrl -s <file> -c <comand>
-
-Lines written to the above starting with '#' or being empty, are ignored.
-
-** Command syntax:
-commands can have no, one or 2 arguments.
-
-<command>[\t<arg1>[\t<arg2>]]
-
-The 'bind' command is a special command, where argument 1 is a keyboard character (combo) and argument 2 is a command as specified above.
-You can also use a '_' in the <chars> part to denote where you pass on whatever you want, which will be replaced into the specififed command whereever %s is mentioned
-
-** commands
-Commands where one of the arguments is "parameter" expect this arugment to be a valid variable identifier (eg uzbl.behave.status_format) 
-
-set              parameter value # make sure the value complies with the datatype.
-toggle           parameter    # expects parameter to be a gboolean. (eg status, insert_mode, ..)
-get              parameter
-bind             <chars> <command>
-script           <JS code to execute>
-script_file      <filename containing JS code to execute>
-back
-forward
-scroll_vert      <int>
-scroll_horz      <int>
-reload
-reload_ign_cache
-stop
-zoom_in
-zoom_out
-spawn            <filename for process to start asynchronously>
-exit
-search           <string>
-
-The 'set' command may do more then just set the variable. eg 'set uri' commands will also cause uzbl to navigate to the uri.
-
+here: design notes
+readme: end-user instructions
 
 
 Rationale. AKA "why not config files?"
@@ -53,4 +16,6 @@ issues
    - iterate over state structs and generate appropriate commands to bring an instance in this state.
      - plaintext :)
      - user editable
-     - also useful for saving state if we need to update/shutdown/..
\ No newline at end of file
+     - also useful for saving state if we need to update/shutdown/..
+   -> all of this is overkill. for now we just decided to live with the fact we pass on '--config' flags,
+      it's up to the user to tweak his setup so it works.
diff --git a/docs/url-editing b/docs/url-editing
index 1059fc5..d8943fb 100644
--- a/docs/url-editing
+++ b/docs/url-editing
@@ -5,3 +5,5 @@ Use cases:
 * edit current url or one from history/bookmarks: dmenu-vertical is relatively good for this, though it would be better if we had:
 - minimal editing helper key shortcuts (eg to go to beginning/end of input buffer, erase search string, undo)
 - copy/paste support
+
+* Though you can obviously type new urls and edit the current ones with the appropriate statusbar stuff/binds/xclip commands, this is sometimes enough.
\ No newline at end of file
diff --git a/docs/widgets b/docs/widgets
deleted file mode 100644
index dc7127a..0000000
--- a/docs/widgets
+++ /dev/null
@@ -1,33 +0,0 @@
-
-* 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.
-* 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.
-* 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.
-* tabs -> yes. you don't have to use them, but you can.
-* back/forward/.. buttons? -> no: use keyboard shortcuts.
-* 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.
-* 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?
-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.