On the rationale of using a custom parser instead of a lex/yacc one, see this
quote from src/commands_parser.c:
We use a hand-written parser instead of lex/yacc because our commands are
easy for humans, not for computers. Thus, it’s quite hard to specify a
context-free grammar for the commands. A PEG grammar would be easier, but
there’s downsides to every PEG parser generator I have come accross so far.
This parser is basically a state machine which looks for literals or strings
and can push either on a stack. After identifying a literal or string, it
will either transition to the current state, to a different state, or call a
function (like cmd_move()).
Special care has been taken that error messages are useful and the code is
well testable (when compiled with -DTEST_PARSER it will output to stdout
instead of actually calling any function).
During the migration phase (I plan to completely switch to this parser before
4.2 will be released), the new parser will parse every command you send to
i3 and save the resulting call stack. Then, the old parser will parse your
input and actually execute the commands. Afterwards, both call stacks will be
compared and any differences will be logged.
The new parser works with 100% of the test suite and produces identical call
stacks.
After a reload, the drawing parameters for the decorations might
have changed, so we need to invalidate the cache and force a redraw
of the currently visible decorations. Also, don't leak the previous
font when reloading by freeing it before parsing the config.
Abstracted draw_text and predict_text_width into libi3. Use
predict_text_width from libi3 in i3 too. This required tracking
xcb_connection in a xcb_connection_t *conn variable that libi3
expects to be available in i3bar.
Also prints out useful stuff:
CORE DUMPS: You are running a development version of i3, so coredumps were
automatically enabled (ulimit -c unlimited).
CORE DUMPS: Your current working directory is "/home/michael/i3".
CORE DUMPS: Your core_pattern is: /tmp/%e.core.%p
i3 (tree) version 4.0.2-479-g26ab2ac (2011-11-08, branch "next") starting
This does not affect child processes of i3.
The intention of this change is to make debugging easier – it’s one less thing
users of the development version have to worry about when trying to help with
debugging.
Also, the API changed a bit. There are two functions now, both assume you
already got the keysyms (which is the case for i3 and i3-config-wizard),
one gets the modifier mapping for you (aio_get_mod_mask_for) while the other
assumes you also got that. No roundtrips are required for the latter.
In order to not depend on X11 just for getting the socket paths, scripts or
other programs can now use i3 --get-socketpath. Since i3 must be present on the
computer anyways, this saves one dependency :).
This is mainly useful for the testsuite. The tests can wait until i3 processed
all X11 events and then continue. This eliminates sleep() calls which leads to
a more robust and faster testsuite.
The configuration option does the same as the commandline parameter, except
it can be easily set by the user (e.g. you are using KDM and can't start a
session through ~/.xsession).
Signed-off-by: Michael Walle <michael@walle.cc>
- Introduce warp_to static variable in x.c that stores the coordinates
to warp to as a Rect.
- Add x_set_warp_to function to set this variable. Use in _tree_next,
workspace_show, and con_move_to_workspace.
- In x_push_chanages, if warp_to is set, then call xcb_warp_pointer_rect
and then reset it to NULL.
This fixes all know bugs for pointer warping for me.
Modify _tree_next() so that when we reach the workspace container:
1. Find the next corresponding output (screen) using the added
get_output_next().
2. If there is another output, find the visible workspace.
3. Call workspace_show on found workspace.
4. Find the appropriate window to focus (leftmost/rightmost, etc.) using
con_descend_direction, and then focus it.
I've only tested on horizontal monitors (left/right).
Generally, the traversal goes: numbered workspaces in order, and then
named workspaces in the order in which they appear in the tree.
Example:
Output 1: Output 2:
1 3 D C 2 4 B A
Traversal: 1, 2, 3, 4, D, C, B, A, 1, ...
Note, after the numbered workspaces, we traverse the named workspaces
from output 1, and then output 2, etc.
