other_stuff.h | [was: Review Request for KDecoration]

[Martin Gräßlin]

On Tuesday 11 November 2014 17:00:24 Thomas Lübking wrote:
> On Dienstag, 11. November 2014 14:43:56 CEST, Martin Gräßlin wrote:
> >> "BorderSize" - do we *really* want to keep this or rather allow
> >> pixel/pointwise configuration of 2,3, or 4 border sizes globally?
> > 
> > could you please explain your alternative approach? I'm kind of
> > not getting it and yes I'm also unsure about providing the BorderSize
> > enum,
> > but I want to ensure that Decoration plugins provide large borders for
> > accessibility.
> 
> Well "ensure" is a problem in any case, but what I meant was a global
> setting for left, right, top & bottom border widths (in pixels or points,
> latter translated to pixels by the core) Eventually group this to
> "vertical" and "horizontal" border widths or "vertical", "top" and "bottom"
> Eventually also titlebar oriented (ie. you've the titlebar, its counter
> side and the orthogonals)
> 
> The user would say: "I want 0pt extra border on the titlebar, 4pt on the
> counter side (usually bottom) and 1pt on the orthogonal ("left & right")
> edges.
> 
> The core then makes a decoration with such padding and either the deco
> plugin reasonably paints for this sizes or it will cause artifacts.
> 
> This is to address bugs where ppl. complained that there's no reasonable
> decoration size - either they're unusably small or ridiculously huge.
> 
> Also decos do not get a chance to interpret "huge" and "small" with their
> own idea of their meanings. The user will get the same paddings for every
> decoration.

suggestion: we keep the BorderSizes enum and do not enforce a specific size (I 
imagine theme engines to have a problem with it, at least Aurorae could have), 
but add a

int DecorationSettings::recommendedBorderSize() const

which gets the logic from breeze decoration. And it would probably need 
something like
bool DecorationSettings::sideBorders() const

which would be false for NoSideBorders and NoBorders otherwise true.

That way all Decorations which use the recommendedBorderSize() would have the 
same configured (sane) size. If a decoration doesn't use it and it provides 
bad useability: well then the user should report a bug against it ;-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141111/c6b94a05/attachment.sig>