nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
gri3-wm/parser-specs/commands.spec

425 lines
9.9 KiB
RPMSpec
Raw Normal View History

Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# vim:ts=2:sw=2:expandtab
#
# i3 - an improved dynamic tiling window manager
Update copyright notices and get rid of ranges The script used to make these changes can be found at: https://gist.github.com/Deiz/32322020f76d23e2bf8f
2015-04-04 02:17:56 +02:00
# © 2009 Michael Stapelberg and contributors (see also: LICENSE)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
#
# parser-specs/commands.spec: Specification file for generate-command-parser.pl
# which will generate the appropriate header files for our C parser.
#
# Use :source highlighting.vim in vim to get syntax highlighting
# for this file.
state INITIAL:
# We have an end token here for all the commands which just call some
# function without using an explicit 'end' token.
end ->
'[' -> call cmd_criteria_init(); CRITERIA
'move' -> MOVE
'exec' -> EXEC
'exit' -> call cmd_exit()
'restart' -> call cmd_restart()
'reload' -> call cmd_reload()
Implement shmlog command Add shmlog command that takes <size>|toggle|on|off. Separate logbuffer management into open_logbuffer() and close_logbuffer(). Make t/187-commands-parser.t expect 'shmlog'. Add update_shmlog_atom() to update the SHMLOG_PATH. Document the shmlog command in userguide.
2013-06-05 15:04:57 +02:00
'shmlog' -> SHMLOG
Implement debuglog command Add debuglog command that takes toggle|on|off. Add get_debug_logging() to be able to toggle. Make t/187-commands-parser.t expect 'debuglog'. Document the debuglog command in userguide.
2013-06-05 15:06:53 +02:00
'debuglog' -> DEBUGLOG
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
'border' -> BORDER
'layout' -> LAYOUT
'append_layout' -> APPEND_LAYOUT
'workspace' -> WORKSPACE
'focus' -> FOCUS
'kill' -> KILL
'open' -> call cmd_open()
'fullscreen' -> FULLSCREEN
Implement new 'sticky' command to manually set, remove or toggle the sticky state on a window.
2015-08-22 23:37:41 +02:00
'sticky' -> STICKY
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
'split' -> SPLIT
'floating' -> FLOATING
'mark' -> MARK
implement unmark command
2013-07-16 00:33:14 +02:00
'unmark' -> UNMARK
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
'resize' -> RESIZE
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
'rename' -> RENAME
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
'nop' -> NOP
'scratchpad' -> SCRATCHPAD
Added command directive 'title_format'. This directive will be used to customize the window title.
2015-06-10 18:59:45 +02:00
'title_format' -> TITLE_FORMAT
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
'mode' -> MODE
introduced i3 command for changing the hidden state and the mode of i3bar The hidden_state and mode of each i3bar instance can now be controlled from within i3. Therefore, two new i3 command were introduced: _ bar hidden_state show|hide|toggle [<bar_id>] show: always show the bar hide: normal hide mode toggle: toggle between show and hide (individually for each bar) _ bar mode dock|hide|invisible|toggle [<bar_id>] hide,dock: like before invisible: always keep the bar hidden toggle: toggle between dock and hide (individually for each bar) This patch introduces a hidden_state ("hidden_state hide|show") in the barconfig, which indicates the current hidden_state of each i3bar instance. It only affects the bar when in hide mode. Additionally, a new invisible mode was introduced. In order to change the hidden_state or mode of the bar from i3, a barconfig-update event was introduced, for which a bar can subscribe and the bar then gets notified about the currently set hidden_state and mode in its barconfig. For convenience, an id field ("id <bar_id>") was added to the barconfig, where one can set the desired id for the corresponding bar. If the id is not specified, i3 will deterministically choose an id; otherwise, with the previous random approach for finding a new id, which is actually not shared with i3bar, as it would determine its id on startup, the event-subscription would be destroyed on reload. Still, this issue remains when manually changing the bar_id in the config and then reloading. fixes #833, #651
2013-05-25 14:30:00 +02:00
'bar' -> BAR
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state CRITERIA:
Small cleanups: * Implement criterion specs just like it is done in the spec for the config * Declare variables in test case early so the 'my' keyword can be dropped in the actual test cases
2015-04-19 10:47:09 +02:00
ctype = 'class' -> CRITERION
ctype = 'instance' -> CRITERION
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
ctype = 'window_role' -> CRITERION
Small cleanups: * Implement criterion specs just like it is done in the spec for the config * Declare variables in test case early so the 'my' keyword can be dropped in the actual test cases
2015-04-19 10:47:09 +02:00
ctype = 'con_id' -> CRITERION
ctype = 'id' -> CRITERION
Implement new criterion 'window_type = normal|dialog|utility|toolbar|splash|menu|dropdown_menu|popup_menu|tooltip' fixes #1658
2015-04-18 21:09:03 +02:00
ctype = 'window_type' -> CRITERION
Small cleanups: * Implement criterion specs just like it is done in the spec for the config * Declare variables in test case early so the 'my' keyword can be dropped in the actual test cases
2015-04-19 10:47:09 +02:00
ctype = 'con_mark' -> CRITERION
ctype = 'title' -> CRITERION
ctype = 'urgent' -> CRITERION
Implement new criterion 'workspace'. If the match expression is a plain number (e.g., '99'), the number of a workspace will be compared strictly. Otherwise, the match expression is taken as a regular expression and compared against the workspace's name. This allows all of the following: for_window [workspace=5] ... for_window [workspace="5:foo"] ... for_window [workspace="foo"] ... fixes #1769
2015-06-29 23:58:48 +02:00
ctype = 'workspace' -> CRITERION
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
']' -> call cmd_criteria_match_windows(); INITIAL
state CRITERION:
'=' -> CRITERION_STR
state CRITERION_STR:
cvalue = word
-> call cmd_criteria_add($ctype, $cvalue); CRITERIA
# exec [--no-startup-id] <command>
state EXEC:
nosn = '--no-startup-id'
->
command = string
-> call cmd_exec($nosn, $command)
Implement shmlog command Add shmlog command that takes <size>|toggle|on|off. Separate logbuffer management into open_logbuffer() and close_logbuffer(). Make t/187-commands-parser.t expect 'shmlog'. Add update_shmlog_atom() to update the SHMLOG_PATH. Document the shmlog command in userguide.
2013-06-05 15:04:57 +02:00
# shmlog <size>|toggle|on|off
state SHMLOG:
# argument may be a number
argument = string
-> call cmd_shmlog($argument)
Implement debuglog command Add debuglog command that takes toggle|on|off. Add get_debug_logging() to be able to toggle. Make t/187-commands-parser.t expect 'debuglog'. Document the debuglog command in userguide.
2013-06-05 15:06:53 +02:00
# debuglog toggle|on|off
state DEBUGLOG:
argument = 'toggle', 'on', 'off'
-> call cmd_debuglog($argument)
Fix documentation for border styles.
2015-06-09 23:13:40 +02:00
# border normal|pixel [<n>]
# border none|1pixel|toggle
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state BORDER:
Implement variable border widths for pixel/normal fixes #325
2012-09-24 01:14:00 +02:00
border_style = 'normal', 'pixel'
-> BORDER_WIDTH
border_style = 'none', 'toggle'
-> call cmd_border($border_style, "0")
border_style = '1pixel'
-> call cmd_border($border_style, "1")
state BORDER_WIDTH:
end
-> call cmd_border($border_style, "2")
border_width = word
-> call cmd_border($border_style, $border_width)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
Introduce splith/splitv layouts, remove orientation With this commit, the "default" layout is replaced by the splith and splitv layouts. splith is equivalent to default with orientation horizontal and splitv is equivalent to default with orientation vertical. The "split h" and "split v" commands continue to work as before, they split the current container and you will end up in a split container with layout splith (after "split h") or splitv (after "split v"). To change a splith container into a splitv container, use either "layout splitv" or "layout toggle split". The latter command is used in the default config as mod+l (previously "layout default"). In case you have "layout default" in your config file, it is recommended to just replace it by "layout toggle split", which will work as "layout default" did before when pressing it once, but toggle between horizontal/vertical when pressing it repeatedly. The rationale behind this commit is that it’s cleaner to have all parameters that influence how windows are rendered in the layout itself rather than having a special parameter in combination with only one layout. This enables us to change existing split containers in all cases without breaking existing features (see ticket #464). Also, users should feel more confident about whether they are actually splitting or just changing an existing split container now. As a nice side-effect, this commit brings back the "layout toggle" feature we once had in i3 version 3 (see the userguide). AFAIK, it is safe to use in-place restart to upgrade into versions after this commit (switching to an older version will break your layout, though). Fixes #464
2012-08-04 03:04:00 +02:00
# layout default|stacked|stacking|tabbed|splitv|splith
# layout toggle [split|all]
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state LAYOUT:
Introduce splith/splitv layouts, remove orientation With this commit, the "default" layout is replaced by the splith and splitv layouts. splith is equivalent to default with orientation horizontal and splitv is equivalent to default with orientation vertical. The "split h" and "split v" commands continue to work as before, they split the current container and you will end up in a split container with layout splith (after "split h") or splitv (after "split v"). To change a splith container into a splitv container, use either "layout splitv" or "layout toggle split". The latter command is used in the default config as mod+l (previously "layout default"). In case you have "layout default" in your config file, it is recommended to just replace it by "layout toggle split", which will work as "layout default" did before when pressing it once, but toggle between horizontal/vertical when pressing it repeatedly. The rationale behind this commit is that it’s cleaner to have all parameters that influence how windows are rendered in the layout itself rather than having a special parameter in combination with only one layout. This enables us to change existing split containers in all cases without breaking existing features (see ticket #464). Also, users should feel more confident about whether they are actually splitting or just changing an existing split container now. As a nice side-effect, this commit brings back the "layout toggle" feature we once had in i3 version 3 (see the userguide). AFAIK, it is safe to use in-place restart to upgrade into versions after this commit (switching to an older version will break your layout, though). Fixes #464
2012-08-04 03:04:00 +02:00
layout_mode = 'default', 'stacked', 'stacking', 'tabbed', 'splitv', 'splith'
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
-> call cmd_layout($layout_mode)
Introduce splith/splitv layouts, remove orientation With this commit, the "default" layout is replaced by the splith and splitv layouts. splith is equivalent to default with orientation horizontal and splitv is equivalent to default with orientation vertical. The "split h" and "split v" commands continue to work as before, they split the current container and you will end up in a split container with layout splith (after "split h") or splitv (after "split v"). To change a splith container into a splitv container, use either "layout splitv" or "layout toggle split". The latter command is used in the default config as mod+l (previously "layout default"). In case you have "layout default" in your config file, it is recommended to just replace it by "layout toggle split", which will work as "layout default" did before when pressing it once, but toggle between horizontal/vertical when pressing it repeatedly. The rationale behind this commit is that it’s cleaner to have all parameters that influence how windows are rendered in the layout itself rather than having a special parameter in combination with only one layout. This enables us to change existing split containers in all cases without breaking existing features (see ticket #464). Also, users should feel more confident about whether they are actually splitting or just changing an existing split container now. As a nice side-effect, this commit brings back the "layout toggle" feature we once had in i3 version 3 (see the userguide). AFAIK, it is safe to use in-place restart to upgrade into versions after this commit (switching to an older version will break your layout, though). Fixes #464
2012-08-04 03:04:00 +02:00
'toggle'
-> LAYOUT_TOGGLE
# layout toggle [split|all]
state LAYOUT_TOGGLE:
end
-> call cmd_layout_toggle($toggle_mode)
toggle_mode = 'split', 'all'
-> call cmd_layout_toggle($toggle_mode)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# append_layout <path>
state APPEND_LAYOUT:
path = string -> call cmd_append_layout($path)
# workspace next|prev|next_on_output|prev_on_output
# workspace back_and_forth
# workspace <name>
Implement 'workspace number <number>' to switch to named workspaces
2012-04-08 19:17:46 +02:00
# workspace number <number>
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state WORKSPACE:
direction = 'next_on_output', 'prev_on_output', 'next', 'prev'
-> call cmd_workspace($direction)
'back_and_forth'
-> call cmd_workspace_back_and_forth()
Implement 'workspace number <number>' to switch to named workspaces
2012-04-08 19:17:46 +02:00
'number'
-> WORKSPACE_NUMBER
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
workspace = string
-> call cmd_workspace_name($workspace)
Implement 'workspace number <number>' to switch to named workspaces
2012-04-08 19:17:46 +02:00
state WORKSPACE_NUMBER:
workspace = string
-> call cmd_workspace_number($workspace)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# focus left|right|up|down
# focus output <output>
# focus tiling|floating|mode_toggle
# focus parent|child
# focus
state FOCUS:
direction = 'left', 'right', 'up', 'down'
-> call cmd_focus_direction($direction)
'output'
-> FOCUS_OUTPUT
window_mode = 'tiling', 'floating', 'mode_toggle'
-> call cmd_focus_window_mode($window_mode)
level = 'parent', 'child'
-> call cmd_focus_level($level)
end
-> call cmd_focus()
state FOCUS_OUTPUT:
output = string
-> call cmd_focus_output($output)
add comments to src/commands.c
2012-01-27 23:32:40 +01:00
# kill [window|client]
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state KILL:
kill_mode = 'window', 'client'
-> call cmd_kill($kill_mode)
end
-> call cmd_kill($kill_mode)
Extend the fullscreen command Rather than just toggling the fullscreen modes, allow to set them directly with: fullscreen enable|toggle [global] fullscreen disable For compatibility, retain the previous command and its toggling behavior: fullscreen [global] fixes #1120
2014-10-26 19:33:09 +01:00
# fullscreen enable|toggle [global]
# fullscreen disable
add comments to src/commands.c
2012-01-27 23:32:40 +01:00
# fullscreen [global]
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state FULLSCREEN:
Extend the fullscreen command Rather than just toggling the fullscreen modes, allow to set them directly with: fullscreen enable|toggle [global] fullscreen disable For compatibility, retain the previous command and its toggling behavior: fullscreen [global] fixes #1120
2014-10-26 19:33:09 +01:00
action = 'disable'
-> call cmd_fullscreen($action, "output")
action = 'enable', 'toggle'
-> FULLSCREEN_MODE
action = ''
-> FULLSCREEN_COMPAT
state FULLSCREEN_MODE:
mode = 'global'
-> call cmd_fullscreen($action, $mode)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
end
Extend the fullscreen command Rather than just toggling the fullscreen modes, allow to set them directly with: fullscreen enable|toggle [global] fullscreen disable For compatibility, retain the previous command and its toggling behavior: fullscreen [global] fixes #1120
2014-10-26 19:33:09 +01:00
-> call cmd_fullscreen($action, "output")
state FULLSCREEN_COMPAT:
mode = 'global'
-> call cmd_fullscreen("toggle", $mode)
end
-> call cmd_fullscreen("toggle", "output")
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
Implement new 'sticky' command to manually set, remove or toggle the sticky state on a window.
2015-08-22 23:37:41 +02:00
# sticky enable|disable|toggle
state STICKY:
action = 'enable', 'disable', 'toggle'
-> call cmd_sticky($action)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# split v|h|vertical|horizontal
state SPLIT:
parser: reorder v/h/vertical/horizontal This eliminates an error message upon split horizontal which did not occur in older i3 versions. The command itself worked just fine.
2012-06-10 17:56:28 +02:00
direction = 'horizontal', 'vertical', 'v', 'h'
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
-> call cmd_split($direction)
# floating enable|disable|toggle
state FLOATING:
floating = 'enable', 'disable', 'toggle'
-> call cmd_floating($floating)
Added a --toggle switch to "mark [--toggle] <mark>" This option allows toggling marks on a window without knowing whether the mark is already set or not. It behaves as follows: 1) If the matched window has no mark, the new mark is set. 2) If the matched window has another mark, the old mark is removed and the new mark is set. 3) If the matched window already has the mark, the mark is removed. The behavior that all non-matched windows have this mark removed is kept. fixes #1463
2015-03-28 19:12:25 +01:00
# mark [--toggle] <mark>
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state MARK:
Added a --toggle switch to "mark [--toggle] <mark>" This option allows toggling marks on a window without knowing whether the mark is already set or not. It behaves as follows: 1) If the matched window has no mark, the new mark is set. 2) If the matched window has another mark, the old mark is removed and the new mark is set. 3) If the matched window already has the mark, the mark is removed. The behavior that all non-matched windows have this mark removed is kept. fixes #1463
2015-03-28 19:12:25 +01:00
toggle = '--toggle'
->
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
mark = string
Added a --toggle switch to "mark [--toggle] <mark>" This option allows toggling marks on a window without knowing whether the mark is already set or not. It behaves as follows: 1) If the matched window has no mark, the new mark is set. 2) If the matched window has another mark, the old mark is removed and the new mark is set. 3) If the matched window already has the mark, the mark is removed. The behavior that all non-matched windows have this mark removed is kept. fixes #1463
2015-03-28 19:12:25 +01:00
-> call cmd_mark($mark, $toggle)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
implement unmark command
2013-07-16 00:33:14 +02:00
# unmark [mark]
state UNMARK:
end
-> call cmd_unmark($mark)
mark = string
-> call cmd_unmark($mark)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# resize
state RESIZE:
way = 'grow', 'shrink'
-> RESIZE_DIRECTION
Support "resize set W H"
2015-09-05 08:31:45 +02:00
set = 'set'
-> RESIZE_SET
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state RESIZE_DIRECTION:
Implement resize <grow|shrink> <width|height>, use it in the default config Fixes: #576
2012-04-08 15:59:49 +02:00
direction = 'up', 'down', 'left', 'right', 'width', 'height'
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
-> RESIZE_PX
state RESIZE_PX:
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
resize_px = number
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
-> RESIZE_TILING
end
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
-> call cmd_resize($way, $direction, 10, 10)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state RESIZE_TILING:
'px'
->
'or'
-> RESIZE_TILING_OR
end
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
-> call cmd_resize($way, $direction, &resize_px, 10)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state RESIZE_TILING_OR:
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
resize_ppt = number
Fix command parser: resizing tiling windows i3 would accept an invalid resize command like 'resize shrink width 10 px or' without specifying the ppt value, and then crash. This patch fixes the parser specification.
2013-10-09 22:30:41 +02:00
-> RESIZE_TILING_FINAL
state RESIZE_TILING_FINAL:
'ppt', end
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
-> call cmd_resize($way, $direction, &resize_px, &resize_ppt)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
Support "resize set W H"
2015-09-05 08:31:45 +02:00
state RESIZE_SET:
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
width = number
Support "resize set W H"
2015-09-05 08:31:45 +02:00
-> RESIZE_WIDTH
state RESIZE_WIDTH:
'px'
->
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
height = number
Support "resize set W H"
2015-09-05 08:31:45 +02:00
-> RESIZE_HEIGHT
state RESIZE_HEIGHT:
'px', end
Migrate the resize command to use typed numbers.
2015-09-27 16:32:54 +02:00
-> call cmd_resize_set(&width, &height)
Support "resize set W H"
2015-09-05 08:31:45 +02:00
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
# rename workspace <name> to <name>
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
# rename workspace to <name>
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
state RENAME:
'workspace'
-> RENAME_WORKSPACE
state RENAME_WORKSPACE:
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
old_name = 'to'
-> RENAME_WORKSPACE_LIKELY_TO
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
old_name = word
-> RENAME_WORKSPACE_TO
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
state RENAME_WORKSPACE_LIKELY_TO:
'to'
-> RENAME_WORKSPACE_NEW_NAME
new_name = word
-> call cmd_rename_workspace(NULL, $new_name)
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
state RENAME_WORKSPACE_TO:
'to'
introduce new command to rename focused workspace The corresponding command is 'rename workspace to <name>'. As a side-effect this fixes the command 'rename workspace 1 to to'. Signed-off-by: Michael Walle <michael@walle.cc>
2012-10-29 22:42:20 +01:00
-> RENAME_WORKSPACE_NEW_NAME
state RENAME_WORKSPACE_NEW_NAME:
end
-> call cmd_rename_workspace(NULL, "to")
Implement 'rename workspace <old_name> to <new_name>'
2012-04-08 20:34:31 +02:00
new_name = string
-> call cmd_rename_workspace($old_name, $new_name)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# move <direction> [<pixels> [px]]
Bugfix: Correctly parse `move ... workspace *_on_output` The parse spec for `move ... workspace ...` ordered next/prev before next_on_output/prev_on_output causing the parser to match next/prev before next_on_output/prev_on_output. Ticket: http://bugs.i3wm.org/report/ticket/941
2013-01-29 09:05:23 +01:00
# move [window|container] [to] workspace [<str>|next|prev|next_on_output|prev_on_output|current]
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# move [window|container] [to] output <str>
Added configuration directive for 'move [container|window] [to] mark <str>'
2015-04-12 17:30:31 +02:00
# move [window|container] [to] mark <str>
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# move [window|container] [to] scratchpad
# move workspace to [output] <str>
# move scratchpad
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
# move [window|container] [to] [absolute] position [ [<pixels> [px] <pixels> [px]] | center ]
Implemented new command 'move [window|container] [to] position mouse|cursor|pointer fixes #1696
2015-05-03 00:19:26 +02:00
# move [window|container] [to] position mouse|cursor|pointer
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state MOVE:
'window'
->
'container'
->
'to'
->
'workspace'
-> MOVE_WORKSPACE
'output'
-> MOVE_TO_OUTPUT
Added configuration directive for 'move [container|window] [to] mark <str>'
2015-04-12 17:30:31 +02:00
'mark'
-> MOVE_TO_MARK
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
'scratchpad'
-> call cmd_move_scratchpad()
direction = 'left', 'right', 'up', 'down'
-> MOVE_DIRECTION
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
method = 'position'
-> MOVE_TO_POSITION
method = 'absolute'
-> MOVE_TO_ABSOLUTE_POSITION
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state MOVE_DIRECTION:
pixels = word
-> MOVE_DIRECTION_PX
end
-> call cmd_move_direction($direction, "10")
state MOVE_DIRECTION_PX:
'px'
-> call cmd_move_direction($direction, $pixels)
end
-> call cmd_move_direction($direction, $pixels)
state MOVE_WORKSPACE:
Bugfix: Properly parse commands like “move workspace torrent” (Thanks rasi) fixes #955
2013-02-19 00:27:55 +01:00
'to '
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
-> MOVE_WORKSPACE_TO_OUTPUT
Bugfix: Correctly parse `move ... workspace *_on_output` The parse spec for `move ... workspace ...` ordered next/prev before next_on_output/prev_on_output causing the parser to match next/prev before next_on_output/prev_on_output. Ticket: http://bugs.i3wm.org/report/ticket/941
2013-01-29 09:05:23 +01:00
workspace = 'next_on_output', 'prev_on_output', 'next', 'prev', 'current'
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
-> call cmd_move_con_to_workspace($workspace)
fixes #776 this implements both the "move container to workspace back_and_forth" command and movements to the same workspace when auto_back_and_forth is set. it includes documentation and test suite additions by michael. it also simplifies the workspace_show_by_name function (making use of workspace_get accepting NULL pointers).
2012-09-04 10:51:18 +02:00
'back_and_forth'
-> call cmd_move_con_to_workspace_back_and_forth()
Implement 'move [container|window] to workspace number <number>'
2012-04-08 20:33:46 +02:00
'number'
-> MOVE_WORKSPACE_NUMBER
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
workspace = string
-> call cmd_move_con_to_workspace_name($workspace)
Implement 'move [container|window] to workspace number <number>'
2012-04-08 20:33:46 +02:00
state MOVE_WORKSPACE_NUMBER:
number = string
-> call cmd_move_con_to_workspace_number($number)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state MOVE_TO_OUTPUT:
output = string
-> call cmd_move_con_to_output($output)
Added configuration directive for 'move [container|window] [to] mark <str>'
2015-04-12 17:30:31 +02:00
state MOVE_TO_MARK:
mark = string
-> call cmd_move_con_to_mark($mark)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state MOVE_WORKSPACE_TO_OUTPUT:
'output'
->
output = string
-> call cmd_move_workspace_to_output($output)
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
state MOVE_TO_ABSOLUTE_POSITION:
'position'
-> MOVE_TO_POSITION
state MOVE_TO_POSITION:
'center'
-> call cmd_move_window_to_center($method)
Implemented new command 'move [window|container] [to] position mouse|cursor|pointer fixes #1696
2015-05-03 00:19:26 +02:00
'mouse', 'cursor', 'pointer'
-> call cmd_move_window_to_mouse()
Extends move command for floating windows
2012-03-23 13:39:17 +01:00
coord_x = word
-> MOVE_TO_POSITION_X
state MOVE_TO_POSITION_X:
'px'
->
coord_y = word
-> MOVE_TO_POSITION_Y
state MOVE_TO_POSITION_Y:
'px', end
-> call cmd_move_window_to_position($method, $coord_x, $coord_y)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
# mode <string>
state MODE:
mode = string
-> call cmd_mode($mode)
state NOP:
comment = string
-> call cmd_nop($comment)
Allow nop command without argument fixes #1318
2015-03-25 17:50:06 +01:00
end
-> call cmd_nop(NULL)
Implement a new parser for commands. (+test) 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.
2012-01-14 20:53:29 +01:00
state SCRATCHPAD:
'show'
-> call cmd_scratchpad_show()
introduced i3 command for changing the hidden state and the mode of i3bar The hidden_state and mode of each i3bar instance can now be controlled from within i3. Therefore, two new i3 command were introduced: _ bar hidden_state show|hide|toggle [<bar_id>] show: always show the bar hide: normal hide mode toggle: toggle between show and hide (individually for each bar) _ bar mode dock|hide|invisible|toggle [<bar_id>] hide,dock: like before invisible: always keep the bar hidden toggle: toggle between dock and hide (individually for each bar) This patch introduces a hidden_state ("hidden_state hide|show") in the barconfig, which indicates the current hidden_state of each i3bar instance. It only affects the bar when in hide mode. Additionally, a new invisible mode was introduced. In order to change the hidden_state or mode of the bar from i3, a barconfig-update event was introduced, for which a bar can subscribe and the bar then gets notified about the currently set hidden_state and mode in its barconfig. For convenience, an id field ("id <bar_id>") was added to the barconfig, where one can set the desired id for the corresponding bar. If the id is not specified, i3 will deterministically choose an id; otherwise, with the previous random approach for finding a new id, which is actually not shared with i3bar, as it would determine its id on startup, the event-subscription would be destroyed on reload. Still, this issue remains when manually changing the bar_id in the config and then reloading. fixes #833, #651
2013-05-25 14:30:00 +02:00
Added command directive 'title_format'. This directive will be used to customize the window title.
2015-06-10 18:59:45 +02:00
state TITLE_FORMAT:
format = string
-> call cmd_title_format($format)
introduced i3 command for changing the hidden state and the mode of i3bar The hidden_state and mode of each i3bar instance can now be controlled from within i3. Therefore, two new i3 command were introduced: _ bar hidden_state show|hide|toggle [<bar_id>] show: always show the bar hide: normal hide mode toggle: toggle between show and hide (individually for each bar) _ bar mode dock|hide|invisible|toggle [<bar_id>] hide,dock: like before invisible: always keep the bar hidden toggle: toggle between dock and hide (individually for each bar) This patch introduces a hidden_state ("hidden_state hide|show") in the barconfig, which indicates the current hidden_state of each i3bar instance. It only affects the bar when in hide mode. Additionally, a new invisible mode was introduced. In order to change the hidden_state or mode of the bar from i3, a barconfig-update event was introduced, for which a bar can subscribe and the bar then gets notified about the currently set hidden_state and mode in its barconfig. For convenience, an id field ("id <bar_id>") was added to the barconfig, where one can set the desired id for the corresponding bar. If the id is not specified, i3 will deterministically choose an id; otherwise, with the previous random approach for finding a new id, which is actually not shared with i3bar, as it would determine its id on startup, the event-subscription would be destroyed on reload. Still, this issue remains when manually changing the bar_id in the config and then reloading. fixes #833, #651
2013-05-25 14:30:00 +02:00
# bar (hidden_state hide|show|toggle)|(mode dock|hide|invisible|toggle) [<bar_id>]
state BAR:
bar_type = 'hidden_state'
-> BAR_HIDDEN_STATE
bar_type = 'mode'
-> BAR_MODE
state BAR_HIDDEN_STATE:
bar_value = 'hide', 'show', 'toggle'
-> BAR_W_ID
state BAR_MODE:
bar_value = 'dock', 'hide', 'invisible', 'toggle'
-> BAR_W_ID
state BAR_W_ID:
bar_id = word
->
end
-> call cmd_bar($bar_type, $bar_value, $bar_id)