Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-04-19T14:01:43Zhttps://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/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/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/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-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-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.2https://invent.kde.org/plasma/plasma-workspace/-/issues/5When Widget Sidebar Opens Show Widget Edit Controls2023-11-28T14:35:06ZAndy BettsWhen Widget Sidebar Opens Show Widget Edit ControlsI think it would make a lot of sense that when you enter the widget add sidebar, that the widgets you already have on the desktop have their edit controls showing. It would seem like a simple edit mode.
Something like this:
![Screensho...I think it would make a lot of sense that when you enter the widget add sidebar, that the widgets you already have on the desktop have their edit controls showing. It would seem like a simple edit mode.
Something like this:
![Screenshot_20200816_161850](/uploads/6ddd719509a38fb4a2fdf9209afb4034/Screenshot_20200816_161850.png)
@teams/vdgAndy BettsAndy Bettshttps://invent.kde.org/plasma/plasma-desktop/-/issues/2KColorSchemeEditor Redesign2023-07-29T16:38:15ZNoah DavisKColorSchemeEditor RedesignI asked @mdelafuente to make this mockup a while ago: https://phabricator.kde.org/T12412
![](https://phabricator.kde.org/file/data/ucajyntha2c5ermudhjk/PHID-FILE-t6f2kcqcvjkvqimku5cr/KColorSchemeEditor.png)
# Issues
- [ ] Figure out wh...I asked @mdelafuente to make this mockup a while ago: https://phabricator.kde.org/T12412
![](https://phabricator.kde.org/file/data/ucajyntha2c5ermudhjk/PHID-FILE-t6f2kcqcvjkvqimku5cr/KColorSchemeEditor.png)
# Issues
- [ ] Figure out what to do about the various color effects and options Noah DavisNoah Davishttps://invent.kde.org/plasma/plasma-mobile/-/issues/15Allow packaging to set custom wallpaper2020-10-18T13:08:32ZBart RibbersAllow packaging to set custom wallpaperIn postmarketOS we set the wallpaper of all DE's to a custom one. Currently we do this by [patching `org.kde.phone.homescreen.js`](https://gitlab.com/postmarketOS/pmaports/-/blob/d370a6fe239edf0a899c1a0764b39bef8cec4109/temp/plasma-phone...In postmarketOS we set the wallpaper of all DE's to a custom one. Currently we do this by [patching `org.kde.phone.homescreen.js`](https://gitlab.com/postmarketOS/pmaports/-/blob/d370a6fe239edf0a899c1a0764b39bef8cec4109/temp/plasma-phone-components/set-postmarketos-wallpaper.patch), but it would be nice if there were just a config file we can edit or a command we can execute to do this instead.https://invent.kde.org/plasma/plasma-workspace/-/issues/119Do Not Disturb: When fullscreen applications are present2024-03-19T17:58:33ZKristen McWilliamDo Not Disturb: When fullscreen applications are presentCurrently DnD can be enabled automatically when:
- screens are mirrored
- screen sharing
![image](/uploads/5780293f4a2a33a1fc11cbd81658a067/image.png)
It would be nice to have an option to automatically enable DnD when a fullscreen ap...Currently DnD can be enabled automatically when:
- screens are mirrored
- screen sharing
![image](/uploads/5780293f4a2a33a1fc11cbd81658a067/image.png)
It would be nice to have an option to automatically enable DnD when a fullscreen application is present. This would be useful for presentations, watching movies, etc.
Thoughts?Kristen McWilliamKristen McWilliamhttps://invent.kde.org/plasma/plasma-workspace/-/issues/101RFC: Enable force passing tests in plasma-workspace2024-01-26T17:43:15ZFushan WenRFC: Enable force passing tests in plasma-workspaceDiscussion from !3450 : a consensus is needed to enable force passing tests in plasma-workspace.
Background incident: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3315 was merged without passing testlockscreen.
Main ...Discussion from !3450 : a consensus is needed to enable force passing tests in plasma-workspace.
Background incident: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3315 was merged without passing testlockscreen.
Main obstacles:
- Some tests are flaky
- Nobody steps up to fix the failing tests
Solutions:
- `ctest-arguments: '--repeat until-pass:5'`
- If a test keeps failing but nothing goes wrong in reality, it means the test is outdated and can be disabled or removed until someone cares about it, which is totally fine given the limited development resource. The only unacceptable thing is **merging something with a obviously related test failing while the test still passes in master**.https://invent.kde.org/plasma/plasma-welcome/-/issues/20Get New Stuff & KDE Store2023-09-04T12:01:50ZOliver BeardGet New Stuff & KDE StoreWe should probably expand more on the [KDE Store](https://store.kde.org/) which provides content for the GNS system.
![image](/uploads/503d1fe6b0b2519337091008a70193b8/image.png)
We could also include something similar to the network p...We should probably expand more on the [KDE Store](https://store.kde.org/) which provides content for the GNS system.
![image](/uploads/503d1fe6b0b2519337091008a70193b8/image.png)
We could also include something similar to the network page that shows a mock settings window with the Get New X header option. This shouldn't be particularly difficult and might be something we reuse in other places - KRunner's page could show its relatively simple popup.6https://invent.kde.org/plasma/plasma-desktop/-/issues/95Plasma 6 proposal: Make the minimize all mode default for peek at desktop2023-07-16T09:39:34ZTanbir JishanPlasma 6 proposal: Make the minimize all mode default for peek at desktopMinimize all should be the default mode for the peek at desktop widget.
It is first of all much more familiar behaviour for the users.
The logic behind peek at desktop mode is that the user can go back to the previous window order jus...Minimize all should be the default mode for the peek at desktop widget.
It is first of all much more familiar behaviour for the users.
The logic behind peek at desktop mode is that the user can go back to the previous window order just by clicking on any app icon again. This has several downsides.
1. It already looks like the windows are being minimized(they actually are minimized I think). The user expects them to behave like any minimized windows and only the clicked one should be raised above. Not all of them.
2. The user cannot just minimize all windows easily. The keyboard shortcut is only for advanced users. Moreover, **there must be a default way to minimize all windows, easily visible and accessible and usable with a mouse**.
3. The logic for the current behaviour doesn't make sense, at all. **Nobody wants to preserve the z order of inactive windows and minimize them all, take a look at the desktop and maximize them back**. It sounds like an invented use case. The order of the inactive windows doesn't concern most of the users, if not all. I as a user, even for taking a look at the desktop, or for interacting with icons prefer to minimize them all and just come back to the last active task again. I don't find myself in the need of inactive tasks being around. Also it really frustrates me that I cannot just click it and minimize all apps and then maximize the last active one, so that I can just minimize all the inactive tasks.
4. Last but not the least, it gives users coming from a different popular platform a false sense of familiarity. The functionality is at the same place and almost behaves the same way initially, but it starts to act differently later.https://invent.kde.org/plasma/plasma-welcome/-/issues/17Advertise discuss.kde.org in Welcome Center2023-09-11T16:01:05ZOliver BeardAdvertise discuss.kde.org in Welcome CenterSomething of a mental note to myself for when I pick up work on Welcome Center over summer:
I think we should advertise Discuss in the application.
I'm not sure whether this would be a good candidate for a page proper, or just a link. ...Something of a mental note to myself for when I pick up work on Welcome Center over summer:
I think we should advertise Discuss in the application.
I'm not sure whether this would be a good candidate for a page proper, or just a link. I tend towards the latter, but I think the former could be interesting for driving users to it, especially with /r/KDE going dark.6Oliver BeardOliver Beardhttps://invent.kde.org/plasma/plasma-desktop/-/issues/93Plasma 6 proposal: rethink splash screen themability2023-06-12T14:21:31ZNate GrahamPlasma 6 proposal: rethink splash screen themabilityRight now the KSplash appearance is themable. Users can download splash screens from store.kde.org and Global Themes can include them. So far so good.
But. Being themable currently offers a paradox of too much choice for things that don...Right now the KSplash appearance is themable. Users can download splash screens from store.kde.org and Global Themes can include them. So far so good.
But. Being themable currently offers a paradox of too much choice for things that don't matter, and not enough for things to do. For example, right now the most basic thing a user would want to do--[change the splash screen background](https://bugs.kde.org/show_bug.cgi?id=355250)--is not supported. Instead they have to either fork the splash screen and change the path in the QML code, or find a new splash screen theme that has a background they like. These are not ideal ways to offer customizability for a simple background image. And as a result, https://store.kde.org/browse?cat=488&ord=latest is full of clones of the default Breeze splash screen with various random images in them. It even used to be much worse in the past when there were over 1000 splash screens with random cringeworthy computer-generated anime girls as the background, and I convinced the author to put them all in a single package so they wouldn't be so visible.
In addition, the actual QML code differences between one splash screen and another is generally small to non-existent; there are simply only so many ways to display a "loading your desktop" screen beyond what you can achieve by overlaying some icons or text on top of an image.
I'm starting to think that offering themability here was a mistake, and instead we should have a single hardcoded splash screen with a loading spinner in the center overlaid on top of a static image that's user-customizable (and can also be configured in a Global Theme's `defaults` file. Custom branding for distros and Global Themes could then be provided by simply swapping out the image for a custom one.6