navigationPanelThickness is explicitly 0 in convergence mode, so using
it as the layer-shell surface height triggered a Wayland protocol error
and crashed the shell. Use gridUnit * 3 directly, matching the dock bar
height set on FavouritesBar.
NavigationPanel: the taskStrip ListView checked contentWidth > width
to decide whether scrolling is enabled, which is wrong when the
panel is vertical. Check contentHeight > height in that case.
taskpanel: dockSpaceReserver used a hardcoded gridUnit * 3 for both
height and exclusionZone. Use navigationPanelHeight so the reserved
strip tracks the actual panel thickness.
Dock and space reserver hid unconditionally on maximize.
Gate both on autoHidePanelsEnabled. Make the exclusive zone
constant — dynamic changes on a contentless surface never
get committed to the compositor.
Slide the dock off-screen when WindowMaximizedTracker reports a
maximized window, and bring it back on mouse proximity via a
HoverHandler. The dockSpaceReserver exclusion zone drops to 0 so
KWin gives the full screen to the maximized window.
Animation follows the StatusBarWrapper pattern: offset property,
Translate transform, Behavior with InExpo/OutExpo easing.
Add an invisible layer-shell surface with an exclusive zone matching
the dock height. KWin uses this to shrink MaximizeArea so maximized
and tiled windows no longer overlap the dock.
The previous approach of tweaking the nav-panel PanelView was a dead
end: PanelView resets its own surface properties on reconfiguration
and Wayland offers no way to set struts from a KWin script. A
separate surface at LayerBottom with exclusionZone is the intended
protocol mechanism.
The task panel window reserved bottom-edge screen space even
with zero thickness and invisible content. Set its visibility
mode to auto-hide in convergence and force the dock bottom
margin to zero so the favourites bar sits flush at the screen
edge.
Load the button-based NavigationPanel when convergence mode is
enabled, regardless of the gesture panel preference. Gesture-only
navigation is incompatible with mouse and keyboard input.
This adds a gesture handle mode to the navigation panel, which can be
enabled during gesture-only mode. This reserves space for the system
gesture to be able to be used, allowing us to extend the height in KWin
of the gesture recognition area (which is currently far too short for devices such as Pixel 3a).
This also allows for navigation with a mouse; clicking on the handle
triggers the task switcher, holding it triggers the "home" action.
The startup feedback uses theme adjusted colors, we can use standard
foreground colors for the panels for better contrast rather than relying
on the shadow.
This adds support for specifying options needed to deal with phone
display panel pecularities (ex. screen curves, notches, punch holes)
This is implemented as settings in ~/.config/plasmamobilerc, which can
set panel heights, paddings, and center spacings to duck display
cutouts. The pixel values are scaling independent, and so are not
affected when the display scaling is changed.
This is then exposed over DBus, so that components from outside of
plasmashell (ex. KWin) can access it easily without needing to connect to
kscreen themselves. Each screen is exposed as a single object.
Currently support is only added in the status bar and the navigation
panel.
Currently all screens have the settings applied. In the future, we may
want to limit this just to the internal screen (?)
---
This also adds a "devices" folder (in `devices/configs`) where per-device configs can be set.
This is installed to `/usr/share/plasma-mobile-device-configs`.
In `plasmamobilerc` (installed to `/etc/xdg/plasmamobilerc`, or
`~/.config/plasmamobilerc`), envmanager will read:
```toml
[Device]
device=oneplus-enchilada
```
for the device config to use and write its settings to
`~/.config/plasma-mobile/plasmamobilerc`.
A custom 0.95 opacity was added to the panels in
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/642 for
overlaying applications. This
required some complicated logic and layering to mix with other modes of
operation. Since this broke at some point, simplify the logic completely
so that it's just a flat colour. This also fixes the navigation panel
not having a colour when the keyboard is shown over the homescreen.
The virtual keyboard can be active but not visible. We want to use the
visibile property when determining whether there is a keyboard visually
showing.
Overlay the shell's status panel and quicksettings panel over the lockscreen, instead of rendering a second copy in the lockscreen theme. This will allow us to improve the lockscreen loading speed.
Key changes:
- Overlay quicksettings window and the status bar over the lockscreen when it is shown
- Refactor the top panel's showing logic to be cleaner (as it supports various overlay modes over fullscreen apps already)
- Implement lockscreen support to the status bar and quicksettings panel in the to panel
- Forward quicksettings panel requests for "unlock" over DBus to the lockscreen
- Add "raiselockscreen" QML plugin to easily request a window to be raised over the lockscreen
Notes:
- Now that we are sharing the quicksettings panel from the shell, notifications that are already there will be shown on the lockscreen (compared to right now, where only new notifications would be shown)
Depends on:
- https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2339
- https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/283
- https://invent.kde.org/plasma/kwin/-/merge_requests/7839
Implements: https://invent.kde.org/plasma/plasma-mobile/-/issues/199
Use plasma_add_applet to deploy the applets as a module: https://invent.kde.org/plasma/libplasma/-/merge_requests/1116
We eventually need to do this for Halcyon and Folio homescreens too, but
they also have a bunch of C++ classes to be ported to declarative type
registration.
2025-06-26 20:46:48 -04:00
Renamed from containments/taskpanel/package/contents/ui/main.qml (Browse further)
