| Summary: | Effect to slide notifications | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Vlad Zahorodnii <vlad.zahorodnii> |
| Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | CC: | kde, kde, nate |
| Priority: | LO | ||
| Version First Reported In: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Vlad Zahorodnii
2018-08-30 09:37:28 UTC
CC'ing Nate as a member of VDG. Note notifications are being rewritten for 5.something by Kai (kbroulik) now CCd There's mockups at https://community.kde.org/Plasma/Notifications Probably best to keep any work on kwin in sync to make sure changes are still relevant > There's mockups at > https://community.kde.org/Plasma/Notifications https://community.kde.org/images.community/0/08/On-desktop_notif_grouping.jpg Are grouped notifications have own windows? Or they all live under single notification window? Or that's still a mockup? A group will be a single window, at least that's what I have planned. Inside we could use ListView transitions to animate it. There's no proper code written for that yet, though Here's a list of potential animations: * fade: notifications fade in and out when they are shown or hidden (like the Fade effect); * glide: notifications glide in and out when they are shown or hidden (like the Glide effect). Also, maybe, they have to slide a little bit; * scale: notifications scale in and out when they are shown or hidden (like the Scale effect); * slide: notifications slide in and out when they are shown or hidden (like the Sliding Popups effect). The first 3 animations(well, maybe, except the second one) don't need any coordination with the notifications applet. The last one and the notification applet need some coordination. E.g. from what edge to slide notifications? Also, currently, new notifications can overlap with the "re-stacked" ones. I don't know how to fix that because there could be several notification applets. Also, if it's guaranteed that there could be only one notification applet, the dedicated effect would need to know where notifications appear, in what order they appear, etc. s/coordination/cooperation/ I implemented pretty dummy version of this effect: https://www.youtube.com/watch?v=3jX-06mXkMg Do you have any input? https://www.youtube.com/watch?v=B3Y45z0Eb2A @Kai Not sure whether that's a bug in KWin, but effects receive signals in the following order: windowAdded / Notification 0 windowAdded / Notification 1 windowAdded / Notification 2 windowGeometryShapeChanged windowGeometryShapeChanged windowClosed / Notification 0 windowGeometryShapeChanged windowGeometryShapeChanged windowClosed / Notification 1 ... windowGeometryShapeChanged windowGeometryShapeChanged windowClosed / Notification 10 With this sequence of emitted signals, it's really hard to implement proper version of this effect (or any other that wants to correctly animate notifications). Any interest in upstreaming it? I think that effect is nicer than the default one. |
