Open AdamWagner opened 4 years ago
I don't think stacks will be considered its own entity in the query system, but I can see the use of stacks having an internal id that would be included as an attribute alongside the stack-index in window queries.
As for signals, the current system is not capable of providing custom signals that are not directly mapped 1-to-1 with the macOS notifications that we observe, and so this is unlikely to happen for quite some time. There are other benefits to changing the signal system as well, such as #581
but I can see the use of stacks having an internal id that would be included as an attribute alongside the stack-index in window queries.
Yep, that ↑ would work fine.
And it's helpful to know that signals for stacks is unlikely. Very helpful!
@koekeishiya I updated the issue title to reflect your last comment. It'd be helpful to have a sense of when (soon / not soon) you expect a stack ID attribute could be added to windows, since it affects design decisions in stackline. Thanks!
@koekeishiya
I don't think stacks will be considered its own entity in the query system, but I can see the use of stacks having an internal id that would be included as an attribute alongside the stack-index in window queries.
However, it would be helpful to have control over them with rules. Right now it's not possible to configure a layout that uses stacks. The stacking layer that can be configured there seems to be a completely different concept that doesn't interact with the normal window stacking that can be achieved via window commands.
This is outside the scope of what rules are meant to be used for. If you want to somehow automate layouts, use the signal system instead.
Sent from my iPhone
On 21 Dec 2020, at 17:25, nbcomplete notifications@github.com wrote:
@koekeishiyahttps://github.com/koekeishiya
I don't think stacks will be considered its own entity in the query system, but I can see the use of stacks having an internal id that would be included as an attribute alongside the stack-index in window queries.
However, it would be helpful to have control over them with rules. Right now it's not possible to configure a layout that uses stacks. The stacking layer that can be configured there seems to be a completely different concept that doesn't interact with the normal window stacking that can be achieved via window commands.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/koekeishiya/yabai/issues/672#issuecomment-749060029, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPDZV5FPVJKBS4U5TSY5NTSV5ZG7ANCNFSM4R3CFHNQ.
I'm curious if you intend stacks to be a first class citizen: identifiable by
id
, queryable viayabai -m query --stacks …
etc?1) Ability to query stacks I ask because, currently, stackline's stack detection is the worst of both worlds – complicated and crappy :-) Lacking a mechanism to query stacks directly, stackline assumes that windows that occupy the same space (
a.frame == b.frame
) are in a stack. This is quite fragile:zoom-parent
andzoom-fullscreen
may result in false positives (possible to mitigate by filtering out zoomed-windows, but stacked windows may also be zoomed, and this adds yet more complexity)I would much prefer to query stack data directly from
yabai
. For example:2) Signals for stacks
Stackline's logic for tracking stack state is also really complicated. If you don't think stack signals are going to be added soon, I'll take another pass at trying to simplify it as-is.
Let me know if you want me to split this into 2 issues.