-
Notifications
You must be signed in to change notification settings - Fork 0
Add foreign toplevel icon protocol. #2
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
base: master
Are you sure you want to change the base?
Conversation
Multiple add_buffer events may be sent at different sizes, scales, | ||
and buffer formats. The event must not be sent after 'done'. | ||
|
||
The buffer must be backed by wl_shm and must be square. |
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.
Is this enforced somewhere else in icon specs or protocol? Idk but seems a bit strange a requirement
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.
Its enforced by xdg-toplevel-icon. The compositor could render it into a dmabuf but I see no reason to make it do that.
</description> | ||
|
||
<arg name="size" type="uint" summary="the width and height of the icon in pixels"/> | ||
<arg name="scale" type="uint" summary="the scaling factor of the icon"/> |
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.
No fractional?
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.
xdg-toplevel-icon only exposes integer scales, but we could make this a float in case that ever changes.
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.
A float would be inconsistent with the fractional scale protocol which expects a uint representing "the numerator of a fraction with a denominator of 120".
I'd suggest the better option here might be to add an additional event arg (scale_fractional
) that represents that, and let the client figure out which one it needs. I'm not sure where you'd need it though? Would the scale ever differ from the one advertised by the fractional scale protocol?
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.
If toplevel icon only has integer scales then it's probably fine to leave as uint (idk if there are any plans to change it).
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.
Also general comment about the fractional scale protocol: ppl are already hitting issues with its quantization to 1/120 (common scale/resolution combos are not exactly representable), so it's possible that it'll change to a float in the future
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.
In that case lets just leave it as an int and mirror whatever xdg-toplevel-icon does if changed.
This protocol is intended to mirror xdg-toplevel-icon, allowing clients like bars and window switchers to use icons provided by the foreign client instead of just desktop entries.