bbd2394601 added support for ‘rename’
and ‘move’ events. In order to do that, it changed how workspace
events are matched against our internal workspace list: from string
comparing the workspace name, to checking i3/sway’s workspace ID
parameter.
This introduced a regression in our handling of persistent
workspaces. A persistent workspace is one that isn’t removed from the
bar when it’s deleted (empty, and switched away from) by i3/sway.
This concept doesn’t exist in i3/sway, but is something we’ve
added. Put simple, the way we do this is be keeping the workspace in
our list, even when i3/sway tells us it has been deleted.
However, at this point the workspace doesn’t have an ID anymore. And
the same is true at startup; when we initialize the persistent
workspaces, we only have their names. Not their IDs (since the
workspaces don’t actually exist yet).
To this the regression, we need to:
a) fallback to looking up workspaces by name. That is, if we fail to
find one with a matching ID, try again using the workspace name. For
_this_ to match, we also required the matched workspace to be a
persistent workspace, with an ID < 0 (which essentially means the
workspace doesn’t exist yet).
b) reset the ID to -1 when a persistent workspace is "deleted".
Closes#253
73ccafdade