Development/Tutorials/Plasma5/ThemePortingToPlasma5: Difference between revisions
(add note about shadows) |
(add note about borders & content margins) |
||
Line 46: | Line 46: | ||
Changes to do: | Changes to do: | ||
* 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]]) | ||
== 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''' |
Revision as of 13:26, 11 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)
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)
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