gri3-wm/i3bar/src/ipc.c

362 lines
9.9 KiB
C
Raw Normal View History

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
* © 2010 Axel Wagner and contributors (see also: LICENSE)
2010-08-07 18:05:16 +02:00
*
* ipc.c: Communicating with i3
2010-08-07 18:05:16 +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>
#include <string.h>
#include <errno.h>
2010-07-22 01:15:18 +02:00
#include <sys/socket.h>
#include <sys/un.h>
#include <i3/ipc.h>
#include <ev.h>
#ifdef I3_ASAN_ENABLED
#include <sanitizer/lsan_interface.h>
#endif
2010-07-22 01:15:18 +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
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
*
*/
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
*
*/
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);
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
*
*/
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
*
*/
static void got_output_reply(char *reply) {
DLOG("Clearing old output configuration...\n");
2017-09-26 13:50:26 +02:00
free_outputs();
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");
reconfig_windows(false);
2017-09-26 13:50:26 +02:00
i3_output *o_walk;
SLIST_FOREACH (o_walk, outputs, slist) {
kick_tray_clients(o_walk);
}
if (!config.disable_ws) {
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_WORKSPACES, NULL);
}
draw_bars(false);
2010-07-23 04:43:43 +02:00
}
2010-07-22 01:15:18 +02:00
/*
* Called when we get the configuration for our bar instance
*
*/
static void got_bar_config(char *reply) {
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
* 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);
free_colors(&(config.colors));
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[] = {
&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
*
*/
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
*
*/
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);
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
/*
2015-03-23 20:56:49 +01:00
* Called, when a mode event arrives (i3 changed binding mode).
*
*/
static void got_mode_event(char *event) {
2015-03-24 13:41:16 +01:00
DLOG("Got mode event!\n");
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)
*
*/
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)
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
/* reconfigure the bar based on the current outputs */
i3_send_msg(I3_IPC_MESSAGE_TYPE_GET_OUTPUTS, NULL);
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);
char *old_command = config.command ? sstrdup(config.command) : NULL;
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) {
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
}
/* update fonts and colors */
init_xcb_late(config.fontname);
init_colors(&(config.colors));
/* restart status command process */
if (old_command && strcmp(old_command, config.command) != 0) {
kill_child();
start_child(config.command);
}
free(old_command);
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,
&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
*
*/
static void got_data(struct ev_loop *loop, ev_io *watcher, int events) {
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 */
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) {
ELOG("read() failed: %s\n", strerror(errno));
2010-08-03 21:20:11 +02:00
exit(EXIT_FAILURE);
}
if (n == 0) {
/* EOF received. Since i3 will restart i3bar instances as appropriate,
* we exit here. */
DLOG("EOF received, exiting...\n");
#ifdef I3_ASAN_ENABLED
__lsan_do_leak_check();
#endif
clean_xcb();
exit(EXIT_SUCCESS);
2010-08-03 21:20:11 +02:00
}
rec += n;
}
if (strncmp(header, I3_IPC_MAGIC, strlen(I3_IPC_MAGIC))) {
ELOG("Wrong magic code: %.*s\n Expected: %s\n",
(int)strlen(I3_IPC_MAGIC),
header,
I3_IPC_MAGIC);
2010-08-03 21:20:11 +02:00
exit(EXIT_FAILURE);
}
char *walk = header + strlen(I3_IPC_MAGIC);
uint32_t size;
memcpy(&size, (uint32_t *)walk, sizeof(uint32_t));
2010-08-03 21:20:11 +02:00
walk += sizeof(uint32_t);
uint32_t type;
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) {
ELOG("read() failed: %s\n", strerror(errno));
2010-08-03 21:20:11 +02:00
exit(EXIT_FAILURE);
}
if (n == 0) {
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) */
if (type & (1UL << 31)) {
type ^= 1UL << 31;
2010-08-03 21:20:11 +02:00
event_handlers[type](buffer);
} else {
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 */
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;
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);
if (payload != NULL)
strncpy(walk, payload, len);
2010-08-03 21:20:11 +02: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;
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.
*/
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
*
*/
void subscribe_events(void) {
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\" ]");
} 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\" ]");
}
2010-07-22 01:15:18 +02:00
}