Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-04-28T14:46:02Zhttps://invent.kde.org/plasma/plasma-workspace/-/issues/67Save more formats in clipboard history2023-04-28T14:46:02ZFushan WenSave more formats in clipboard historyDitto is a clipboard manager on Windows. The database used in Ditto contains 2 tables, and I think some fields will also be useful for klipper in regards of both performance and usability.
| Main | Data |
|---------...Ditto is a clipboard manager on Windows. The database used in Ditto contains 2 tables, and I think some fields will also be useful for klipper in regards of both performance and usability.
| Main | Data |
|----------------|-----------------|
|ID|ID|
| CRC (used to find duplicate) | ClipBoardFormat (mimetype) |
| Date | oData (binary data) |
| Text | |
| DontAutoDelete (starred) | |
| clipOrder | |
|stickyClipOrder||
The "Main" table is used to store clips. Each clip in the table has a unique CRC which is generated from all formats, and the order is saved in a separate column. In the "Data" table, an ID can be mapped to multiple records, and each record has a different format. The main advantages are:
- The structure allows the frontend to list clips quickly by only reading the "Main" table, and the "Data" table is read only when details should be shown, so users can save more images in klipper with a lower memory footprint.
- More formats like HTML rich text can also be saved in the history, like Windows clipboard history already does.
- Flexible to add more features like "sticky clip", sorting clips by date, and a klipper runner.
To achieve this goal, klipper will need to:
- [ ] Port to SQLite and use the new database
- [ ] Convert the current database
- [ ] lazily load clips on startup
- [ ] Port the search field to using SQL query instead of filtering in a model6https://invent.kde.org/plasma/plasma-desktop/-/issues/79Split libinput and legacy Mouse and Touchpad KCMs2024-02-23T21:09:13ZNicolas FellaSplit libinput and legacy Mouse and Touchpad KCMsThe mouse and touchpad KCMs currently support three different "platforms": KWin Wayland Libinput, X11 Libinput, X11 Synaptics/XLib.
Wayland Libinput and X11 Libinput share mostly the same UI, which is using QML. However the Synaptics UI...The mouse and touchpad KCMs currently support three different "platforms": KWin Wayland Libinput, X11 Libinput, X11 Synaptics/XLib.
Wayland Libinput and X11 Libinput share mostly the same UI, which is using QML. However the Synaptics UI is completely different and using Widgets.
Supporting all of that from the same KCMs makes them massively complex. They have internal backend systems and the KCM is a hybrid of QML and widgets, with all the challenges that brings.
This is not sustainable. We should split the KCMs into a Libinput variant and a legacy variant.
The challenge here is that the current thing handles switching between libinput and legacy at runtime. Would it be fine if it was a compile-time option?https://invent.kde.org/plasma/plasma-nm/-/issues/3Improve UX for adding new VPN connection2023-04-19T14:01:43ZNicolas FellaImprove UX for adding new VPN connectionWhen clicking "Add new connection" in the KCM the user gets presented with a huge list of different connection types to choose from.
Some of them are somewhat obscure technologies (Bond, Team, VLAN).
Some of them are common things (wire...When clicking "Add new connection" in the KCM the user gets presented with a huge list of different connection types to choose from.
Some of them are somewhat obscure technologies (Bond, Team, VLAN).
Some of them are common things (wired ethernet, WiFi), but one usually doesn't create such connections that way. Wired connections should just work when plugging a cable in. For Wifi we expect people to select a discovered WiFi from the applet instead of creating a Wifi connection from scratch.
My guess would be that 99% of the time people go there they want to configure a VPN. And yet VPNs are sorted last in the list. Quite often they probably want to import a VPN from a configuration file they got e.g. from $work, but that item is the last in the list.
How can we make the common case of wanting to add a VPN more streamlined instead of hiding it below a bunch of mostly irrelevant and even confusing options?
For context, this is the current list of available connection types:
![grafik](/uploads/ab52b70361c6bdb60c63324ae715b49e/grafik.png)
@teams/vdghttps://invent.kde.org/plasma/plasma-mobile/-/issues/236[navigationpanel] Switch to gesture only mode by default2024-03-21T18:21:27ZDevin Lin[navigationpanel] Switch to gesture only mode by defaultI think for Plasma 6 we should switch to gesture mode by default, because:
- It takes up screen real estate
- Buttons can be accidentally pressed
- The navigation bar being a different colour from apps (especially ones with graphics in t...I think for Plasma 6 we should switch to gesture mode by default, because:
- It takes up screen real estate
- Buttons can be accidentally pressed
- The navigation bar being a different colour from apps (especially ones with graphics in the footer) looks really ugly
However, in order for this to happen, we need gestures to be better, which means these should be resolved:
- https://invent.kde.org/plasma/plasma-mobile/-/issues/186
- https://invent.kde.org/plasma/plasma-mobile/-/issues/1736.1https://invent.kde.org/plasma/kwin/-/issues/134reduce latency for cursor updates2023-07-26T14:11:51ZXaver Huglreduce latency for cursor updatesRight now we commit atomic commits right after rendering, and have the drm driver wait on rendering to be done. This causes two problems:
- when render time is high, we need to commit up to a full frame before the page flip. This means t...Right now we commit atomic commits right after rendering, and have the drm driver wait on rendering to be done. This causes two problems:
- when render time is high, we need to commit up to a full frame before the page flip. This means the cursor will have a lot more latency than needed
- when we miss the page flip because rendering takes too long, the cursor update is dropped as well
With a proper async update API for cursors missing in the drm API, the next best solution is to always commit right before vblank with updated cursor data, and only update the framebuffer of the primary plane if rendering is complete.6https://invent.kde.org/plasma/plasma-desktop/-/issues/68[Approved] Plasma 6 proposal: Consolidate desktop folder layouts2023-05-08T04:04:48ZOliver Beard[Approved] Plasma 6 proposal: Consolidate desktop folder layoutsCurrently, there are two desktop folder layouts available, 'Folder View' and 'Desktop'. They could be easily merged without issue:
- Folder View could have the option to show no location, instead of the current choices of 'Desktop fold...Currently, there are two desktop folder layouts available, 'Folder View' and 'Desktop'. They could be easily merged without issue:
- Folder View could have the option to show no location, instead of the current choices of 'Desktop folder', 'Files linked to the current activity', 'Places panel item: <>' and 'Custom location: <>'. An option for 'No location' would simply not have any desktop icons and disable the mouse drag selection, _completely_ absorbing the functionality of the Desktop layout option.
- Additionally, it could gain the option to hide desktop icons, which is something a user might want to do, for instance, when creating a screen recording. This would probably appear under the Icons category and as a toggle switch in the context menu under Icons.
| Layout option | Location options |
| ------ | ------ |
| ![image](/uploads/94ce031cba1714d015c7b20116788533/image.png) The layout options, which are somewhat confusing for users and are more of an implementation detail. | ![image](/uploads/f9170732c332c805fabd2d25cd3ca938/image.png) _The 'Places panel item' choice could be removed, as it's kind of redundant - places are visible in the picker dialog for a custom location._ |
The way that the settings window shows settings for both options is dynamic. The choice of layout is in the Wallpaper category, but further categories (Location, Icons, Filter) are added depending on the selected option (and forcing the window to reopen). This is quite poor behaviour, as a user wouldn't expect the settings categories to change.
I was prompted to think about this when a user commented to me that it was strange that the choice of whether to show desktop icons was listed under Wallpapers.
I'm also completely unaware of how this is handled internally, whether Folder View inherits and expands upon the Desktop layout as it appears to do.
This would be a good step in consolidating things ready to eventually place desktop options in System Settings (I could imagine a UI similar to Display Configuration to select the desktop to change, but by default only having customisation for all desktops as a single unit).
I haven't properly used Plasma 4, but I expect that the choice of Layout was originally far richer and this is simply a holdover from that time.https://invent.kde.org/plasma/plasma-desktop/-/issues/66Plasma 6 RFC: Mouse buttons (etc) in shortcuts KCM?2024-03-12T23:37:48ZJohn BrooksPlasma 6 RFC: Mouse buttons (etc) in shortcuts KCM?* Users have wanted to be able to bind shortcuts to input devices other than the keyboard ([Bug 171295](https://bugs.kde.org/show_bug.cgi?id=171295)).
* With !920 it is now possible remap extra mouse buttons to keyboard keys. With plasma...* Users have wanted to be able to bind shortcuts to input devices other than the keyboard ([Bug 171295](https://bugs.kde.org/show_bug.cgi?id=171295)).
* With !920 it is now possible remap extra mouse buttons to keyboard keys. With plasma/kwin!3055 it is possible to remap mouse buttons to other mouse buttons and tablet tool buttons.
* Tablet pad and tool buttons can also be mapped to mouse buttons or keyboard keys.
* This flexibility enables many different workflows for users, which is good.
* However, in the case of shortcuts, only key sequences are supported. Any other input method we've added support for rests on synthesizing key presses which then activate keyboard shortcuts.
This means that a user who wants a mouse button to activate a shortcut needs to add a "sacrificial" keybind to act as a middleman.
And then if we get into other input devices; tablets, game controllers, whatever else one might find on a mobile device. If one wants to use any of them for a shortcut, it has to be a keybind first. Could we, do we want to cut out this middleman?
* Could change the ~~settings~~ shortcuts KCM (called "keys" in the code) and add/modify the necessary APIs so it isn't so [QKeySequence](https://doc.qt.io/qt-6/qkeysequence.html)-centric
* Could enable binding these non-keyboard inputs directly to shortcuts/actions in their respective KCMs.
* Could just keep it the way it is.
Also on the horizon, applications are going to start adding their own shortcuts via the new GlobalShortcuts xdg-desktop-portal. This is the Wayland session's answer to global hotkeys; instead of an application being able to see input while unfocused, it asks the compositor to bind shortcuts, and the compositor will send the application a DBus signal when it detects the shortcut is pressed or released. Instead of using the application's settings menu to bind hotkeys, the compositor's settings menu (the [keys KCM](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/src/globalshortcuts.cpp#L114), in this case) is opened.
Some (most?) applications that support global hotkeys support binding mouse buttons (and possibly other input devices) in their settings menus. If an application uses the global shortcuts portal, the KCM that pops up should be able to do the same, or make it obvious where it can be done.
@ngraham @apol @davidre @davidedmundson, I'd appreciate your input.https://invent.kde.org/plasma/discover/-/issues/19Purpose and future of the "Featured" page2022-10-29T20:58:03ZNate GrahamPurpose and future of the "Featured" pageRight now when you launch Discover, you see the "Featured" page that shows a couple apps which are defined at https://autoconfig.kde.org/discover/featured-5.9.json:
![image](/uploads/70a360d9db3959dd7356f7b0e6b29c49/image.png)
This pag...Right now when you launch Discover, you see the "Featured" page that shows a couple apps which are defined at https://autoconfig.kde.org/discover/featured-5.9.json:
![image](/uploads/70a360d9db3959dd7356f7b0e6b29c49/image.png)
This page suffer from a few problems:
- Information density is very low
- There's no clear pattern or reason for how an app gets here. The set of apps never changes, so it isn't clearly some kind of rotating "apps featured this week" view. See https://bugs.kde.org/show_bug.cgi?id=431316.
- The apps chosen seem rather random. Some are KDE apps, some aren't. Some are basic with broad usefulness to everyone (Kolourpaint) while others are very specialized (KDenlive, KMyMoney, Blender, InkScape, Digikam)
---
I think this page is not ideal for those reasons, and suffers from a lack of direction. I'd like to propose a new direction: turn it into a quick way for people to install commonly-used apps that might not have been pre-installed with their distro. Apps in the list that are either not available or already installed would be hidden, to keep the page relevant. In essence we turn the page into a convenient way to get your system set up quickly, with the following apps listed, separated into categories:
Chat
- Discord
- MS Teams
- NeoChat
- Skype
- Telegram
- Zoom
Documents
- Gwenview
- LibreOffice
- Okular
Games
- GCompris
- Steam
Graphics
- GIMP
- Kolourpaint
- Krita
Media
- Spotify
- VLC
Utilities
- Filelight
- KWrite
- OBS
- Partition Manager
- Warpinator
(note: set of apps is just a suggestion; open to ideas)
---
Since this would increase the number of apps that would generally appear on the page, I would recommend increasing the information density as well, with smaller cards.
@teams/vdg @teams/usabilityhttps://invent.kde.org/plasma/kactivitymanagerd/-/issues/3Feature Discussion: Settings separation between activities2024-02-24T03:45:06ZEric Edlundericedlund2017@gmail.comFeature Discussion: Settings separation between activitiesSeparating application and system configuration by activity would be very helpful for organization. There are many different approaches to doing this in both implementation/scope which will need to be considered before anything is implem...Separating application and system configuration by activity would be very helpful for organization. There are many different approaches to doing this in both implementation/scope which will need to be considered before anything is implemented.
Is it possible to swap out the config files of apps based on what activity we're in? Is there a cleaner approach? How could we best do this? What model would be best for the user?
How can tools like flatpak, bubblewrap and firejail be used to provide this isolation? Are we willing to write packaging specific code?https://invent.kde.org/plasma/discover/-/issues/16Assign apps a safety rating using an at-a-glance "safety scorecard"2024-03-22T21:18:25ZNate GrahamAssign apps a safety rating using an at-a-glance "safety scorecard"This idea was inspired by something I saw in https://www.youtube.com/watch?v=j0IhajCNs14, which is quite a relevant take on Linux app deployment.
Anyway, the idea is to replace the current mishmash of metadata relating to an app's licen...This idea was inspired by something I saw in https://www.youtube.com/watch?v=j0IhajCNs14, which is quite a relevant take on Linux app deployment.
Anyway, the idea is to replace the current mishmash of metadata relating to an app's license and permissions with a simple "Safety scorecard" UI, with expanded information available on a separate page/sheet for people who want to know all the nitty-gritty details. License and permissions are quite technical and my sense is that most users don't really want to dive into this stuff; they would benefit from a higher level safety scorecard that provides at-a-glance information. If we do this, we could relocate the sections about the app's license and permissions to the nerdy expanded view, saving space on the main page and making its information simpler and more relevant.
In essence, we would rate apps on a scale of safety from 0 to 3 points:
- 3 points: Maximum safety
- 2 points: Safe*
- 1 point: Possibly unsafe
- 0 points: Unsafe
Points would be awarded like so:
- +1 point: all licenses are FOSS (0 points if the app has any proprietary licenses)
- +1 point: sandboxed (0 points if it's not sandboxed, or if it's got such broad perimssions that the sandbox is effectively escaped, e.g. full read/write filesystem access in a Flatpak)
- +1 point: packaged by the developer, a member of the developer's organization like the KDE release team, or a trustworthy 3rd-party packager like the user's distro (0 points if the app has been packaged by a random person in a PPA, OBS repo, Flathub package from an internet rando not endorsed by the developer, etc)
Over time we could potentially refine this and add more criteria too.
For apps listed as "Probably Unsafe" or "Unsafe," the simple view would list the factors in a short bulleted list that are causing Discover to rate the app badly.
---
*The reason for 2 out of 3 points being listed as "Safe" is that you really need a combination of at least 2 of the above issues to result in a real problem. For example if an app is not sandboxed, but it's FOSS and packaged by a trustworthy packager, the fact that it has full access to your system is probably not a significant issue. Likewise, a proprietary app that's sandboxed and packaged by someone trustworthy has been checked out and at least contains a means for the user to restrict its activities via the sandbox.
@teams/vdghttps://invent.kde.org/plasma/plasma-systemmonitor/-/issues/23Per process GPU stats2022-12-21T16:57:55ZDavid RedondoPer process GPU statsThere is now a standard way to query GPU stats for processes https://docs.kernel.org/gpu/drm-usage-stats.html
[Intel](https://github.com/torvalds/linux/commit/055634e4b62f109a47727c2c50586e2e318595a9) and [amd](https://github.com/torval...There is now a standard way to query GPU stats for processes https://docs.kernel.org/gpu/drm-usage-stats.html
[Intel](https://github.com/torvalds/linux/commit/055634e4b62f109a47727c2c50586e2e318595a9) and [amd](https://github.com/torvalds/linux/commit/af0b541670090e87996e0894bd0e457edf617541) follows it since 5.19
(for nvidia we already have the plugin which uses nvidia-smi output)
Reading this should only be a matter of implementing it. How we can show it in a sensible way may be a bit harder. Both implementations do not output a singular usage value but rather per 'engine'. The question is what would be the best way to display this in our tableview.
I can think of multiple options:
- Average it
- Take the max
- One column/attribute per engine
- Do it like windows taskmanager, have a GPU usage column and GPU engine column, they show the currently most used engine https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/#processes-tabhttps://invent.kde.org/plasma/powerdevil/-/issues/10Energy Saving KCM redesign2023-12-16T20:19:05ZJakob PetsovitsEnergy Saving KCM redesignThe Energy Saving KCM has long irked me because:
* In order to see the settings for a single field in different battery modes, I have to switch tabs.
* In order to switch settings for both Battery and Low Battery mode, I have to do it tw...The Energy Saving KCM has long irked me because:
* In order to see the settings for a single field in different battery modes, I have to switch tabs.
* In order to switch settings for both Battery and Low Battery mode, I have to do it twice. Three times if changing it for all power states including AC. Makes simple changes hard without providing a pro workflow for the customization-overkill power user that really justifies the complexity.
* Each tab is longer than my default window height, and an unsightly mess of unaligned label indentations.
* In addition to the three tabs of Energy Saving, more power actions can be found both in Activity Power Settings and Advanced Power Settings, and again those are disconnected from the settings in Energy Savings in presentation.
So here's my attempt at designing a better UI for the stuff in Power Management.
The first big change is that settings are organized by function, instead of by power state or activity (together known as "Profile", but I removed that term from the UI to avoid clashing with the distinct "power management profile").
The second big change is that there is one field for the default value affecting each Profile. The user and/or default-setting developer can add one or more Exceptions which set a separate value for the same setting under a certain condition. The idea is that I really only want to set my laptop lid actions once, and use the same settings between Battery and Low Battery for the most part. Exceptions can be removed by the user as well; the existence of a few sensible default Exceptions helps with understanding the concept on the fly.
This paradigm has the effect of both reducing and reintroducing some complexity:
* We generally need only one field per setting, instead of properly named checkbox field plus clumsily-labeled "actual settings value" field.
* However, adding an Exception for a given one-liner field will add two extra lines: one for the condition (e.g. "On battery") together with its "minus" Exception-removal button, and one for the value of the setting under that condition. The combination of both lines gets a common form label assigned, named `↪ except` in my drafts below.
Overall I think it accounts for some good space savings compared to the status quo, but not enough to entirely fit the whole Energy Saving KCM with all of its three tabs into a single page that fits as a whole. So after redesigning the fields, I ended up splitting them into several pages again. I don't think that should be an issue because I get rid of the existing three-page subdivision in Power Management, which is currently "Energy Saving", "Activity Power Settings" and "Advanced Power Settings". Instead, we'd have the following pages below.
All hail ASCII form art!
### Brightness
```
**Laptop Screen**
Screen brightness -------------------------()----------- 70%
↪ except [On battery: ▾] [-]
-------------------()----------------- 50%
Dim automatically [✓] [after 10 min 🡙]
Switch off screen [✓] [after 20 min 🡙]
Exceptions [➕ Add...]
**Keyboard**
Keyboard backlight ----------------------------()-------- 80%
Exceptions [➕ Add...]
```
Default screen brightness goes to Displays & Monitors **in addition** to here.
Default keyboard backlight goes to Keyboard **in addition** to here.
Otherwise the user has to navigate around between different KCMs in order to change related settings.
Ideally these KCMs will link to the Energy Saving KCM for dimming settings.
The string "Laptop Screen" is taken from the Display Configuration KCM, which uses it too. I figure if there's no laptop screen or keyboard backlight, the relevant section and possibly the whole page won't be visible.
For the "Add" button, I'm imagining a pop-up menu with a flat list of Exception-capable field names for that section (e.g. the "Add" button for the "Laptop Screen" sction would contain three actions named "Screen brightness", "Dim screen when inactive" and "Switch off screen"). The selected one will then dynamically add this two-line field with `↪ except` label.
I tried a few permutations for the UI for the condition+value combo, and ended up on this design. You might wonder why the timeout isn't part of the condition line. One reason is that the condition line needs to be generically applicable to all fields, and timeouts only make sense for some of them. The other reason is that this way we can define a condition as state, as opposed to an event.
Also, it keeps the list of exception drop-down options from exploding - we don't want a timed and a non-timed option for each power state, and I'd rather prefer to avoid an extra "after 0 mins" field for each exception by default.
Furthermore, we could use the global brightness shortcut (and power/battery plasmoid) to also set the KCM settings for the current state, instead of only setting the main brightness but having a profile change reset it again next time. Because we know what state we're in, so we can figure out which particular setting to adapt. With a bit of luck, this might fix some of the funky brightness-setting errors that I've encountered a few times in the past.
Note that an Exception with "On battery" condition also matches "On low battery" if the second one isn't matched by an Exception with higher precedence.
Anyway, enough rambling. More pages, same concepts, no nesting of fields in the form layout (note that I put Exception fields on the same level of the form as well, I think it works, even with a makeshift Unicode arrow to connect it to the label above):
### Suspend session
```
**Suspend Actions**
When laptop lid closed [Sleep ▾]
↪ except [When an external monitor is connected: ▾] [-]
[Do nothing ▾]
When power button pressed [Shut down ▾]
Suspend automatically [Do nothing ▾]
↪ except [On battery: ▾] [-]
[Sleep ▾] [after 10 min 🡙]
↪ except [At critical level: ▾] [-]
[Hibernate ▾] [after 1 min 🡙]
While in Sleep mode [ ] Hibernate after a period of inactivity
Exceptions [➕ Add...]
**When Suspending**
Media playback [ ] Pause media players
[🕭 Configure Notifications...]
```
Media playback here is lifted from "Advanced Power Settings", which allows us to put Battery Levels and Charge Limit into a more intuitively named "Battery Settings" page. Also, I genuinely think it makes a good fit here.
I took the freedom to use "When an external monitor is connected" as Exception condition here. This seems consistent with the theme, avoids a random nested checkbox field and allows more customization if desired, but not sure whether it should only be an option on this page / for the laptop lid action or a generally available condition.
Note that this incorporates the "At critical level" action from "Advanced Power Settings" as a standard condition+action field, with "At critical level" being a newly introduced condition as opposed to the original set of AC Power, Battery and Low Battery.
### Performance
```
Power management profile [Best Performance ▾]
↪ except [On battery: ▾] [-]
[Balanced ▾]
↪ except [On low battery: ▾] [-]
[Power Save ▾]
Exceptions [➕ Add...]
```
This one was hard to decide, because three separate fields are easy to add (AC, Battery, Low Battery) but then it wouldn't be consistent with any activities added subsequently. It would be straightforward to hardcode/repeat the fields for each power state and activity, but then one would have to select the same state several times and it's still not clear/configurable whether the activity has precedence or the power state. So I'm going with the same Exceptions concept here as well.
One thing this proposal isn't 100% clear about is precedence of exceptions. Given the above examples, it's clear that there can be an arbitrary number, also I established that the condition drop-down allows a free choice of available conditions. (At least the conditions that haven't already been used above or below for the same setting.)
So one could pick implicit precedence (e.g. low battery always gets chosen before regular battery) but then activities must take precedence before any power states, and that's a little limiting. The order of "except" fields seen by the user doesn't match the programmatic order in that case.
Or one could pick precedence as listed in order and check conditions from the bottom-listed field to the top (default) one, and that makes sense when reading, but users could easily end up with unexpectedly broken setting when selecting exceptions in the wrong listed order. If using order as precedence, should there be up/down buttons next to the "minus" button for removal? Or a "Rearrange" button next to "Add"? Perhaps when selecting a power state, the logic could make sure that AC power is always listed above battery and battery is always listed above low battery, and leave the rest to fate and the user? Not entirely sure about this, but I feel like it's a solvable issue.
### Wireless connections
```
Wi-Fi [Leave unchanged ▾]
Bluetooth [Disable on battery ▾]
Mobile broadband [Disable on low battery ▾]
```
Breaking with the theme, I left out Exceptions for this page because it seems more confusing than beneficial. I guess people might want to enable/disable wireless connections when switching between activities, but is it a strong enough use case to make this form more complicated?
### Run scripts
```
Before suspending [_______________________________________] [🗁]
After waking up [_______________________________________] [🗁]
Trigger [On AC Power ▾] [after 0 min 🡙] [-]
Script [_______________________________________] [🗁]
[➕ Add...]
```
Pressing the "Add" button will add another Trigger/Script pair here, without pop-up menu because there's only one possible thing to add on this page. Other selectable values for the Trigger drop-down include "Leaving AC Power state" (likely with timed delay disabled) as well as analogous "In <activity> activity" and "Leaving <activity> activity" options.
I did put the timeout next to the power state on this page (goes the same for activities) for two reasons. One is that this page is for power users who can bear a little information overload. The other is that unlike on the remaining pages, the Trigger here is not a state but an actual event. It has to be an event when a script is run. That's different than a settings value that should be deterministic and repeatably applicable at any time.
### Battery Settings
```
**Battery Levels**
Low level [15% 🡙]
Critical level [ 3% 🡙]
**Charge Limit**
Keeping the battery charged 100% over a prolonged period of time may accelerate
deterioration of battery health. By limiting the maximum battery charge you can
help extend the battery lifespan. (verbatim from "Advanced Power Settings" KCM)
Stop charging at [80% 🡙]
Start charging only once below [70% 🡙]
```
This is just the remainder of "Advanced Power Settings", minus the relocated "Other Settings" section and thus renamed.
---
I'll leave it like this for now and put it up for discussion. Thoughts, objections, suggestions? Did I perhaps miss someone else doing much of the same work already? Should I have consulted with the VDG first, or is this the way to do it? Am I completely off base for one reason or another? Is this kind of design useless without actually sitting down and implementing it? Tons of questions, and I'm sorry if I perhaps approached it in the wrong way. Gotta use the inspiration when it strikes.
Note that I'm a lazy fuck and might not reply or revise on time. If it helps, feel free to take ownership of this ticket at the right time. Or close it if it's useless, and reuse it elsewhere in a different form. Hopefully it can evolve into something useful eventually.https://invent.kde.org/plasma/plasma-mobile/-/issues/134[widgets/notifications] Add "Do Not Disturb" and "Clear All Notifications" bu...2022-06-27T03:46:20ZDevin Lin[widgets/notifications] Add "Do Not Disturb" and "Clear All Notifications" buttonsAdd a way to configure "do not disturb" from the notifications widget, and a "clear all notifications" button.Add a way to configure "do not disturb" from the notifications widget, and a "clear all notifications" button.Yari Pollaskilvingr@gmail.comYari Pollaskilvingr@gmail.comhttps://invent.kde.org/plasma/latte-dock/-/issues/95wayland: LayerShell support2023-12-18T22:10:05ZMichail Vourlakoswayland: LayerShell supportA thread to discuss about layershell, progress, limitations etc...
**Development Branch:** https://invent.kde.org/plasma/latte-dock/-/tree/work/m_layershell
**cmd:** `QT_WAYLAND_SHELL_INTEGRATION=layer-shell latte-dock -d`
**_NOTE: th...A thread to discuss about layershell, progress, limitations etc...
**Development Branch:** https://invent.kde.org/plasma/latte-dock/-/tree/work/m_layershell
**cmd:** `QT_WAYLAND_SHELL_INTEGRATION=layer-shell latte-dock -d`
**_NOTE: the working branch will be rebased regularly so you will need to redownload it in the future in order to work correctly._**
Issues:
- [ ] **startup:** docks are loaded correctly on startup but Panels can create crashes. To load a Dock on startup the user can use `latte-dock --default-layout`
- [ ] **placement:** all docks and panels are anchored relative to TopEdge because Bottom and Right anchors are not taking into account window width/height changes [upstream issue]
- [x] ~~**exclusive:** Exclusive zone has currently been disabled because it moves also neighbor docks and panels~~ [just needed to use -1 for exclusiveZones of the rest docks and panels]
- [ ] **fullscreen:** popus are appearing fullscreen [upstream issue]
- [ ] **fullscreen:** tooltips are appearing fullscreen [upstream issue]
- [ ] **fullscreen:** context menus are appearing fullscreen [upstream issue]
- [ ] **fullscreen:** normal windows such as Layouts Editor are appearing fullscreen [upstream issue]
- [X] **sway:** ~~when latte launches it steals keyboard focus and no application afterwards can be used with keyboard~~
- [ ] **sway/plasma when launching tasks from inside the dock:** taskmanager applets are never showing any windows. Plasma libtaskmanager is probably not ready for layer-shell way of things.https://invent.kde.org/plasma/plasma-mobile/-/issues/127quicksettings/flashlight: Flashlight is hardcoded for the PinePhone2023-12-31T17:12:00ZBart Ribbersquicksettings/flashlight: Flashlight is hardcoded for the PinePhoneBut people are in fact using Plasma Mobile on _other_ devices. It should be made more generic so the flashlight button in the top drawer works with any device.But people are in fact using Plasma Mobile on _other_ devices. It should be made more generic so the flashlight button in the top drawer works with any device.6Alexey AndreyevAlexey Andreyevhttps://invent.kde.org/plasma/plasma-workspace/-/issues/27Virtual keyboard opens when you launch an app with the search field focused b...2023-11-28T14:35:08ZNate GrahamVirtual keyboard opens when you launch an app with the search field focused by defaultExamples include System Settings, Discover (if https://invent.kde.org/plasma/discover/-/merge_requests/197 is merged), the widget explorer, the Networks applet, and KRunner. If Kickoff and the clipboard applet focused their search fields...Examples include System Settings, Discover (if https://invent.kde.org/plasma/discover/-/merge_requests/197 is merged), the widget explorer, the Networks applet, and KRunner. If Kickoff and the clipboard applet focused their search fields by default, they would have the issue too.
We should find a way to fix this either centrally, or else with a single central solution.
See also:
- https://invent.kde.org/plasma/systemsettings/-/merge_requests/87
- https://invent.kde.org/plasma/discover/-/merge_requests/197
- https://invent.kde.org/frameworks/kirigami/-/merge_requests/398
- https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/670
cc @ahiemstra @mart @apol @davidedmundson @fusionfuturehttps://invent.kde.org/plasma/plasma-desktop/-/issues/24Show a "What's New In This Release" notification when detecting an upgrade fr...2022-10-04T19:05:03ZGuilherme Marçal SilvaShow a "What's New In This Release" notification when detecting an upgrade from one major Plasma version to anotherThis has been briefly discussed in the VDG room and also has a Phabricator Task: https://phabricator.kde.org/T14966
**Feature and benefits of implementing it:**
Basically, Plasma would have a "What's New In This Release" icon show up i...This has been briefly discussed in the VDG room and also has a Phabricator Task: https://phabricator.kde.org/T14966
**Feature and benefits of implementing it:**
Basically, Plasma would have a "What's New In This Release" icon show up in the system tray every time there's a new major Plasma update, like 5.23 > 5.24 (and maybe the x.xx.1 release that distros tend to adopt). To avoid any kind of problems, distros would have to opt-in to that functionality. Some candidates to show that icon by default would be KDE Neon and rolling-release distros (since users that use them are very likely to be interested in knowing more about updates but might not know about KDE social media).
With this feature, Promo could reach many users that would otherwise be oblivious to the fact KDE has social media pages, and they would also be informed of new features and possibly start getting interested in following Plasma development and even contributing. Also, letting them know about all the new features would improve user perception about Plasma and work as a sort of tutorial by showing users all the new things they can do and didn't even know about, thus improving the user experience.
**How it would work:**
Clicking on that button would simply open a browser window with the latest release announcement page. Clicking on it one time or right-clicking and closing it would make it permanently go away until the next major update, that way, it wouldn't be intrusive to the user experience.
It has also been suggested the icon could instead open an applet with a generic message and a button for opening the announcement, or maybe a text snippet of the announcement.
Since this would probably have to be included in Plasma before the announcement is written and we have a link for it, the button could simply point to a hardcoded, generic link which the sole purpose would be to redirect to the correct announcement page once it gets published.
**Some questions:**
Plasma developers:
How feasible would this be to implement?
Is anyone interested in implementing it?
VDG:
What icon should be used?
Would it be better to open the link in a browser window or in a dedicated one?
Should it just open a link or instead work as an applet with a message like "Your KDE Plasma Desktop has been successfully updated. Click on the button below to check all the new features and improvements:"https://invent.kde.org/plasma/plasma-mobile/-/issues/98Cannot answer a call when the phone is suspended2022-08-15T21:44:31ZLadislav NesneraCannot answer a call when the phone is suspendedThe mobile phone wakes up, but no call answering interface is displayed.
(For logs of correct and incorrect course, see. [Manjarno's bug tracking](https://gitlab.manjaro.org/manjaro-arm/issues/pinephone/plasma-mobile/-/issues/136).)The mobile phone wakes up, but no call answering interface is displayed.
(For logs of correct and incorrect course, see. [Manjarno's bug tracking](https://gitlab.manjaro.org/manjaro-arm/issues/pinephone/plasma-mobile/-/issues/136).)https://invent.kde.org/plasma/plasma-mobile/-/issues/85[panel] Port screenshot to new kwin api to fix long delay2021-07-25T17:01:45ZDevin Lin[panel] Port screenshot to new kwin api to fix long delaySee example here:
https://invent.kde.org/graphics/spectacle/-/commit/be8ee0f7efd17f5f29cbf70ac1374ad05f0481ffSee example here:
https://invent.kde.org/graphics/spectacle/-/commit/be8ee0f7efd17f5f29cbf70ac1374ad05f0481ffhttps://invent.kde.org/plasma/plasma-mobile/-/issues/46Add split-screen option2024-03-21T19:31:01ZIvan RancicAdd split-screen optionSo, something like in Android. Activated perhaps by double tap on app switcher button. Once first app has taken upper half of the screen, lower half can show a grid of apps user commonly used in split-screen mode and "below" that, by swi...So, something like in Android. Activated perhaps by double tap on app switcher button. Once first app has taken upper half of the screen, lower half can show a grid of apps user commonly used in split-screen mode and "below" that, by swiping u on the grid, can bring up standard app drawer with the rest of the apps.6.2