Development/Tutorials/Plasma5/ThemePortingToPlasma5: Difference between revisions

From KDE TechBase
(Add note about analog clock)
(Add note about [BlurBehindEffect])
Line 58: Line 58:
* add shadow elements & hints to the SVGs of '''dialogs/background''', '''widgets/panel-background''', '''widgets/tooltip''' (see [[Development/Tutorials/Plasma5/ThemeDetails|Details]])
* add shadow elements & hints to the SVGs of '''dialogs/background''', '''widgets/panel-background''', '''widgets/tooltip''' (see [[Development/Tutorials/Plasma5/ThemeDetails|Details]])


== BlurBehind (panels, tooltips, dialogs) ==
If KWin, the window manager, is set to do compositing, by default now for any window-like views the visual content behind the view will be blurred, if the KWin BlurBehind effect is enabled (default), using the mask of the painted view. For panels until Plasma 5.16 not the mask, but the full rect is used though, resulting in artifacts for non-full-rect panel shape themes.
As the BlurBehind effect also is applied for non-Plasma windows, users might want to have the effect enabled for non-Plasma windows in any case.
Changes to do:
* if no BlurBehind is wanted or needed for the theme (e.g. with full opaque themes), add to the metadata.desktop file a group "[BlurBehindEffect]" with an entry "enabled=false" (available for Plasma >= 5.16)


== Borders and content margins (panels, tooltips, dialogs) ==
== Borders and content margins (panels, tooltips, dialogs) ==

Revision as of 11:16, 12 April 2019

While the basic format of Plasma themes has not changed since the first version of Plasma, by the time in Plasma 5 some backward-incompatible changes happened for the range of elements expected in the themes. Here is a list of the changes, please supplement if changes are missing.


KRunner

dialogs/krunner is no longer used by KRunner, instead dialogs/background is applied.

Changes to do:

  • remove dialogs/krunner SVGs

Logout/Shutdown dialog

dialogs/shutdowndialog is no longer used. Instead the the implementation of "logoutmainscript" of the active Plasma LookAndFeel package defines the look of that dialog, with the default Breeze implementation not using any special theme elements.

Changes to do:

  • remove dialogs/shutdowndialog SVGs

Panel background

The "*-mini-*" variants from the widgets/panel-background SVGs are no longer applied, instead always the normal "[prefix-]*" elements are used.

Changes to do:

  • remove all "*-mini-*" variants
  • ensure all the "[prefix-]*" elements include the potential borders (e.g. the "north-*" ones have the "*left*", "*bottom*" & "*right*" ones)

(often simply renaming the "*-mini-*" variants to their non-mini counterparts and removing the old ones before is all to do)

Analog clock

The rotation center of a hand (shadow) element now defaults to its "(width/2,width/2)" point from the top-left of the element, no longer is the the y-axis position of the elements with respect to the center of ClockFace taken into account. Since Plasma 5.16 the hints "hint-[hand(shadow)]-rotation-center-offset" (with "[hand(shadow)]" being "hourhand", "hourhandshadow", "minutehand", "minutehandshadow", "secondhand", "secondhandshadow") allow to define a custom relative point (can also be outside the element).

Also has the hard-coded relative offset of the optional shadow elements for the hands been changed a few times. Since Plasma 5.16 it defaults to (0,0) and can be overwritten by the "hint-hands-shadow-offset-to-west/hint-hands-shadows-offset-to-east" and "hint-hands-shadow-offset-to-north/hint-hands-shadow-offset-to-south" hints.


Changes to do:

  • if the default "(width/2,width/2)" relative rotation center point of a hand does not match: either add transparent padding area to the hand as needed or, recommended for Plasma >= 5.16, define a "hint-[hand(shadow)]-rotation-center-offset" element, e.g. by adding a circle whose center marks the relative rotation center
  • if there are shadows elements and the default (0,0) offset does not match the theme's light model: define ""hint-hands-shadow-offset-to-*" elements for the shadow offset

Notes

The notes applet no longer uses the complete widgets/notes SVG file as shape for a note. Instead it expects 10 elements in the widgets/notes SVG, one note shape element with name "[color]-notes" per each supported color: "white", "black", "red", "orange", "yellow", "green", "blue", "pink", "translucent", "translucent-light".

Changes to do:

  • name the existing shape with a name for a matching color
  • add 9 more variants for all the missing colors

Extender

The widgets/extender-background SVG is no longer used.

Changes to do:

  • remove widgets/extender-background SVGs

Shadows (panels, tooltips, dialogs)

The window/compositing manager no longer automatically adds shadows to windows. But leaves it to the windows to provide shadow pixmaps matching the light model of the current theme.

Changes to do:

  • add shadow elements & hints to the SVGs of dialogs/background, widgets/panel-background, widgets/tooltip (see Details)

BlurBehind (panels, tooltips, dialogs)

If KWin, the window manager, is set to do compositing, by default now for any window-like views the visual content behind the view will be blurred, if the KWin BlurBehind effect is enabled (default), using the mask of the painted view. For panels until Plasma 5.16 not the mask, but the full rect is used though, resulting in artifacts for non-full-rect panel shape themes.

As the BlurBehind effect also is applied for non-Plasma windows, users might want to have the effect enabled for non-Plasma windows in any case.

Changes to do:

  • if no BlurBehind is wanted or needed for the theme (e.g. with full opaque themes), add to the metadata.desktop file a group "[BlurBehindEffect]" with an entry "enabled=false" (available for Plasma >= 5.16)

Borders and content margins (panels, tooltips, dialogs)

Plasma code now has the assumption that the value of the full width of the border element (or the "[prefix]-hint-[direction]-margin" override) can also be interpreted as content margin when the border is not enabled. So effectively assuming that visual border itself is almost of 0 width, and the margin is just that, the margin between edge and content. This was done to simplify the code when any window-like elements where shown bounded to a screen edge, where then the related border would be disabled (which again would mean another window size if turning off the border would affect the window size).

On the sides where the border is disabled, the content then gets a padding with a value of the border element width (or "[prefix]-hint-[direction]-margin" override) over the center element.

Changes to do:

  • make sure the visual borders of frames are as slim as possible, so that the full border element width works also as content margin value when the border element itself is not used (consider also use of "[prefix]-hint-[direction]-margin"), e.g. for dialogs/background, widgets/panel-background, widgets/tooltip