2010-08-07 18:05:16 +02:00
|
|
|
/*
|
2011-10-09 15:28:20 +02:00
|
|
|
* vim:ts=4:sw=4:expandtab
|
|
|
|
*
|
2010-08-07 18:05:16 +02:00
|
|
|
* i3bar - an xcb-based status- and ws-bar for i3
|
2015-04-04 02:17:56 +02:00
|
|
|
* © 2010 Axel Wagner and contributors (see also: LICENSE)
|
2010-08-07 18:05:16 +02:00
|
|
|
*
|
2011-10-25 22:19:38 +02:00
|
|
|
* ipc.c: Communicating with i3
|
2010-08-07 18:05:16 +02:00
|
|
|
*
|
|
|
|
*/
|
2016-10-11 09:13:35 +02:00
|
|
|
#include "common.h"
|
|
|
|
|
2010-07-23 04:43:43 +02:00
|
|
|
#include <stdlib.h>
|
2010-07-22 01:15:18 +02:00
|
|
|
#include <stdio.h>
|
2010-07-23 04:43:43 +02:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <stdint.h>
|
2011-08-01 16:17:59 +02:00
|
|
|
#include <string.h>
|
2011-01-01 16:48:30 +01:00
|
|
|
#include <errno.h>
|
2010-07-22 01:15:18 +02:00
|
|
|
#include <sys/socket.h>
|
|
|
|
#include <sys/un.h>
|
|
|
|
#include <i3/ipc.h>
|
2010-08-05 05:09:59 +02:00
|
|
|
#include <ev.h>
|
2016-01-09 17:18:05 +01:00
|
|
|
#ifdef I3_ASAN_ENABLED
|
|
|
|
#include <sanitizer/lsan_interface.h>
|
|
|
|
#endif
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2014-06-15 19:07:02 +02:00
|
|
|
ev_io *i3_connection;
|
2010-12-26 19:29:57 +01:00
|
|
|
|
|
|
|
const char *sock_path;
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2014-06-15 19:07:02 +02:00
|
|
|
typedef void (*handler_t)(char *);
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
|
|
|
* Called, when we get a reply to a command from i3.
|
|
|
|
* Since i3 does not give us much feedback on commands, we do not much
|
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_command_reply(char *reply) {
|
2015-03-23 20:56:49 +01:00
|
|
|
/* TODO: Error handling for command replies */
|
2010-07-22 01:15:18 +02:00
|
|
|
}
|
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
2015-03-23 20:56:49 +01:00
|
|
|
* Called, when we get a reply with workspaces data
|
2010-08-07 02:10:05 +02:00
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_workspace_reply(char *reply) {
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Got workspace data!\n");
|
2010-08-03 21:20:11 +02:00
|
|
|
parse_workspaces_json(reply);
|
2012-08-21 13:51:40 +02:00
|
|
|
draw_bars(false);
|
2010-07-22 01:15:18 +02:00
|
|
|
}
|
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
|
|
|
* Called, when we get a reply for a subscription.
|
|
|
|
* Since i3 does not give us much feedback on commands, we do not much
|
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_subscribe_reply(char *reply) {
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Got subscribe reply: %s\n", reply);
|
2015-03-23 20:56:49 +01:00
|
|
|
/* TODO: Error handling for subscribe commands */
|
2010-07-23 04:43:43 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
2015-03-23 20:56:49 +01:00
|
|
|
* Called, when we get a reply with outputs data
|
2010-08-07 02:10:05 +02:00
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_output_reply(char *reply) {
|
2017-03-12 21:17:12 +01:00
|
|
|
DLOG("Clearing old output configuration...\n");
|
2017-09-26 13:50:26 +02:00
|
|
|
free_outputs();
|
2017-03-12 21:17:12 +01:00
|
|
|
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Parsing outputs JSON...\n");
|
2010-08-03 21:20:11 +02:00
|
|
|
parse_outputs_json(reply);
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Reconfiguring windows...\n");
|
2013-05-29 18:02:46 +02:00
|
|
|
reconfig_windows(false);
|
2012-04-22 20:43:52 +02:00
|
|
|
|
2017-09-26 13:50:26 +02:00
|
|
|
i3_output *o_walk;
|
2020-02-19 11:31:09 +01:00
|
|
|
SLIST_FOREACH (o_walk, outputs, slist) {
|
2012-04-22 20:43:52 +02:00
|
|
|
kick_tray_clients(o_walk);
|
|
|
|
}
|
2012-04-24 12:04:07 +02:00
|
|
|
|
2017-05-02 09:11:35 +02:00
|
|
|
if (!config.disable_ws) {
|
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_WORKSPACES, NULL);
|
|
|
|
}
|
|
|
|
|
2012-08-21 13:51:40 +02:00
|
|
|
draw_bars(false);
|
2010-07-23 04:43:43 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2011-10-19 23:58:19 +02:00
|
|
|
/*
|
|
|
|
* Called when we get the configuration for our bar instance
|
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_bar_config(char *reply) {
|
2011-10-19 23:58:19 +02:00
|
|
|
DLOG("Received bar config \"%s\"\n", reply);
|
2015-03-23 20:56:49 +01:00
|
|
|
/* We initiate the main function by requesting infos about the outputs and
|
2011-10-19 23:58:19 +02:00
|
|
|
* workspaces. Everything else (creating the bars, showing the right workspace-
|
|
|
|
* buttons and more) is taken care of by the event-drivenness of the code */
|
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_OUTPUTS, NULL);
|
2013-01-02 23:09:52 +01:00
|
|
|
|
|
|
|
free_colors(&(config.colors));
|
2011-10-19 23:58:19 +02:00
|
|
|
parse_config_json(reply);
|
|
|
|
|
|
|
|
/* Now we can actually use 'config', so let's subscribe to the appropriate
|
|
|
|
* events and request the workspaces if necessary. */
|
|
|
|
subscribe_events();
|
|
|
|
if (!config.disable_ws)
|
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_WORKSPACES, NULL);
|
|
|
|
|
|
|
|
/* Initialize the rest of XCB */
|
|
|
|
init_xcb_late(config.fontname);
|
|
|
|
|
|
|
|
/* Resolve color strings to colorpixels and save them, then free the strings. */
|
|
|
|
init_colors(&(config.colors));
|
|
|
|
|
|
|
|
start_child(config.command);
|
|
|
|
}
|
|
|
|
|
2015-03-24 13:41:16 +01:00
|
|
|
/* Data structure to easily call the reply handlers later */
|
2010-07-23 04:43:43 +02:00
|
|
|
handler_t reply_handlers[] = {
|
2018-03-30 21:07:48 +02:00
|
|
|
&got_command_reply, /* I3_IPC_REPLY_TYPE_COMMAND */
|
|
|
|
&got_workspace_reply, /* I3_IPC_REPLY_TYPE_WORKSPACES */
|
|
|
|
&got_subscribe_reply, /* I3_IPC_REPLY_TYPE_SUBSCRIBE */
|
|
|
|
&got_output_reply, /* I3_IPC_REPLY_TYPE_OUTPUTS */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_TREE */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_MARKS */
|
|
|
|
&got_bar_config, /* I3_IPC_REPLY_TYPE_BAR_CONFIG */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_VERSION */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_BINDING_MODES */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_CONFIG */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_TICK */
|
|
|
|
NULL, /* I3_IPC_REPLY_TYPE_SYNC */
|
2010-07-23 04:43:43 +02:00
|
|
|
};
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
2015-03-23 20:56:49 +01:00
|
|
|
* Called, when a workspace event arrives (i.e. the user changed the workspace)
|
2010-08-07 02:10:05 +02:00
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_workspace_event(char *event) {
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Got workspace event!\n");
|
2010-08-03 21:20:11 +02:00
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_WORKSPACES, NULL);
|
2010-07-22 01:15:18 +02:00
|
|
|
}
|
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
2015-03-24 13:41:16 +01:00
|
|
|
* Called, when an output event arrives (i.e. the screen configuration changed)
|
2010-08-07 02:10:05 +02:00
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_output_event(char *event) {
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Got output event!\n");
|
2010-08-03 21:20:11 +02:00
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_OUTPUTS, NULL);
|
2011-04-21 20:24:02 +02:00
|
|
|
if (!config.disable_ws) {
|
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_WORKSPACES, NULL);
|
|
|
|
}
|
2010-07-23 04:43:43 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2012-11-10 13:41:39 +01:00
|
|
|
/*
|
2015-03-23 20:56:49 +01:00
|
|
|
* Called, when a mode event arrives (i3 changed binding mode).
|
2012-11-10 13:41:39 +01:00
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_mode_event(char *event) {
|
2015-03-24 13:41:16 +01:00
|
|
|
DLOG("Got mode event!\n");
|
2012-11-10 13:41:39 +01:00
|
|
|
parse_mode_json(event);
|
|
|
|
draw_bars(false);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Called, when a barconfig_update event arrives (i.e. i3 changed the bar hidden_state or mode)
|
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_bar_config_update(char *event) {
|
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
|
|
|
/* check whether this affect this bar instance by checking the bar_id */
|
|
|
|
char *expected_id;
|
|
|
|
sasprintf(&expected_id, "\"id\":\"%s\"", config.bar_id);
|
|
|
|
char *found_id = strstr(event, expected_id);
|
|
|
|
FREE(expected_id);
|
|
|
|
if (found_id == NULL)
|
2014-06-15 19:07:02 +02:00
|
|
|
return;
|
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
|
|
|
|
2015-02-10 20:26:22 +01:00
|
|
|
/* reconfigure the bar based on the current outputs */
|
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_OUTPUTS, NULL);
|
|
|
|
|
2014-05-03 01:56:12 +02:00
|
|
|
free_colors(&(config.colors));
|
|
|
|
|
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
|
|
|
/* update the configuration with the received settings */
|
|
|
|
DLOG("Received bar config update \"%s\"\n", event);
|
2017-09-26 01:50:10 +02:00
|
|
|
char *old_command = config.command ? sstrdup(config.command) : NULL;
|
2014-01-04 13:18:38 +01:00
|
|
|
bar_display_mode_t old_mode = config.hide_on_modifier;
|
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
|
|
|
parse_config_json(event);
|
|
|
|
if (old_mode != config.hide_on_modifier) {
|
2013-05-29 18:02:46 +02:00
|
|
|
reconfig_windows(true);
|
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
|
|
|
}
|
2012-11-10 13:41:39 +01:00
|
|
|
|
2015-02-10 20:26:22 +01:00
|
|
|
/* update fonts and colors */
|
|
|
|
init_xcb_late(config.fontname);
|
2014-05-03 01:56:12 +02:00
|
|
|
init_colors(&(config.colors));
|
|
|
|
|
2017-02-05 10:04:35 +01:00
|
|
|
/* restart status command process */
|
2017-09-26 01:50:10 +02:00
|
|
|
if (old_command && strcmp(old_command, config.command) != 0) {
|
2017-08-20 15:30:27 +02:00
|
|
|
kill_child();
|
|
|
|
start_child(config.command);
|
|
|
|
}
|
|
|
|
free(old_command);
|
2017-02-05 10:04:35 +01:00
|
|
|
|
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
|
|
|
draw_bars(false);
|
|
|
|
}
|
|
|
|
|
2015-03-24 13:41:16 +01:00
|
|
|
/* Data structure to easily call the event handlers later */
|
2010-07-23 04:43:43 +02:00
|
|
|
handler_t event_handlers[] = {
|
2010-08-03 21:20:11 +02:00
|
|
|
&got_workspace_event,
|
2012-11-10 13:41:39 +01:00
|
|
|
&got_output_event,
|
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
|
|
|
&got_mode_event,
|
|
|
|
NULL,
|
|
|
|
&got_bar_config_update,
|
2010-07-23 04:43:43 +02:00
|
|
|
};
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
|
|
|
* Called, when we get a message from i3
|
|
|
|
*
|
|
|
|
*/
|
2018-04-21 01:28:31 +02:00
|
|
|
static void got_data(struct ev_loop *loop, ev_io *watcher, int events) {
|
2010-09-17 06:49:28 +02:00
|
|
|
DLOG("Got data!\n");
|
2010-08-03 21:20:11 +02:00
|
|
|
int fd = watcher->fd;
|
2010-08-07 02:10:05 +02:00
|
|
|
|
2011-03-20 19:52:20 +01:00
|
|
|
/* First we only read the header, because we know its length */
|
2014-06-15 19:07:02 +02:00
|
|
|
uint32_t header_len = strlen(I3_IPC_MAGIC) + sizeof(uint32_t) * 2;
|
2011-10-21 20:30:46 +02:00
|
|
|
char *header = smalloc(header_len);
|
2010-08-03 21:20:11 +02:00
|
|
|
|
2015-03-24 13:41:16 +01:00
|
|
|
/* We first parse the fixed-length IPC header, to know, how much data
|
2010-09-17 05:26:31 +02:00
|
|
|
* we have to expect */
|
2010-08-03 21:20:11 +02:00
|
|
|
uint32_t rec = 0;
|
|
|
|
while (rec < header_len) {
|
|
|
|
int n = read(fd, header + rec, header_len - rec);
|
|
|
|
if (n == -1) {
|
2011-01-01 16:48:30 +01:00
|
|
|
ELOG("read() failed: %s\n", strerror(errno));
|
2010-08-03 21:20:11 +02:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (n == 0) {
|
2011-10-20 20:08:41 +02:00
|
|
|
/* EOF received. Since i3 will restart i3bar instances as appropriate,
|
|
|
|
* we exit here. */
|
|
|
|
DLOG("EOF received, exiting...\n");
|
2016-01-09 17:18:05 +01:00
|
|
|
#ifdef I3_ASAN_ENABLED
|
|
|
|
__lsan_do_leak_check();
|
|
|
|
#endif
|
2011-10-24 21:11:32 +02:00
|
|
|
clean_xcb();
|
2011-10-20 20:08:41 +02:00
|
|
|
exit(EXIT_SUCCESS);
|
2010-08-03 21:20:11 +02:00
|
|
|
}
|
|
|
|
rec += n;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (strncmp(header, I3_IPC_MAGIC, strlen(I3_IPC_MAGIC))) {
|
2010-09-17 06:49:28 +02:00
|
|
|
ELOG("Wrong magic code: %.*s\n Expected: %s\n",
|
2014-06-15 19:07:02 +02:00
|
|
|
(int)strlen(I3_IPC_MAGIC),
|
2010-09-17 06:49:28 +02:00
|
|
|
header,
|
|
|
|
I3_IPC_MAGIC);
|
2010-08-03 21:20:11 +02:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
char *walk = header + strlen(I3_IPC_MAGIC);
|
2011-05-03 12:38:57 +02:00
|
|
|
uint32_t size;
|
2014-06-15 19:07:02 +02:00
|
|
|
memcpy(&size, (uint32_t *)walk, sizeof(uint32_t));
|
2010-08-03 21:20:11 +02:00
|
|
|
walk += sizeof(uint32_t);
|
2011-05-03 12:38:57 +02:00
|
|
|
uint32_t type;
|
2014-06-15 19:07:02 +02:00
|
|
|
memcpy(&type, (uint32_t *)walk, sizeof(uint32_t));
|
2010-09-17 05:26:31 +02:00
|
|
|
|
|
|
|
/* Now that we know, what to expect, we can start read()ing the rest
|
|
|
|
* of the message */
|
2011-10-21 20:30:46 +02:00
|
|
|
char *buffer = smalloc(size + 1);
|
2010-08-03 21:20:11 +02:00
|
|
|
rec = 0;
|
|
|
|
|
|
|
|
while (rec < size) {
|
|
|
|
int n = read(fd, buffer + rec, size - rec);
|
|
|
|
if (n == -1) {
|
2011-01-01 16:48:30 +01:00
|
|
|
ELOG("read() failed: %s\n", strerror(errno));
|
2010-08-03 21:20:11 +02:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
if (n == 0) {
|
2010-09-17 06:49:28 +02:00
|
|
|
ELOG("Nothing to read!\n");
|
2010-08-03 21:20:11 +02:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
rec += n;
|
|
|
|
}
|
|
|
|
buffer[size] = '\0';
|
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/* And call the callback (indexed by the type) */
|
2018-10-13 20:04:40 +02:00
|
|
|
if (type & (1UL << 31)) {
|
|
|
|
type ^= 1UL << 31;
|
2010-08-03 21:20:11 +02:00
|
|
|
event_handlers[type](buffer);
|
|
|
|
} else {
|
2011-10-19 23:58:19 +02:00
|
|
|
if (reply_handlers[type])
|
|
|
|
reply_handlers[type](buffer);
|
2010-08-03 21:20:11 +02:00
|
|
|
}
|
|
|
|
|
2010-08-04 04:07:16 +02:00
|
|
|
FREE(header);
|
2010-08-03 21:20:11 +02:00
|
|
|
FREE(buffer);
|
2010-07-23 04:43:43 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
2015-03-24 13:41:16 +01:00
|
|
|
* Sends a message to i3.
|
2010-08-07 02:10:05 +02:00
|
|
|
* type must be a valid I3_IPC_MESSAGE_TYPE (see i3/ipc.h for further information)
|
|
|
|
*
|
|
|
|
*/
|
2010-08-03 21:20:11 +02:00
|
|
|
int i3_send_msg(uint32_t type, const char *payload) {
|
|
|
|
uint32_t len = 0;
|
|
|
|
if (payload != NULL) {
|
|
|
|
len = strlen(payload);
|
|
|
|
}
|
|
|
|
|
2010-09-17 05:26:31 +02:00
|
|
|
/* We are a wellbehaved client and send a proper header first */
|
2014-06-15 19:07:02 +02:00
|
|
|
uint32_t to_write = strlen(I3_IPC_MAGIC) + sizeof(uint32_t) * 2 + len;
|
2010-09-17 05:26:31 +02:00
|
|
|
/* TODO: I'm not entirely sure if this buffer really has to contain more
|
|
|
|
* than the pure header (why not just write() the payload from *payload?),
|
|
|
|
* but we leave it for now */
|
2011-10-21 20:30:46 +02:00
|
|
|
char *buffer = smalloc(to_write);
|
2010-08-03 21:20:11 +02:00
|
|
|
char *walk = buffer;
|
|
|
|
|
2018-05-08 16:05:46 +02:00
|
|
|
memcpy(buffer, I3_IPC_MAGIC, strlen(I3_IPC_MAGIC));
|
2010-08-03 21:20:11 +02:00
|
|
|
walk += strlen(I3_IPC_MAGIC);
|
|
|
|
memcpy(walk, &len, sizeof(uint32_t));
|
|
|
|
walk += sizeof(uint32_t);
|
|
|
|
memcpy(walk, &type, sizeof(uint32_t));
|
|
|
|
walk += sizeof(uint32_t);
|
|
|
|
|
2011-02-26 01:45:52 +01:00
|
|
|
if (payload != NULL)
|
|
|
|
strncpy(walk, payload, len);
|
2010-08-03 21:20:11 +02:00
|
|
|
|
2015-03-24 13:57:06 +01:00
|
|
|
swrite(i3_connection->fd, buffer, to_write);
|
2010-08-03 21:20:11 +02:00
|
|
|
|
|
|
|
FREE(buffer);
|
|
|
|
|
|
|
|
return 1;
|
2010-07-23 04:43:43 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
|
|
|
* Initiate a connection to i3.
|
2015-03-23 20:56:49 +01:00
|
|
|
* socket_path must be a valid path to the ipc_socket of i3
|
2010-08-07 02:10:05 +02:00
|
|
|
*
|
|
|
|
*/
|
2010-07-23 04:43:43 +02:00
|
|
|
int init_connection(const char *socket_path) {
|
2010-12-26 19:29:57 +01:00
|
|
|
sock_path = socket_path;
|
2011-10-23 18:18:14 +02:00
|
|
|
int sockfd = ipc_connect(socket_path);
|
2011-10-21 20:30:46 +02:00
|
|
|
i3_connection = smalloc(sizeof(ev_io));
|
2011-04-28 19:54:31 +02:00
|
|
|
ev_io_init(i3_connection, &got_data, sockfd, EV_READ);
|
|
|
|
ev_io_start(main_loop, i3_connection);
|
2010-08-03 21:20:11 +02:00
|
|
|
return 1;
|
2010-07-23 04:43:43 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
|
2010-12-26 19:29:57 +01:00
|
|
|
/*
|
|
|
|
* Destroy the connection to i3.
|
|
|
|
*/
|
2012-08-23 12:55:28 +02:00
|
|
|
void destroy_connection(void) {
|
2011-04-28 19:54:31 +02:00
|
|
|
close(i3_connection->fd);
|
|
|
|
ev_io_stop(main_loop, i3_connection);
|
2010-12-26 19:29:57 +01:00
|
|
|
}
|
|
|
|
|
2010-08-07 02:10:05 +02:00
|
|
|
/*
|
|
|
|
* Subscribe to all the i3-events, we need
|
|
|
|
*
|
|
|
|
*/
|
2012-08-23 12:55:28 +02:00
|
|
|
void subscribe_events(void) {
|
2011-04-21 20:24:02 +02:00
|
|
|
if (config.disable_ws) {
|
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
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_SUBSCRIBE, "[ \"output\", \"mode\", \"barconfig_update\" ]");
|
2011-04-21 20:24:02 +02:00
|
|
|
} else {
|
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
|
|
|
i3_send_msg(I3_IPC_MESSAGE_TYPE_SUBSCRIBE, "[ \"workspace\", \"output\", \"mode\", \"barconfig_update\" ]");
|
2011-04-21 20:24:02 +02:00
|
|
|
}
|
2010-07-22 01:15:18 +02:00
|
|
|
}
|