RFC: Additional hint elements for frame theme SVGs

Eike Hein hein at kde.org
Thu Apr 24 23:40:11 UTC 2014


Hi,

I think we have a conceptual problem in the theming system that needs
addressing, specifically related to frame elements that can have borders
partially clipped away, such as dialogs and panels.

Let's recap the current state of things: Frame SVGs are so-called nine-
patches, i.e. there's an element for the center, one for every corner,
and one for every edge.

A dialog will usually draw all of these elements, and the dialog content
goes into the grid cell filled with the center element, filling it.

When the dialog bumps up against a screen edge, the border row/column
on that side gets disabled.

Now we need to consider how themes tend to distribute the visual over
the nine-cell grid. Many themes have rounded corners, which means the
size of the corner cells must be large enough to fit the curve of the
corner. This causes all of the border rows/columns to be of a certain
width.

Both the rounded corners, and the fact that many themes like to have a
visually strongly defined border (i.e. a visible, contrasting outline
of some kind) means the sides of the center rectangle are usually a
small distance from what an onlooker visually perceives as the inside
edge of the dialog. In other words, there is a margin between the con-
tent and the inside edge of the dialog.

When a border row/column gets disabled, this margin disappears,
causing a visually uneven/asymmetrical result. Content appears not
centered, with different margins between content and opposing inside
edges (one of them now a screen edge). This is a problem for dialogs
spawned from panels, and for the panel itself. The latter especially
often causes grief and unhappy feedback from users and designers.

Right now, many applets try to hack around this by adding their own
inside margins depending on how they're used and their position. This
is doomed to fail however (I know, I tried in Plasma 1), because:

- The location enum doesn't provide enough information, specifically
  it has no notion of when something is in a corner, and popup applets
  can't access the margins prop for the popup dialog.

- Much more importantly, the applet can't actually know what margin
  is correct, because it doesn't know anything about the design of
  the theme. This is a critical point: The width of the border row
  or column as the distance to the visually perceived inside edge,
  because this depends on the specifics of the design. In a theme
  that implements an outline design (e.g. say a 2px pink border or
  whatever), the perceived inside edge is where that outline begins.

So, how do we fix this?

A naive approach would be to disable the border row/column just as
we do now, but then extend the center rectangle by the same width
as the border would normally be, and then apply an inside margin
between the edge of the center rectangle and the edge of the content
equal to that width as well.

This doesn't actually fix the problem however because again, the
visually perceived inside edge isn't equal to the width of the
whole border element.

To really address this, we thus need to allow theme authors to pro-
vide another set of hint elements in their SVGs that specify a
width to use for that center rect edge <-> content edge margin on
edges with disabled borders.

Other hint elements already exist: Theme authors can specify a
set of width hints that substitute for the actual widths of the
border elements - but these substitutes aren't used when a border
is disabled.

So, bottom line: Four new hints and code to make use of them are
needed IMHO. This would finally unfuck a lot of bad asymmetry and
hacks in panels, panel popups and the like. Thoughts?


Cheers,
Eike








More information about the Plasma-devel mailing list