Thank you for the bug report!

Please note that Plasma 5.25.90 is not supported for much longer by KDE; supported versions are 5.24, and 5.26 or newer.

If at all possible please upgrade to a supported version and verify that the bug is still happening there.

(In reply to Bug Janitor Service from comment #1)
> Thank you for the bug report!
> 
> Please note that Plasma 5.25.90 is not supported for much longer by KDE;
> supported versions are 5.24, and 5.26 or newer.
> 
> If at all possible please upgrade to a supported version and verify that the
> bug is still happening there.

Hi,

I'm actually in 5.26 but thought that git-stable-Plasma/5.26 was not the one i'm using... since 5.25.90 was the 5.26 beta, i opted for it. Should i select git-stable-Plasma/5.26???

(naturally, my question was not addressed to the bot... :)

*** Bug 483850 has been marked as a duplicate of this bug. ***

We have three practical options for how to do this, if we want to do it:

1. Give overview its own set of favorite apps
- Pros: easy
- Cons: a *third* source of favorite apps that doesn't sync with either Kicker/Kickoff favorites or Task Manager pinned apps. Feels messy.

2. Expose Kicker/Kickoff favorites to Overview
- Pros: those favorites are global in scope, matching the scope of Overview
- Cons: would require making Activities a dependency; see Bug 449919. Possibly stuff from Plasma's Kicker model would also need to be broken out into a non-Plasma library so that Overview would use it without formally depending on Plasma

3. Expose the pinned apps from a particular Task Manager to Overview
- Pros: apps in Overview match the apps you see visually on your panel's task manager
- Cons: these pinned apps are per-panel so the scope doesn't match. Also, there are similar concerns about needing to use a separate library to get the data

I think option #2 would be best if we want to do this. #1 seems undesirable and #3 seems both undesirable and infeasible.

(In reply to Nate Graham from comment #5)
> We have three practical options for how to do this, if we want to do it:

> 2. Expose Kicker/Kickoff favorites to Overview
> - Pros: those favorites are global in scope, matching the scope of Overview
> - Cons: would require making Activities a dependency; see Bug 449919.
> Possibly stuff from Plasma's Kicker model would also need to be broken out
> into a non-Plasma library so that Overview would use it without formally
> depending on Plasma

> I think option #2 would be best if we want to do this. #1 seems undesirable
> and #3 seems both undesirable and infeasible.

I personally think #2 would be great, specially if, once at it, Bug 449919 would be included as well (if indeed the plan is keeping activities).

From a  user perspective, the Overview could be a go-to to access and manage anything desktop-tasks-related.
It would also be a nice way to expose the user more to Activities (yeah, i don't think they're exposed enough!)

However, beside all the possible technical challenge this may represent, there is also the risk of putting "too much noise" in the overview effect (not so much from the launchers, but activities should be well thought on how they will be presented - i remember i've seen some nice mockups that don't take much space/noise).

... all this should be optional (naturally) ...

What about allowing regular panels to be visible or not in overview. By default, all panels will be visible and in panel settings, user can decide if they want it to be shown in overview on not. This has 2 benefits:
1) overview because a central place of managing windows like gnome overview. Users can interact with panels, launch and close applications, and even move them around in different workspaces.
2) users can create special panels that are only visible in overview mode and not in desktop mode. This can be a place for their favorite widgets and applications. This will let users customize the overview and maximize their workflow efficiency.