01:03wlb: wayland-protocols Issue #168 closed \o/ (Request for New Wayland Protocol to Improve Window Taskbar Progress Features https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/168)
09:20pq: bwidawsk, before xdg-shell, we used keyboard focus to indicate that the window should be drawn with an "active" look, as in, this window is the default target of input events, especially keyboard events. Then we noticed it does not work too well on systems that have no keyboard: all windows would always look inactive no matter how many times you touched it.
09:23pq: bwidawsk, the point of "active" is to let the end user know which window would be the target of actions (like keyboard input) that do not themselves have a specific target. People also expect the last clicked/touched window to "look active". Otherwise it seems somehow not responsive.
09:24pq: bwidawsk, since activeness is traditionally indicated with window decorations style, and Wayland defaults to CSD, the active state is needed.
11:00wlb: weston/main: Pekka Paalanen * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/903b6b93367e4207cceec3b7ec85f6a9a51b21a2...309a546165f42690abbaba3350207ac989d23faa
11:00wlb: weston Merge request !1358 merged \o/ (gl-renderer: Improve clipper API https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1358)
17:36bwidawsk: pq: thanks for the explanation, makes sense
17:36bwidawsk: so for a traditional desktop, keyboard focus and activation would go together
18:13zamundaaa[m]: bwidawsk: not necessarily. A window can be active while a popup has keyboard focus for example
18:19bwidawsk: right, that's true,
21:20framework: quit