[Konsole-devel] [Bug 198175] Konsole should set blur region for the new kwin effect

[Eike Hein]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #34 from Eike Hein <hein at kde.org> ---
I don't think it makes sense to duplicate the blur settings in every app,
especially if they naturally go hand in hand with the profile system (i.e. you
usually want blur, except for that one app you use where you know you need to
read what's below it, so you define a profile starting it that doesn't use
blur). It's also not really economical to force apps to do lifting that can be
done once in Konsole.

Plus profiles are shared between Konsole and KPart-using apps, so it's a
convenient way to share the blur settings, too.


> Also there are skins for yakuake that have transparent borders, etc and they also not blurred so it probably should be considered like a Yakuake bug.

It's not a Yakuake bug that translucent skin areas are currently not blurred,
since it's not the result of any wrongdoing on Yakuake's part. Blur is opt-in
and hence an additional feature.

I develop Yakuake, and the reason that there's no such feature yet is because
Konsole doesn't have blur going yet, and it doesn't make much aesthetic sense
to blur the skin but not the terminal. As soon as blurring is worked out in
Konsole, Yakuake's skin engine will get blur support, too.


> and then one option could be added to Konsole KPart pluggin to supress bluring under it (if that's possible of course).

An option to disable blurring is basically the same as an option to enable
blurring, except even more work: Not only do you need to update the blur region
in all of the scenarios mentioned above, you also need to actively fight
anything that might be setting it differently. That way definitely lies
madness.


No, really, the only correct way to implement this is to stick code managing
the blur region in a cooperative fashion with whatever else is modifying the
blur region into Konsole's TerminalDisplay widget class, and add a profile
option to enable/disable it.

It also only sounds like much work, someone who knows what they're doing can
still code up and debug it in 1-2 hours. It's just that the patches written so
far were much quicker affairs since their authors were evidently satisfied with
implementations that don't achieve production quality.

-- 
You are receiving this mail because:
You are the assignee for the bug.