If the target is in a different workspace, there's no reason why
we wouldn't allow the user to focus it. We already allow this when
focusing a workspace, for example.
calling workspace by number now also checks for switching back and forth
and creates a new workspace if no workspace starting with that number is
found
also removed the obsolete tree_render() in favor of setting
cmd_output->needs_tree_render to true
When calculating coordinates we should multiply at first otherwise
we lose precision when i3 is compiled without sse2 support.
The following code prints "Res1: 348 Res2: 349" when compiled with
-O0 -mno-sse2 and "Res1: 349 Res2: 349" with -O0 -msee2.
Note that -msse2 is default flag on 64bit OSes.
int main() {
double a = 349.0 / 768;
double b = 349.0 * 768;
int res1 = a * 768;
int res2 = b / 768;
printf("Res1: %d Res2: %d\n", res1, res2);
return 0;
}
Thanks guys for helping me to hunt down this one.
See also:
http://article.gmane.org/gmane.linux.kernel/1268792
The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.
This fixes focus problems with Eclipse. Apparently, Eclipse waits for getting
notified about the focus, and since it used non-managed windows, i3 didn’t care
to update the focus.
Fixes: #621, #675
Fixes: #668
Calling tree_close with dont_kill_parent=true will avoid it from closing the
workspace if it’s empty (and it’s temporarily empty, because 'floating disable'
detaches, then re-attaches the window).
Initially I thought using the second precision time() function is good enough,
but to make t/113-urgent.t considerably faster (>2s vs. 0.08s), we put in a
little more effort and use gettimeofday. Otherwise, this test blocks the whole
testsuite from completing much faster on modern machines :).
This change has two implications:
1) tree_render() will now be called precisely once for input which consists of
multiple commands (like "focus left; focus right"). Also, the caller of
parse_command() has to call it. This makes us able to fix tickets such as
ticket #608 (where multiple tree_render() calls are noticable).
2) The output of a command is now a JSON array of return values of the
individual subcommands. In the case of "focus left; focus right", this is:
[{"success":true}, {"success":true}]
While this is incompatible with what i3 returned before, the return value of
commands was undocumented and therefore not subject to our API stability.
You need to specify the --enable-32bit-visual flag when starting i3. This is
done because everything feels sluggish on my system when using a 32 bit visual
instead of a 24 bit visual. Fast > fancy.
Fixes floating containers seemingly showing up in the wrong
workspace after moving workspaces containing floating containers.
We must *always* fix the coordinates of floating containers when
moving workspaces across outputs. That's because the coordinates
of floating containers are *not* relative to the workspaces.
Currently it supports the following options:
"oldest": match the first window that triggered an urgent event
"latest": match the last window that triggered an urgent event
If you had workspace 1, 2, 3, 4 on LVDS1 and you enabled HDMI2 (where workspace
1 to workspace 5 are assigned to HDMI2), i3 would look for a new workspace for
LVDS1 (since all workspaces were moved), create workspace 5, move that over due
to assignment and then create workspace 6. Effectively, you would end up with
an empty workspace 5.
Fixes a bug where splitting then moving in the other orientation
(e.g. v-splitting and moving right) would result in the old
indicators not disappearing.
This re-introduces borders around the workspace buttons in i3bar.
No additional pixels will be consumed (you will not lose any space for your
windows).
This fixes problems with the Oracle JRE7, which checks the current focus after
receiving WM_TAKE_FOCUS and just does nothing when the focus is on one of its
windows. Hopefully it doesn’t introduce any regressions :).
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.
