Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2024-02-12T02:01:28Zhttps://invent.kde.org/plasma/kactivitymanagerd/-/issues/4Research: What tools could be used enforce activity specific behavior?2024-02-12T02:01:28ZEric Edlundericedlund2017@gmail.comResearch: What tools could be used enforce activity specific behavior?To make apps behave differently in different activities, we will need a way of manipulating them. Since the vast majority of applications are unaware of the activity system, it seems we will need to "trick" them. There are many possible ...To make apps behave differently in different activities, we will need a way of manipulating them. Since the vast majority of applications are unaware of the activity system, it seems we will need to "trick" them. There are many possible ways to do this.
https://github.com/alexjp/testingfirejailhttps://invent.kde.org/plasma/kactivitymanagerd/-/issues/5Discussion: How should we switch between activities?2024-02-08T12:48:57ZEric Edlundericedlund2017@gmail.comDiscussion: How should we switch between activities?A key to making the Activity system understood is making switching activities intuitive. One of our tasks will need to be to evaluate the current switching paradigm.
Design Considerations:
- Doesn't feel buggy
- Very simple
- Implies a...A key to making the Activity system understood is making switching activities intuitive. One of our tasks will need to be to evaluate the current switching paradigm.
Design Considerations:
- Doesn't feel buggy
- Very simple
- Implies accurately how activities function
I haven't read BUG: 419499 yet but it discusses this.https://invent.kde.org/plasma/kactivitymanagerd/-/issues/6Definition Discussion: What are Activities?2024-03-07T05:12:48ZHeqro IglensDefinition Discussion: What are Activities?Defining what Activities are used to be just a concern of mine, but the well-known now [issue 35](https://invent.kde.org/plasma/plasma-workspace/-/issues/35) confirmed my belief that, in order to maintain a clear course of maintenance fo...Defining what Activities are used to be just a concern of mine, but the well-known now [issue 35](https://invent.kde.org/plasma/plasma-workspace/-/issues/35) confirmed my belief that, in order to maintain a clear course of maintenance for this feature, it is fundamental be explicit as to which features we expect Activities to cover.
And most importantly, in order for any user to understand what Activities are, it is primordial to be able to explain Activities in a succinct way. The current README.MD reads
> When a user is interacting with a computer, there are three main areas of contextual information that may affect the behaviour of the system: who the user is, where they are, and what they are doing.
> *Activities* deal with the last one. An activity might be "developing a KDE application", "studying 19th century art", "composing music" or "watching funny videos". Each of these activities may involve multiple applications, and a single application may be used in multiple activities (for example, most activities are likely to involve using a web browser, but different activities will probably involve different websites).
> KActivities provides the infrastructure needed to manage a user's activities, allowing them to switch between tasks, and for applications to update their state to match the user's current activity. This includes a daemon, a library for interacting with that daemon, and plugins for integration with other frameworks.
There is a glaring issue with using conversational style in here. This issue is that **there is no straight and to the point definition of Activities**.
With this thread, I suggest everyone to propose different definitions of Activities and play, when possible, devil's advocate against them. I expect to replace the current README.MD file with one reached by consensus, and this thread to be the seed of a possible Documentation-Driven Development(-ish) way to keep a firm step on getting right what the community wants Activities to be.https://invent.kde.org/plasma/kactivitymanagerd/-/issues/7Discussion: How will VDs need to be changed?2024-02-11T16:11:14ZEric Edlundericedlund2017@gmail.comDiscussion: How will VDs need to be changed?An idea common in all paths for activities being considered is that we will need to have different virtual desktops in different activities. This will be a pretty large refactor, so we need to figure out all the details.
- How will VD b...An idea common in all paths for activities being considered is that we will need to have different virtual desktops in different activities. This will be a pretty large refactor, so we need to figure out all the details.
- How will VD backgrounds and widgets be handled? Per desktop? Per activity?
- Can activities share common desktops? What operations can be done on desktops between activities?
- What's the best way to present this to the user?
- How do different users use VDs now?https://invent.kde.org/plasma/flatpak-kcm/-/issues/13Implement support for "highlight changed settings" feature2022-08-23T15:03:20ZNate GrahamImplement support for "highlight changed settings" featureYou can use `KCM.SettingStateBinding` objects to determine when an item is different from its default setting and highlight the control in orange (if there is a control) or add an orange dot (if there is not).
Copy other KCMs for inspir...You can use `KCM.SettingStateBinding` objects to determine when an item is different from its default setting and highlight the control in orange (if there is a control) or add an orange dot (if there is not).
Copy other KCMs for inspiration and code.https://invent.kde.org/plasma/kscreenlocker/-/issues/6Only show interactive lock screen controls on the primary screen2024-01-15T15:25:35ZNate GrahamOnly show interactive lock screen controls on the primary screenCurrently, when using a multi-screen set up, an identical copy of the lock screen UI is displayed on all screens.
Various people in the VDG have desired to show the lock screen only on one screen, in the case when there are more than on...Currently, when using a multi-screen set up, an identical copy of the lock screen UI is displayed on all screens.
Various people in the VDG have desired to show the lock screen only on one screen, in the case when there are more than one. Other screens would just show a black background, or a static blurred copy of the wallpaper, or whatever. VDG folks can figure it out. :)
The primary reasons for this would be usability and aesthetics. Usability is improved anytime we let the user avoid making a choice, so only showing one lock screen would make it obvious that you interact with the single thing that's visible. In terms of aesthetics, it would be nicer to not duplicate the same interactive UI on multiple screens, which is a bit visually awkward right now.
---
A secondary benefit would be de-complexification of the implementation. Having to handle multiple screens means multiple sources of data signals that can cause race conditions. The recent lock screen PAM work for Plasma 5.25 generated several of these that range from [annoying](https://bugs.kde.org/show_bug.cgi?id=455380) to [severe](https://bugs.kde.org/show_bug.cgi?id=456210). If we could guarantee only one interactive lock screen UI on one monitor, all the code that handles multi-screen complexities can be removed, and bugs due to race conditions from showing multiple UIs are fixed automatically.
---
In the past I've been told that we had to show the interactive UI on all screens for technical reasons: at the time there was no Primary Screen concept on Wayland, so the screen locker couldn't guarantee that the interactive UI would be shown on an enabled screen, in the case when some were turned off and it had to choose a single screen to appear on. Also without a Primary Screen, the actual screen it appeared on could vary over time seem random to the user.
But today our Wayland session does have a Primary Screen. So the screen locker can safely target the Primary Screen for both the Wayland and X11 sessions to show the interactive UI on, and all other screens can be left blank.
@teams/vdg @davidedmundsonhttps://invent.kde.org/plasma/flatpak-kcm/-/issues/23Allow to remove applications from the KCM2022-09-21T11:57:23ZAleix Pol GonzalezAllow to remove applications from the KCMWhile reviewing the applications it could make sense to want to manage the Discover presence.
We could either uninstall here or redirect to Discover and do it there.While reviewing the applications it could make sense to want to manage the Discover presence.
We could either uninstall here or redirect to Discover and do it there.https://invent.kde.org/plasma/flatpak-kcm/-/issues/24Beware of changes on disk2022-09-06T14:49:17ZAleix Pol GonzalezBeware of changes on diskIt could happen that applications change as we use the KCM, we should make sure that nothing breaks in that case.It could happen that applications change as we use the KCM, we should make sure that nothing breaks in that case.https://invent.kde.org/plasma/plasma-desktop/-/issues/44Make applet popup resizable using keyboard shortcuts2022-09-08T16:03:35ZFushan WenMake applet popup resizable using keyboard shortcuts> Make The Start Menu Wider and Taller – Ctrl + Arrow Keys
>
> You can customize the width and height of the Start Menu. To do so, click and drag the edge of the Start menu with your mouse to make it taller or shorter, or wider. The key...> Make The Start Menu Wider and Taller – Ctrl + Arrow Keys
>
> You can customize the width and height of the Start Menu. To do so, click and drag the edge of the Start menu with your mouse to make it taller or shorter, or wider. The keyboard shortcut to resize the Start Menu bar is Ctrl+Arrow keys.https://invent.kde.org/plasma/plasma-mobile/-/issues/211[actiondrawer] Improve performance of screen rotation2024-03-16T17:15:42ZDevin Lin[actiondrawer] Improve performance of screen rotationCurrently during screen rotation the entire action drawer is reloaded which can be slow on mobile devices. Share components if possible between landscape and portrait and avoid the use of too many loaders that reload during rotation.Currently during screen rotation the entire action drawer is reloaded which can be slow on mobile devices. Share components if possible between landscape and portrait and avoid the use of too many loaders that reload during rotation.https://invent.kde.org/plasma/kwin/-/issues/117Virtual Desktops for Plasma 62024-02-28T16:05:00ZXaver HuglVirtual Desktops for Plasma 6This is sort of part of the Activities discussions, but because it's a pretty large topic without them as well I split out this issue for VDs.
# Status Quo
There's a grid of n \* m virtual desktops. These VDs are static, cover all outpu...This is sort of part of the Activities discussions, but because it's a pretty large topic without them as well I split out this issue for VDs.
# Status Quo
There's a grid of n \* m virtual desktops. These VDs are static, cover all outputs and are the same in all Activities. When you switch VDs, all windows on all monitors switch VDs. When you switch Activities, by default it stays in the same virtual desktop position or optionally switches you to the last VD used in the switched-to Activity.
# Use cases
I think these are the two high level use cases we have to take care of:
1. permanent spatial separation of smaller tasks or applications. An example for this would be that you always put the music player on a specific VD, the IDE on a different one etc
2. providing more space to work with, but without any persistent task association. Effectively VDs are additional monitors for this use case
I'll call these (1) static and (2) dynamic setups from here on.
# Multi Monitor
There's two options in regards to multi monitor:
1. All monitors are on the same VD. Switching VDs will move the state on all monitors
2. All monitors have a separate list of VDs. Both options to switch only on one monitor and on all monitors at once can be provided
# Activities
Generally it makes sense for both static and dynamic setups for VDs to be completely separate per Activity.
Ideally, the dynamic/static state would also be per Activity, but if it makes the implementation simpler I think it wouldn't be a large loss to make it be the same in all Activities. Same for multi monitor options; it's probably not necessary to support a different setting per Activity.
# What to (not) support
In order to limit the complexity of both implementation and UX, a line has to be drawn somewhere. I think we can simplify these things:
- static setups + per monitor VD layouts. Static setups should be required to have the same amount of VDs per monitor, so that we have a clear and intuitive mapping of what should happen when you unplug a monitor with windows still on it (-> move into the matching VD on the other monitor)
- dynamic setups + VD grids. While not impossible, grids do make the UX more complex, especially if VDs are automatically added and removed. So I think we should just not support that
- naming VDs in dynamic setups. Names create the illusion that VDs would be somehow permanent when they're not, so that should not be supported either.
- sharing VDs between Activities. With Activities being explicit separation between environments, sharing VDs doesn't make any sense and should not be supported
- apps interacting with VDs. The usefulness is questionable and creates very different API requirements, so keeping access restricted to plasmashell in the new implementation would be sensible
# How to get there
In order for KWin internals to change, the outward facing APIs must also change; that's what more or less requires such a change to happen with the Plasma 6 transition. The APIs to change would be:
- Wayland: https://invent.kde.org/libraries/plasma-wayland-protocols/-/blob/master/src/protocols/plasma-virtual-desktop.xml, can be easily extended. Adopting https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40 would also be in the cards, it supports pretty much everything we need
- X11: https://invent.kde.org/frameworks/kwindowsystem/-/blob/master/src/platforms/xcb/netwm.h, need to create new API for that
- also dbus for some reason? https://invent.kde.org/plasma/kwin/-/blob/master/src/virtualdesktopsdbustypes.cpp
- Effects and scripting
I haven't started properly looking into any implementations yet, but if we need to break backwards compatibility with other X11 DEs anyways, we could directly switch to a dbus protocol or sth that can be used on both Wayland and X11https://invent.kde.org/plasma/plasma-mobile/-/issues/214lookandfeel/logout: Draw above lockscreen2024-03-21T18:21:26ZDevin Linlookandfeel/logout: Draw above lockscreenUse the new lockscreen protocol to draw the logout popup over the lockscreen.
See https://invent.kde.org/andreyev/lockscreenoverlaytest/-/tree/qml-engineUse the new lockscreen protocol to draw the logout popup over the lockscreen.
See https://invent.kde.org/andreyev/lockscreenoverlaytest/-/tree/qml-engine6.1https://invent.kde.org/plasma/flatpak-kcm/-/issues/27Pass "const QString &varName" instead of "QString varName" throughout the cod...2022-09-16T01:05:41ZSuhaas JoshiPass "const QString &varName" instead of "QString varName" throughout the codebaseIn a bunch of places, especially constructors, we are passing the whole object instead of the reference. This is against KDE's coding practices and should be fixed.In a bunch of places, especially constructors, we are passing the whole object instead of the reference. This is against KDE's coding practices and should be fixed.https://invent.kde.org/plasma/plasma-desktop/-/issues/49Accessibility quick settings applet2023-08-24T01:34:33ZFushan WenAccessibility quick settings applet5.272024-10-01https://invent.kde.org/plasma/plasma-mobile/-/issues/219homescreens/folio: Keyboard arrow navigation2024-03-21T17:56:05ZSeshan Ravikumarhomescreens/folio: Keyboard arrow navigationAllow app delegates to be navigated (by highlight) using the keyboard arrow keys (or equivalent input device, such as the D-Pad mapped to arrows on portable gaming devices). This would allow users to select and open apps in a more natura...Allow app delegates to be navigated (by highlight) using the keyboard arrow keys (or equivalent input device, such as the D-Pad mapped to arrows on portable gaming devices). This would allow users to select and open apps in a more natural way on certain devices.
Additionally, on Halcyon, allow the arrows to navigate between the favourites and app list.6.2https://invent.kde.org/plasma/breeze-grub/-/issues/1Proposal: migrate the content in this repo into Breeze repo2023-10-31T13:00:18ZNate GrahamProposal: migrate the content in this repo into Breeze repoThe content in this repo belongs to the Breeze theme, most of which lives in the `breeze` repo... but not all of it. In the interest of consolidating and making it easier to have all the Breeze stuff installed, I'd like to propose moving...The content in this repo belongs to the Breeze theme, most of which lives in the `breeze` repo... but not all of it. In the interest of consolidating and making it easier to have all the Breeze stuff installed, I'd like to propose moving the content in this repo into the `breeze` repo and then archiving it.
...preserving git history, of course.
See also https://invent.kde.org/plasma/breeze-plymouth/-/issues/15.27Joshua Goinsjosh@redstrate.comJoshua Goinsjosh@redstrate.comhttps://invent.kde.org/plasma/breeze-plymouth/-/issues/1Proposal: migrate the content in this repo into Breeze repo2023-10-31T13:00:15ZNate GrahamProposal: migrate the content in this repo into Breeze repoThe content in this repo belongs to the Breeze theme, most of which lives in the `breeze` repo... but not all of it. In the interest of consolidating and making it easier to have all the Breeze stuff installed, I'd like to propose moving...The content in this repo belongs to the Breeze theme, most of which lives in the `breeze` repo... but not all of it. In the interest of consolidating and making it easier to have all the Breeze stuff installed, I'd like to propose moving the content in this repo into the `breeze` repo and then archiving it.
...preserving git history, of course.
See also https://invent.kde.org/plasma/breeze-grub/-/issues/15.27Joshua Goinsjosh@redstrate.comJoshua Goinsjosh@redstrate.comhttps://invent.kde.org/plasma/bluedevil/-/issues/4Daemon destructor is not called during logout2022-10-06T09:31:40ZMikhail VinogradovDaemon destructor is not called during logoutDaemon destructor is not called during logout. In order to reproduce the problem, you need to logout and login again.
[The destructor](https://invent.kde.org/plasma/bluedevil/-/blob/master/src/kded/bluedevildaemon.cpp#L105) will not wor...Daemon destructor is not called during logout. In order to reproduce the problem, you need to logout and login again.
[The destructor](https://invent.kde.org/plasma/bluedevil/-/blob/master/src/kded/bluedevildaemon.cpp#L105) will not work and the system will not save the new state of the monitor. For example, if you set a different bluetooth power state and log out, your state will not change after logging in (with `launchState=remember` config option).
Most likely this is due to calling `kill` instead of `terminate` for the kded modulehttps://invent.kde.org/plasma/kscreen/-/issues/7OsdManager is designed to handle multiple Osd objects at once2022-10-13T14:42:43Zivan tkachenkoOsdManager is designed to handle multiple Osd objects at once…but only one of them would exist at any given point in time. Seems like that manager component was developed when OSDs were supposed to be displayed on all screens at once, and/or OSD service itself was supposed to be an always-running ...…but only one of them would exist at any given point in time. Seems like that manager component was developed when OSDs were supposed to be displayed on all screens at once, and/or OSD service itself was supposed to be an always-running background process.
I suggest dropping extra complexity, starting from QMap of output names to Osd instances.David EdmundsonDavid Edmundsonhttps://invent.kde.org/plasma/plasma-mobile/-/issues/223ApplicationListModel code is dupe2022-10-16T23:39:09ZAleix Pol GonzalezApplicationListModel code is dupeWe should find places to put the code to share. Copying code is bad!We should find places to put the code to share. Copying code is bad!