-
-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
c2: Perform matching against "all" property values with special index [*]
#550
Conversation
Codecov Report
@@ Coverage Diff @@
## next #550 +/- ##
==========================================
+ Coverage 38.21% 38.35% +0.13%
==========================================
Files 46 46
Lines 9056 9116 +60
==========================================
+ Hits 3461 3496 +35
- Misses 5595 5620 +25
|
Thanks. |
Should this behavior only apply when using |
Regarding #549 (comment)
I initially used the stack allocated array to reduce the number of memory allocations since matching might be performed quite often.
Do we want to restrict |
Yeah, this is a headache. Or should we have another qualifier for matching arrays? Or maybe something like |
Thought about that, but this would mean we can't rely on Let me think about that again. We might be able to default to Do we even want to change the current behaviour of defaulting to the first entry (i.e. break backwards compatibility)? |
Do you mean that
Yeah, that's one of my worries. |
Yes.
Forgot about Lines 628 to 630 in fb38bf0
|
You are right, looks like we should use |
I'll change that in #549. To get rid of a hardcoded limit, we have to provide a way to get the property length similar to I think |
Just add a |
0e57e5e
to
838e85a
Compare
@@ -610,24 +610,30 @@ static int c2_parse_target(const char *pattern, int offset, c2_ptr_t *presult) { | |||
|
|||
// Parse index | |||
if ('[' == pattern[offset]) { | |||
if (pleaf->predef != C2_L_PUNDEFINED) { | |||
c2_error("Predefined targets can't have index."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wm_state
is going to be a predefined target, and it can have index. are you planning to remove this check later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wm_state
doesn't currently support indexing. That doesn't mean I couldn't add the support for indices. I'm not sure how useful indexing would be, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be good for consistency. Because wm_state is indeed an array behind the sceen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we would inherit the same behaviour (no index: first, index *
: all) as with the custom properties? I can change and document that in #549.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that would be good. (Also in that case maybe we don't need to cache the value of wm_state?) Do you have a feeling on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I am more concerned about users confusing ...
Good point, that plus wm_state
being just a shortcut without other added values (besides caching, but see my next comment), makes me wonder if we should just ask the user to use _NET_WM_STATE@[*]:32a = "_NET_WM_STATE_HIDDEN"
. User won't get wrong expectations from that rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And for the caching aspect, I think we could add generic caching for all properties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…
wm_state
being just a shortcut without other added values …
Yeah, this was just meant as a compromise to make these rules "easier to read" (see #512 (comment)). I am fine with leaving those changes out.
I think we could add generic caching for all properties.
Let me see if this can be nicely done for arbitrary atom/string properties (and atom arrays) without adding too much overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caching can be done on-demand when properties are used, eviction can be done when we get property notify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take over #549 to implement general caching instead of the wm_state
target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Since we decided against the |
838e85a
to
5f83983
Compare
… `[*]` When matching against custom window properties or atoms perform the matching against all available values using logical OR if the special index `[*]` is specified. If no index is specified, we fall-back to the first value. This should help when an atom has multiple values and you only want to check against any of these — e.g. hiding windows with state `hidden`: `--opacity-rule "0:_NET_WM_STATE@[*]:32a *= 'HIDDEN'"` — without having to explicitly specify each index separately or when the index is not known in advance. Updated the manpage with examples for hidden and sticky windows.
5f83983
to
5989477
Compare
[*]
Change the defaultAdd special index[*]
in window-rule matching to check against any value if the property in question is an arrayinstead of only checking the first value if no index is provided. See the discussion in #512 for why this makes more sense:instead of
TODO