Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2023-04-18T23:30:37Zhttps://invent.kde.org/plasma/kscreen/-/issues/5Applet: highlight current screen layout if possible2023-04-18T23:30:37Zivan tkachenkoApplet: highlight current screen layout if possibleI'll move it to bugs.kde.org if/when I have time for that.
![applet](/uploads/7ccb1dedaf90f46f853f15412c324e02/image.png)
This applet should have an ability to represent currently selected mode as a `checked` button state or something....I'll move it to bugs.kde.org if/when I have time for that.
![applet](/uploads/7ccb1dedaf90f46f853f15412c324e02/image.png)
This applet should have an ability to represent currently selected mode as a `checked` button state or something.
The challenge is that such information is probably not easy to collect. I'd not expect it to be available in the current KScreen API — although admittedly I haven't checked.ivan tkachenkoivan tkachenkohttps://invent.kde.org/plasma/latte-dock/-/issues/104Non linear scale calculation for the Parabolic Effect2022-03-05T09:14:40ZKaran SinghNon linear scale calculation for the Parabolic EffectHi,
I was wondering if you could try out this mathematical approach to introduce a non linear approach for scale calculation in the parabolic effect:
![image](/uploads/85e31763abc650fe0c5ec994119d79e5/image.png)
![image](/uploads/ce49...Hi,
I was wondering if you could try out this mathematical approach to introduce a non linear approach for scale calculation in the parabolic effect:
![image](/uploads/85e31763abc650fe0c5ec994119d79e5/image.png)
![image](/uploads/ce49fb80a0b4ba549fb851b191fbfe05/image.png)
I found these on StackOverflow and seem to be a good implementation for scale calculation. Supposedly macOS uses this function for their dock.https://invent.kde.org/plasma/plasma-mobile/-/issues/175startupfeedback: Only trigger on a single screen2024-03-21T18:21:26ZDevin Linstartupfeedback: Only trigger on a single screenThe startup feedback triggers on all screens with the homescreen right now, it should only be triggered on a single screenThe startup feedback triggers on all screens with the homescreen right now, it should only be triggered on a single screen6.1https://invent.kde.org/plasma/kwin/-/issues/82Missing pointer_leavel and pointer_enter in some cases2022-02-17T03:14:42Ztang haixiangMissing pointer_leavel and pointer_enter in some casesHover state of QCombobox has not been reset
Click on the qcombobox to pop up a popup window, and click the left mouse button to make the popup window disappear. Repeat several times.
qcombobox is still in hover state. This problem o...Hover state of QCombobox has not been reset
Click on the qcombobox to pop up a popup window, and click the left mouse button to make the popup window disappear. Repeat several times.
qcombobox is still in hover state. This problem only exists in wayland
I compared the logic under X11 and Wayland.
X11: popup menu -> right click outside the menu -> menu disappears -> received XCB_LEAVE_NOTIFY and XCB_ENTER_NOTIFY
At this point the control's WA_UnderMouse will be reset.
Wayland: Pop-up menu -> right-click outside the menu -> menu disappears without any leave or enter events.
The WA_UnderMouse state of Widget and QCombobox is not reset.
I'm not sure if this is a window manager bug, I tested it under kwin and weston, both.
I reported this to Qt, but got no responsehttps://invent.kde.org/plasma/plasma-workspace/-/issues/35Deprecate and remove Activities2024-02-11T00:39:53ZNate GrahamDeprecate and remove ActivitiesIt is with a heavy heart that I write this, but the Activities feature suffers from multiple significant issues and I think it should be deprecated in Plasma 5 and deleted in Plasma 6.
# It's confusing and doesn't work for common use ca...It is with a heavy heart that I write this, but the Activities feature suffers from multiple significant issues and I think it should be deprecated in Plasma 5 and deleted in Plasma 6.
# It's confusing and doesn't work for common use cases
Activities are difficult to understand, as they have an unclear scope. An Activity contains a private, activity-specific repository of certain but not all sources of config and state data. Because it does not encompass all settings and all state, figuring out what parts of the shell and user apps are Activity-aware is a guessing game. For the apps that do support it, support must be specifically added, which in practice means that only a very small number of apps will ever be Activity-aware, so means the system cannot work generically. Most users use more than just Activity-aware KDE apps. The more this is true, the less Activities work or make sense.
# It makes everything it touches buggier
Activities contribute to a combinatorial explosion of options that makes bugs easy to encounter and difficult to triage, especially for things that *are* Activity-aware, such as desktop containments and panels. Users who use Activities can and do suffer loss of data or important state.
# It isn't maintained
The feature seems to be effectively abandoned. I have not seen any substantive work to fix bugs, add new features, or add support for additional apps during the 5 years I have been involved in KDE. Most KDE developers don't use it, aren't familiar with its code, and avoid bug reports about it. The feature is slowly bit-rotting.
---
With the above in mind, I think Activities' disadvantages outweigh its advantages and we should deprecate it and begin porting away from it, with the goal of removing it in Plasma 6. Features can be migrated back to Virtual Desktops as needed--for example [per-virtual-desktop wallpapers](https://bugs.kde.org/show_bug.cgi?id=341143).https://invent.kde.org/plasma/plasma-mobile/-/issues/171Add option to turn of touchscreen (or partially) while screen is on2023-07-16T09:40:17ZIvan RancicAdd option to turn of touchscreen (or partially) while screen is onSo, the idea is to use the phone as a digital quick reference source. One can open a quick reference (cheatsheet), turn off touchscreen and turn on caffeine mode (screen always on). The reason why touchscreen-off option is needed is beca...So, the idea is to use the phone as a digital quick reference source. One can open a quick reference (cheatsheet), turn off touchscreen and turn on caffeine mode (screen always on). The reason why touchscreen-off option is needed is because I'd like to be able to slip my phone into my pocket but not messing up what's present on the screen. Even turning off, say, 90% of the touchscreen would probably do the job (leaving 10% for button/s to turn the screen back on or extras).
Given that one would probably have more than one cheatsheet, it would be nice to have an option to scroll through them quickly (perhaps again by not turning off the entire touch surface and adding some buttons on the sides).https://invent.kde.org/plasma/plasma-mobile/-/issues/168Low framerate when networkmanager connecting to a network2024-01-29T21:00:23ZHennadii ChernyshchykLow framerate when networkmanager connecting to a networkWhen connecting to a network (Wifi or GSM), the idle animation is played in the status bar. When it's active, `kwin_wayland` actively consumes the CPU.When connecting to a network (Wifi or GSM), the idle animation is played in the status bar. When it's active, `kwin_wayland` actively consumes the CPU.https://invent.kde.org/plasma/kwin/-/issues/78Handling tiled outputs and cloning on Wayland2023-02-21T19:17:12ZXaver HuglHandling tiled outputs and cloning on WaylandTiled outputs are outputs where the display is split into two or more sections that are driven by separate display controllers, and need to be driven as separate connectors with separate crtcs from our side as well. Effectively we have t...Tiled outputs are outputs where the display is split into two or more sections that are driven by separate display controllers, and need to be driven as separate connectors with separate crtcs from our side as well. Effectively we have two options for handling these:
1. create one surface per connector, render to every surface separately and present them with once IOCTL for synchronization. Ignoring multi-view extensions, this is very inefficient, but is guaranteed to work
2. create one big surface that spans some or all connectors of the output, and render and present it all in one go. !1174 assumed this would always work with tiled outputs designed for it, but that's not necessarily the case. When it works though it is vastly more efficient than (1)
If one creates a "simulated" tiled output by combining multiple normal outputs, there is also the complexity of possibly having multiple different refresh rates on a single logical output. As that is a niche of a niche of a niche I think we can ignore that use-case though and just render at the highest refresh rate available.
For cloned outputs there are more possibilities:
1. create one surface per connector and render to each surface separately, like for tiled outputs. This is what we're doing now and while incredibly inefficient, it has its use-cases: The outputs could have different color spaces and different refresh rates, which should or potentially need to be driven with those different refresh rates as well
2. create one surface, render to that and then blit to the actual output surfaces, possibly also with color space conversions, and present them all with one IOCTL. This is more efficient than (1)
3. create one surface that can be scanned out on all the connectors, render to that and present it on all outputs with one IOCTL. This is a lot more efficient than (2)
4. create one surface that can be scanned out with one crtc and use that crtc to drive all relevant connectors (obvs also with one IOCTL). This is nearly as efficient as if you'd only be using one monitor
2-4 can be handled as one case from the `Compositor` side, the drm backend can handle it transparently.
For both of these I think that the backend should provide `Compositor` with a list of surfaces to render to. This doesn't *necessarily* need to make the primary plane(s) a special case, cursor & overlay planes will also need positioning limitations (for hw that's weird with cursors, and for overlays on tiled outputs in general) and I think that could be sort of generalized to the bottom planes as well.6https://invent.kde.org/plasma/plasma-mobile/-/issues/162Add search option to file picker2022-02-13T22:36:57ZIvan RancicAdd search option to file pickerWhen there are many files within a folder it becomes hard to find a specific file without search option.When there are many files within a folder it becomes hard to find a specific file without search option.https://invent.kde.org/plasma/plasma-mobile/-/issues/153[taskpanel] Add option of an always visible bottom panel with task manager/dock2022-02-04T12:42:21ZIvan Rancic[taskpanel] Add option of an always visible bottom panel with task manager/dockSo basically very much like on Plasma desktop. Ability to pin apps, an option to set maximum amount of icons that can populate the bar but also an option (just like with task manager) for task manager entries to become progressively narr...So basically very much like on Plasma desktop. Ability to pin apps, an option to set maximum amount of icons that can populate the bar but also an option (just like with task manager) for task manager entries to become progressively narrower in order to accommodate more apps. Maybe even an option for two rows (again, as in task manager on Plasma desktop)? Maybe make the panel scrollable/draggable to the left/right so that unpinned (but open) apps that don't fit into visible width are still reachable through that task manager.
Given that many people use only few apps, one could pin those most important and it would greatly ease up switching between those. If there are more open apps than can practically fit into panel, they can all always be found in the already present app switcher.https://invent.kde.org/plasma/kwin/-/issues/77Rethink quick tile implementation2022-08-01T13:57:11ZVlad ZahorodniiRethink quick tile implementationThe current implementation of quick tile mode and maximize mode is quite tricky and easy to break, which is a sign that we might be doing something wrong. It's worth exploring whether both features can be merged or whether quick tiling c...The current implementation of quick tile mode and maximize mode is quite tricky and easy to break, which is a sign that we might be doing something wrong. It's worth exploring whether both features can be merged or whether quick tiling can replace maximize mode.https://invent.kde.org/plasma/plasma-mobile/-/issues/151Lockscreeen performance issue2022-02-01T19:45:52ZHennadii ChernyshchykLockscreeen performance issueHi! I use Plasma Mobile 5.23 on PinePhone and after pressing power button lockscreen shows with ~2 seconds delay. This is very annoying because sometimes I think I didn't press the power button, I press it again and the screen is locked....Hi! I use Plasma Mobile 5.23 on PinePhone and after pressing power button lockscreen shows with ~2 seconds delay. This is very annoying because sometimes I think I didn't press the power button, I press it again and the screen is locked. Is it possible to optimize lockscreen show-up? On Phosh it displays instant.https://invent.kde.org/plasma/plasma-nano/-/issues/4org.kde.plasma.nano.desktoptoolbox.appdata.xml unkown tag "stock"2022-01-22T16:36:40ZOnuralp SEZERorg.kde.plasma.nano.desktoptoolbox.appdata.xml unkown tag "stock"Hello, I'm a fedora packager and I'm trying to package plasma-nano but after "build" process complete
I got a "appdata.xml" with unknown tag "<icon type="stock">plasma</icon>" and when I check via
appstream-util validate-relax --nonet...Hello, I'm a fedora packager and I'm trying to package plasma-nano but after "build" process complete
I got a "appdata.xml" with unknown tag "<icon type="stock">plasma</icon>" and when I check via
appstream-util validate-relax --nonet %{buildroot}%{_kf5_metainfodir}/%{kde_name}.desktoptoolbox.appdata.xml
It fails, I did a "sed" trick in order to pass the "check" section in my spec file, but I couldn't find where is that come from. So is there any way to fix in it or Where it may be ?
Thank you.https://invent.kde.org/plasma/wacomtablet/-/issues/1Express buttons instantly being released2022-01-21T21:43:26Z... ShaiBlizzardExpress buttons instantly being releasedAs of now, every key input besides the built in 4 builtin keys (ctrl,alt,meta,shift) are seen by xsetwacom as +key -key, so you are unable to hold them down.
Suggestion: either add a toggle that would let you toggle keys between the cur...As of now, every key input besides the built in 4 builtin keys (ctrl,alt,meta,shift) are seen by xsetwacom as +key -key, so you are unable to hold them down.
Suggestion: either add a toggle that would let you toggle keys between the current [+key -key] and [+key], or add an option to globally make every key be seen by xsetwacom as +keyhttps://invent.kde.org/plasma/plasma-nano/-/issues/3Improve readme2023-10-31T12:51:43ZSum GaiImprove readmePlease update the readme to include a description of what is included in `plasma-nano` and what sets it apart from the standard Plasma shell environment. An additional section with build and install instructions would also be appreciated.Please update the readme to include a description of what is included in `plasma-nano` and what sets it apart from the standard Plasma shell environment. An additional section with build and install instructions would also be appreciated.Joshua Goinsjosh@redstrate.comJoshua Goinsjosh@redstrate.comhttps://invent.kde.org/plasma/plasma-mobile/-/issues/147[widgets/notifications] Implement popup notifications2024-03-21T18:21:26ZDevin Lin[widgets/notifications] Implement popup notificationsThe last major thing to implement with the notifications widget are "popup" notifications, which are currently still provided by the desktop notification plasmoid. This would then allow us to remove the desktop notification plasmoid enti...The last major thing to implement with the notifications widget are "popup" notifications, which are currently still provided by the desktop notification plasmoid. This would then allow us to remove the desktop notification plasmoid entirely from the panel containment, reducing memory usage of the shell.6.1Yari Pollaskilvingr@gmail.comYari Pollaskilvingr@gmail.comhttps://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/145Out of box experience2022-09-14T14:22:41ZDevin LinOut of box experienceWe can have a first-run wizard built into the shell to configure aspects like appearance, wifi, etc. Integration into the shell allows us to also provide a small tutorial for users on how to use it.We can have a first-run wizard built into the shell to configure aspects like appearance, wifi, etc. Integration into the shell allows us to also provide a small tutorial for users on how to use it.https://invent.kde.org/plasma/plasma-mobile/-/issues/144Shell keyboard shortcuts2022-01-17T20:17:28ZDevin LinShell keyboard shortcutsWe should have a set of keyboard shortcuts in order to trigger different parts of the shell (ex. open action drawer). Phosh even has shortcuts to switch apps between screens.
Requires https://invent.kde.org/plasma/plasma-phone-component...We should have a set of keyboard shortcuts in order to trigger different parts of the shell (ex. open action drawer). Phosh even has shortcuts to switch apps between screens.
Requires https://invent.kde.org/plasma/plasma-phone-components/-/issues/146https://invent.kde.org/plasma/qqc2-breeze-style/-/issues/21Text handles get covered by Maliit keyboard2022-02-03T20:18:27ZBrian AbertsText handles get covered by Maliit keyboardText box handles will get covered by the Maliit keyboard in Plasma Mobile rendering them essentially useless. Android shows the handles above the virtual keyboard.
Moved from [here](https://invent.kde.org/frameworks/kirigami/-/issues/12)Text box handles will get covered by the Maliit keyboard in Plasma Mobile rendering them essentially useless. Android shows the handles above the virtual keyboard.
Moved from [here](https://invent.kde.org/frameworks/kirigami/-/issues/12)