Bug 198175

hmm I added support for it. It just does not blur as much as kwin can't know how strong the opacity is. In case of manual setting of opacity kwin does know it so the correct amount of blurring is applied.

Nevertheless: blur effect has been removed in KDE 4.3 due to many problems and that makes this bug report unfortunately invalid. We hope to provide a better blur with 4.4

Be interesting to see how the Compiz developers handle the situation. Presumably they would face the same problem.

Thank you very much for the prompt response :)

Guys, I hate necroposting, but I have to report that this one is confirmed in KDE SC 4.5 Beta 1, with the brand new blur plugin.

suffers from the same problem as bug #238141 - the window needs to set the to-be-blurrend region

Can you reopen this and assign this against Konsole? Konsole needs to set its region to be blurred, so, it isn't a KWin bug anymore.

*** Bug 243214 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

Created attachment 49406 [details]
blur patch

this patch does the job (for kde4.5).
There might be more elegant solutions. but as far as I could test, this works just fine.

> this patch does the job (for kde4.5).
> There might be more elegant solutions. but as far as I could test, this
> works just fine.
Please do *not* commit a patch like this one for 4.5! This would break 
translucent Konsole for everybody who wants it. To me not blurring Konsole is 
a feature and not a bug!

Please discuss this properly on how to use. Konsole is a KPart and it does not 
make sense to set blur region on the KPart when embedding it in Kate/KDevelop. 
On the other hand it is not sufficient for Yakuake as it has to blur more.

I discussed this once with Eike Hein and we agreed that there is no easy way 
for 4.5 (there's somewhere a transcript of IRC chat on Konsole mailinglist)

@martin
Clear enough :)
wasn't planning to commit anyway: was just a suggestion. konsole (and kwin) 
devs would definitely know better.

Afaics it should be sufficient to check for a WA_TranslucentBackground 
attributed toplevel window, yesno? (Works here, konsole is "autoblurred" from 
bespin, kate not even translucent)

Yakuake would probably have to override the area once more (and this is the 
main conflict - we'd need an "_NET_I_KNOW_BETTER flag to ensure applications 
can override this, but this would sooner or later break with 
bespin/oxygen/qtcurve blurring support... =\

Thomas

Am Thursday 22 July 2010 schrieb Martin Gräßlin:
> https://bugs.kde.org/show_bug.cgi?id=198175
> 
> 
> 
> 
> 
> --- Comment #9 from Martin Gräßlin <kde martin-graesslin com>  2010-07-22
> 20:05:02 ---
> 
> > this patch does the job (for kde4.5).
> > There might be more elegant solutions. but as far as I could test, this
> > works just fine.
> 
> Please do *not* commit a patch like this one for 4.5! This would break
> translucent Konsole for everybody who wants it. To me not blurring Konsole
> is a feature and not a bug!
> 
> Please discuss this properly on how to use. Konsole is a KPart and it does
> not make sense to set blur region on the KPart when embedding it in
> Kate/KDevelop. On the other hand it is not sufficient for Yakuake as it
> has to blur more.
> 
> I discussed this once with Eike Hein and we agreed that there is no easy
> way for 4.5 (there's somewhere a transcript of IRC chat on Konsole
> mailinglist)

@Thomas
I think the idea of the bug report was to be able to enable blur behind even when using a widget style that does not support translucency (since konsole supports it no matter what). Say, Windows 9x :D

But then yeah, for styles that do support it, basically you end up with the same conflict as with yakuake ...

> --- Comment #12 from Hugo Pereira Da Costa <hugo pereira free fr> 
> 2010-07-22 22:25:27 --- @Thomas
> I think the idea of the bug report was to be able to enable blur behind
> even when using a widget style that does not support translucency

What i meant was "have Terminalidget check wether
::window()->testAttribute(Qt::WA_TranslucentBackground)
before applying the blur region (+ afaics konsole parts like in kate aren't 
translucent anyway - so i don't see that much of a problem to add this - 
except for not blurring konsole because of performance issues...)

Still no blurred konsole window even with the new introduced blurr effect in KDE 4.5

We're at kde 4.7.1, is that difficoult to blur konsole background?

On Thursday 08 September 2011 16:11:42 Antonio Orefice wrote:
> We're at kde 4.7.1, is that difficoult to blur konsole background?
yes it's non-trivial and a complex task to do it correctly. Btw. the minor version does not matter. That's clearly a 
feature which could only be introduced in a major version (e.g. 4.8.0)

Sadly, but konsole is not blurred in 4.8 betas

Try:
xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0

in your konsole, klick on your konsole and enjoy a blurred background

Martin: It works! I only need to run that command in the background and restart Konsole.

Correcting myself: no. When I run that command, cursor turns into a crosshair. I click on the Konsole background, and it blurs.

(In reply to comment #18)
Yes, it works but not useful as described in comment #20.

You mean like "not convenient" or like "not useful, because ..."

If you just wanted to look for an automatic way (but asked instead)

xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION
0 -id `qdbus org.kde.konsole /konsole/MainWindow_1 winId`
(be aware of the linebreaks whe c'n'p)

check the dbus interface to figure the amount of possible windows, there's also a way to automize random commands when launching konsole/sessions

Hi, yes, I meant that this is not very convenient. I also using yakuake and this command doesn't have any effect for it. But even in case with konsole, blur disappears after the app restart and raises an error if I will try to run it when konsole is not running (Service 'org.kde.konsole' does not exist.).

I don't really know how kwin works and does all its cool things, but just wondering if there is a way to detect the transparent regions automatically? This would be much more correct and if there is applications which want to have some transparent and not blurred regions then they will be need to specify these regions (like we do now to enable the blur). This approach will resolve many similar issues (also yakuake, bespin, etc)

> Hi, yes, I meant that this is not very convenient. I also using yakuake 
and
> this command doesn't have any effect for it.
You know that I tried it first with Yakuake, because I prefer that one ;-) It 
works there, too.
> I don't really know how kwin works and does all its cool things, but just
> wondering if there is a way to detect the transparent regions 
automatically?
No the applications have to tell us what is transparent. And that is in 
case of Konsole unfortunately a non trivial task. We can of course 
recognize that the window is translucent but does that mean it has to be 
blurred? IMHO no. I would consider a blurred Konsole a bug and not a 
feature and there are probably many other applications which want 
translucency without blurring.

As I am currently working on KWin scripting I'll try to add some hooks to 
define a KWin script to set the blur regions.

(In reply to comment #24)
> > Hi, yes, I meant that this is not very convenient. I also using yakuake 
> > and this command doesn't have any effect for it.
> You know that I tried it first with Yakuake, because I prefer that one ;-) It 
> works there, too.

I think he means my suggest.

@Alexander
I'm quite sure that if you take a very close look on that string, you'll be able to modify it for yakuake. Trust me, works (i actually tested it for yakuake and mapped it to konsole)

> blurred? IMHO no. I would consider a blurred Konsole a bug and not a 
> feature and there are probably many other applications which want 
> translucency without blurring.
Sounds to me like you and Alexander are asking konsole/yakuake to add a switch for blurring.

@Alexander
please consider that it /can/ be very valuable to have a shell on top and still be able to *read* whaetver is below - this isn't much about eye-candy and a shell is more the pro-kind-of-thing anyway

> @Alexander
> please consider that it /can/ be very valuable to have a shell on top and
> still be able to *read* whaetver is below - this isn't much about eye-candy
> and a shell is more the pro-kind-of-thing anyway

I agree, but I'd like to point out, that blurred transparent konsole/yakuake is far more readable than unblurred. Therefore, if anybody turns transparency on, they wil end up with very low level of transparency (~ 5%) so whatever below the terminal is virtually unreadable and not disturbing. IMHO - why don' t provide a tool (checkbox) to enable/disable blur and let the user to decide himself about it?

(In reply to comment #26)
Absolutelly agree, checkbox to enable blur will solve all problems.

See, that's the thing: A checkbox is indeed required, but nobody has written a patch that implements one yet, that's why there is no blur support so far.

Thats sad, but I am a ruby programmer and can't help with C/C++. Can somebody please implement that? As I understand it shouldn't be too hard to do. Also there is a patch from Hugo (which probably could be modified to check configuration before enable the blur).

Hugo's patch is incomplete for other reasons I mentioned in a ReviewBoard thread once, but apparently not here, so I'll repeat them so they are not forgotten:

The blur region is a per-window atom, but due to the existence of the Konsole KPart component, Konsole terminal widgets can be hosted in application windows other than Konsole's own. That means that when setting the blur region, the Konsole blur code needs to first get the current value of the blur region and merge the update to be done with that current value, since the hosting application may be blurring other parts of its window. Of course, the hosting application also has to do the same on its side.

Further, due to the existence of split support both in Konsole and other apps using its Konsole KPart component (e.g. Yakuake) or the KPart often being used in dock widgets (Dolphin, Kate, KDevelop) the size and position of a terminal within its hosting window can change at any time. That means the blur region also has to be updated on size and position changes of terminal widgets.

Further, both Konsole and applications hosting the KPart implement a tabbed interface, and dock widgets can be closed, etc. So the blur region also has to be updated on show and hide events for terminal widgets.

What existing patches do so far is set the entire "terminal area" in the Konsole main app window to be blurred. This works for Konsole, but not for apps using the KPart component, and it actually stops working even for Konsole as soon as blurring is made a profile option, because then you create the potential for terminals with and without blur co-existing in tab and/or split setups, making the requirements the same as for the KPart.

(To clarify the last paragraph, the requirements are the same except for the "merge with current blur region" part, that is only needed for the KPart case.)

Hmm, regarding to this probably would be much-much more correct if hosting app will setup its blure regions itself, not the KPart plugin. Option for enable/disable blur could be added to each host application configs (if really needed). For example in Dolphin Konsole KPart is not transparent at all (as well as in KDevelop), so blur is not needed here at all.

In short — I think that each app that embeds Konsole KPart (or whatever else, doesn't matter) should take care about the blurred regions itself. So that option could be added to yakuake configuration dialog to disable blur under transparent Konsole KPart area.

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.

This also could be implemented even better. If both Konsole and Yakuake will always set up the blurred regions, without a possibility to disable it (so blur intensivity will only be configurable through the Kwin setting, as usual) and then one option could be added to Konsole KPart pluggin to supress bluring under it (if that's possible of course).

Created attachment 70130 [details]
Konsole KPart config

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.

1. I meant that there will not be any blur settings in each app, you just need to setup the blur region for the whole yakuake window. As I understand from comment #c22 it's quite simple. Also no need to add any configuration controlls to yakuake to change blur settings, simply specify these few constants to set up blurring for the whole window.

2. Add single option to KPart Konsole plugin to supress blur under its area, and that's it.

> 1. I meant that there will not be any blur settings in each app, you just need to setup the blur region for the whole yakuake window.

Setting the blur region for the entire window makes it impossible to have blurring for some terminal profiles but not for others, which isn't optimal (see the aforementioned scenario where you usually want to blur except when you don't).

> Also no need to add any configuration controlls to yakuake to change blur settings.

Sure you do, so users can disable blur if they want to. This is particularly needed for Yakuake because it's designed to be above other things, so an option to single it out is needed by some and just disabling the effect plugin wouldn't do (also I'm privy to plans/desires by the kwin developers to possibly remove helper effects like this from the user-visible effect list).


> 2. Add single option to KPart Konsole plugin to supress blur under its area, and that's it.

This isn't an improvement over the plan I laid out because suppressing blur requires exactly as much work (or more) as possible, and given that there is no gain to be had on the code complexity side, it makes for a hell of an ugly and scary option for non-technical reasons. A "Blur the terminal background" checkbox is a lot more straightforward than having a scary and destructive-sounding verb like "suppress" in there which makes users afraid to use it (do I want that? what will happen if I use it? etc). Friendlyness matters :).

s/as possible/as blurring/ (sorry, dead-tired)

> Hmm, regarding to this probably would be much-much more correct if
> hosting app
> will setup its blure regions itself, not the KPart plugin. Option for
> enable/disable blur could be added to each host application configs
> (if really
> needed). For example in Dolphin Konsole KPart is not transparent at 
> all (as
> well as in KDevelop), so blur is not needed here at all.
This is not correct. In KDevelop it is translucent when using e.g. 
oxygen-transparent widget style. That is if the window is ARGB.

I think there were also plans to default to ARGB visuals for windows in Qt 5, but I don't know if that changed now that upstream no longer really cares about QWidget or X11.

the sane approach would be to have widgets set a tristate or fourstate property "blurme" (-1,0,1,2) or opt. 2 singlestate props (bluryes, blurno) to explicitly opt in or out of blurring done by a single client instance with global sight (qapplication or qstyle)

using the fourstate variant has the charme that widgets intending to change the property at runtime can signal this by explicitly setting the property before polishment, so their events can be explicitly filtered for thy dynamic property change.

we actually wanted similar convention for shadowing undecorated windows, so maybe time for a common style feature convention (4state sf_blur, sf_shadows, ...)?

Created attachment 71789 [details]
automatic blurring

sorry - i didn't know it would immediately pop up like this.
it's not a solution to the problem but simply a convenience-script which will automatically blur all konsoles.

(In reply to comment #41)
> Created attachment 71789 [details]
> automatic blurring

I just added a patch on reviewboard. https://git.reviewboard.kde.org/r/109391/

It's really simple so i hope it gets accepted.

(In reply to comment #43)
> I just added a patch on reviewboard.
> https://git.reviewboard.kde.org/r/109391/
> 
> It's really simple so i hope it gets accepted.
and it shows the same issues any other patch attempt has shown so far. If it were that simple people would have done it already.

after some discussions with eike on irc I came up with this, which I believe is a good compromise, without having to change the WindowEffects class in kdelibs (which is frozen): https://git.reviewboard.kde.org/r/112719/

kwin doesn't seem to respect changes to the blur region, though, and does not seem to care when I unset the xprop either, at least on my system.

(In reply to comment #45)

> kwin doesn't seem to respect changes to the blur region, though, and does
> not seem to care when I unset the xprop either, at least on my system.


   xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c -set _KDE_NET_WM_BLUR_BEHIND_REGION 0

click a window. should now be blurred.

    xprop -remove _KDE_NET_WM_BLUR_BEHIND_REGION

click the window again. should be unblurred.

Notice: regardless of any linebreak in bugzilla, either is only one line.

Also, and that's quite a problem with your patch, some styles like oxygen-transparent do set the blur region as well. This will cross your attempts.

Leaving aside linking libplasma and its dependencies into konsole, the major two problems here have been:
1. blurring can be unwanted depending on the application that carries the konsolepart (though the scheme might be sufficient here)
2. the client needs to aggregate various blurring requests, denies into one region - the plasma function does not provide that since it was probably only meant to blur docks and panels.

See discussion on https://git.reviewboard.kde.org/r/109391/ (no idea what happened to that request)

> See discussion on https://git.reviewboard.kde.org/r/109391/ (no idea what
> happened to that request)

That request - my request - is left there. There doesn't seem to be common ground to implement blur for a console. I see it as a feature and others see it as a bug.. That kinda leaves nowhere to go so i just let it bit rot there.

Here's useful background for sandsmark's patch, which was the result of some discussion on #kde-devel yesterday:

1) It was decided that whether blur should occur or not has to be optional, and that the option should be placed in the profile appearance options with the existing options for translucency and background coloring. This fits the application design and also answers the concern that blur is sometimes desirable and sometimes not, allowing users to set up separate profiles for each and spawn terminals using either as desired.

2) The above implies that the terminal widget has to update the blur region as its geometry (position, size) and visibility changes, since there can be multiple widgets in the window (tabs, splits). The ideal outcome is to assemble the union of all the desired blur regions in the window whenever needed and commit them atomically to the prop. A difficulty here with every widget removing its own blur region and writing its new blur region itself is that you get into ordering problems around overlaps.

3) Since the terminal widget can be embedded into other codebases via the KPart component, it also has to interact with possible blur regions set elsewhere in the window by foreign code, further complicating the above. On top of that, with kdelibs feature-frozen, merging any solution into the libs might not be possible.

4) Martin's results so far seem to indicate that kwin doesn't notice change to the property in realtime.

(In reply to comment #48)

> 4) Martin's results so far seem to indicate that kwin doesn't notice change
> to the property in realtime.

At least for bespin's ARGB/blur implementation (more or less operating on XChangeProperty directly) i got to disagree:
Lowering the global opacity shows that the background of opaque widgets (QTextEdit etc.) is unblurred but switching the tab (showing a plain background) turns the same region blurred.
KWin git master, GL 2.0

Last effective (but rather unrelated) commit:

commit 5d3f405516e1a6c7786d878c30f5490c2b6a484b
Author: Fredrik Höglund <fredrik@kde.org>
Date:   Mon Jun 10 18:51:48 2013 +0200

    kwin/blur: Remove the texcoord attribute

Which is in 4.11


I assume Hugo can confirm that for oxygen-transparent.

=> I assume "mask()" in the patch refers to an atually usable region and not just QWidget::mask() - which is usually just an empty region and will not do anything usable in the plasma implementation?

(In reply to comment #46)
> 1. blurring can be unwanted depending on the application that carries the
> konsolepart (though the scheme might be sufficient here)

Which is why it is optional, off by default, etc., as Eike explained.

> 2. the client needs to aggregate various blurring requests, denies into one
> region - the plasma function does not provide that since it was probably
> only meant to blur docks and panels.

This is not possible with the current API, and as I said, kdelibs is frozen so we can't fix this. The idea I had was to remove the existing "enableBlurBehind" API and add two functions; "addBlurBehind" and "removeBlurBehind" which adds to a static list of regions that are unified before being put into the property.

In the meantime, I believe this gives us a good compromise, especially looking at which apps actually use the konsole kpart.

> => I assume "mask()" in the patch refers to an atually usable region and not just QWidget::mask() - which is usually just an empty region and will not do anything usable in the plasma implementation?

No, I was being stupid. :-P

I changed it to using rect() locally, but KWin still doesn't update the blurred region locally.

(In reply to comment #50)

> This is not possible with the current API
Yes, I know.

> and as I said, kdelibs is frozen
what is irrelevant for the actual problem.

> so we can't fix this. The idea I had was to remove the existing
> "enableBlurBehind" API and add two functions; "addBlurBehind" and
> "removeBlurBehind" which adds to a static list of regions that are unified
> before being put into the property.

Still insufficient, since it can be crossed by other sources.
The feature needs to be moved into some central instance, eg. QWidget/QApplication, a dedicated platform plugin or the style (which effectively is a platform plugin) - otherwise no plain Qt app could make use of this if it has to "fear" that eg. the oxygen-transparent style would still override it - even by this approach.

If you want to add this from a third party, you need a manager, tracking dynamic QWidget properties (set to the blur region) and move/resize events to form a new region and export that at the end of the event cycle.

Since konsole btw. explicitly links X11 libs, you could just  copy over the plasma funtion (so konsole won't suddenly drag in webkit and whatnot)

> In the meantime, I believe this gives us a good compromise, especially
> looking at which apps actually use the konsole kpart.
Not my take ;-)

> I changed it to using rect() locally
like "0,0,width,height" ::rect() or mapped to the window?
You also need to monitor any translation of the widgets geometry relative to the window, ie. when it moves inside its parent or any of its ancestors moves.

suggestion: why not work on frameworks 5 code? How often was now mentioned that a proper fix is not possible because of kdelibs being frozen? It's not true. frameworks is open for improvements and right now would be the time to work on it. Another pro: Konsole would not need to link libplasma as the specific code got moved into KWindowSystem.

Yeah, I suggested that as well, especially since Konsole already has a KF5 port and Yakuake is on the way. The feature's been waiting for two years now, a little longer won't hurt much more.

(In reply to comment #52)
> that a proper fix is not possible because of kdelibs being frozen? It's not
> true. 

As mentioned: actually irrelevant since this has to be added much deeper down if it shall be used generically.

The present function is ok on the application layer and for applications that do not invoke plugins with the least impact on this (ie. adding own blurred items, including the style) - ie. the plasma panel case.
Using it elsewhere will result in an unresolvable conflict.

Otherwise a hint system and implementation in the toolkit or implanting a BlurManager™ is inevitable in order to resolve conflicts.

And this should happen in Qt5/KF5 - yes.

(In reply to comment #51)
> what is irrelevant for the actual problem.

No, since that is the "official" API for setting a blur region.

> Still insufficient, since it can be crossed by other sources.
> The feature needs to be moved into some central instance, eg.
> QWidget/QApplication, a dedicated platform plugin or the style (which
> effectively is a platform plugin) - otherwise no plain Qt app could make use
> of this if it has to "fear" that eg. the oxygen-transparent style would
> still override it - even by this approach.

Then "too bad", IMHO. We can't have a perfect approach.

> If you want to add this from a third party, you need a manager, tracking
> dynamic QWidget properties (set to the blur region) and move/resize events
> to form a new region and export that at the end of the event cycle.

This would still get fucked by for example oxygen-transparent.

> Since konsole btw. explicitly links X11 libs, you could just  copy over the
> plasma funtion (so konsole won't suddenly drag in webkit and whatnot)

Yes, that's what I originally did, but then didn't find the existing parts where it looked for X11, and just linking against another part of kdelibs was easier. :-)

> > I changed it to using rect() locally
> like "0,0,width,height" ::rect() or mapped to the window?
> You also need to monitor any translation of the widgets geometry relative to
> the window, ie. when it moves inside its parent or any of its ancestors
> moves.

Yeah, I just used QWidget::rect(), which obviously doesn't account for window borders, I see.

I guess the simpler approach would be to let it blur behind the entire window if blurring is turned on in the profile.

(In reply to comment #52)
> suggestion: why not work on frameworks 5 code? How often was now mentioned
> that a proper fix is not possible because of kdelibs being frozen? It's not
> true. frameworks is open for improvements and right now would be the time to
> work on it. Another pro: Konsole would not need to link libplasma as the
> specific code got moved into KWindowSystem.

Because the build system changes in frameworks are hard to keep up with unless you're following the frameworks development closely. Unless something has changed since last I looked, it's not easy to just sit down for a couple of hours and hack on it when you have a day job. :-)

> Because the build system changes in frameworks are hard to keep up with
> unless you're following the frameworks development closely. Unless
> something has changed since last I looked, it's not easy to just sit down
> for a couple of hours and hack on it when you have a day job. :-)
don't update each day, stick to one build. I also don't update more than once 
a week and the frameworks are mostly defined.

(In reply to comment #55)

> No, since that is the "official" API for setting a blur region.
Even it it was "official" it'd still be irrelevant since the entire approach is insufficient for the actual task.

> Then "too bad", IMHO. We can't have a perfect approach.
Of course we can. A hint base approached on a central blurmanager (be it in QWidget or explicitly installed) can deal with any amount of blur sources.

> This would still get fucked by for example oxygen-transparent.
No. Oxygen-transparent would simply hint the window to be blurred and the manager would invoke that into the region calculation (ie. minus opaque regions not explicitly hinted to blur)

> I guess the simpler approach would be to let it blur behind the entire
> window if blurring is turned on in the profile.
Probably sufficient for konsole/yakuake but rather overhead for konsole parts in dolphin/kate etc.

Btw: to only blur an entire konsole/yakuake window (so effectively only the translucent parts): a trivial KWin script could provide that right now.

If there's such interest, please raise hand(s).

(In reply to comment #58)

> Btw: to only blur an entire konsole/yakuake window (so effectively only the
> translucent parts): a trivial KWin script could provide that right now.

Or not - sorry.
We've apparently propertyNotify() exported, but no way for scripts to alter X11 properties :-(

(In reply to comment #58)
> Even it it was "official" it'd still be irrelevant since the entire approach
> is insufficient for the actual task.

It's not irrelevant as long as it is the "official" way to do it in the frozen kdelibs.

> Of course we can. A hint base approached on a central blurmanager (be it in
> QWidget or explicitly installed) can deal with any amount of blur sources.

Yes, which means we can't get it now, so irrelevant for this usecase.


> Probably sufficient for konsole/yakuake but rather overhead for konsole
> parts in dolphin/kate etc.

…which, again, is why it is off by default and per-profile. I personally don't care if I waste a couple of GPU cycles blurring behind a mostly opaque window, tbh.

> Btw: to only blur an entire konsole/yakuake window (so effectively only the
> translucent parts): a trivial KWin script could provide that right now.
> 
> If there's such interest, please raise hand(s).

If it was that easy I would rather have done that. :-)


But are there any actual objections, from the Konsole people (or from people maintaining apps using the konsole kpart)? It will be trivial to change this to use a possible, future, magic QWidget blurmanager if that ever appears.

> Or not - sorry.
> We've apparently propertyNotify() exported, but no way for scripts to alter
> X11 properties :-(
tempting, tempting

client.changeX11Property("Foo", [value1, value2, value3,...])

constraints:
* format == 32
* mode == replace
* type == cardinal

Need to sleep over it

On Thursday 19 September 2013 12:20:35 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=198175
> 
> --- Comment #60 from Martin Sandsmark <martin.sandsmark@kde.org> ---
> (In reply to comment #58)
> 
> > Even it it was "official" it'd still be irrelevant since the entire
> > approach is insufficient for the actual task.
> 
> It's not irrelevant as long as it is the "official" way to do it in the
> frozen kdelibs.
> 
> > Of course we can. A hint base approached on a central blurmanager (be it
> > in
> > QWidget or explicitly installed) can deal with any amount of blur sources.
> 
> Yes, which means we can't get it now, so irrelevant for this usecase.
and which is really sad that we just don't make it work properly and ignore 
this usecase. Let's just decide that we won't have that in 4.x, can we? It's a 
nice new feature for the 5.x world, isn't it?

Going the KWin script route might be OK, since that's evident as being a hack to users. I object to implementing a "blur the whole window" mode in Konsole itself for the known reasons (no good suitable place to put the option, not per-profile, either makes the KPart inconsistent or doesn't interact well with what the hosting app might be doing).

Guys, my two cents.

A centralized blur manager seems to be the right choice, and if you can implement it in KF5, it would be beyond awesome. There are some visual glitches that have nothing to do with blurring consoles that could be easily killed that way.

1. Inconsistent dashboard blurring (sometimes blurs, sometimes not).
2. Programs like Homerun don't respect my settings when I enable blur while they are running, and they have to be restarted.

That is for KF5. For KDE 4, a hack like a KWin script will do for the "blurred Konsole" use case, but won't solve any of the above. All of those programs will have to be separately fixed.

(In reply to comment #62)
> and which is really sad that we just don't make it work properly and ignore 
> this usecase. Let's just decide that we won't have that in 4.x, can we? It's
> a 
> nice new feature for the 5.x world, isn't it?

Ok, I agree.

We are now in the 5.x world, is there anything planned or have you got more important things to do?

What is te consensus on this issue?
I would like to have it and want to make a patch for it whatever the consensus is. Shall i go ahead and make it a checkbox in the "Edit color scheme" dialog (under Appearance -> Edit)? I'm fine doing this *if* it isn't vetoed by someone since that would just be wasting my time.

It's clear there is a case for this for some (me included) and for others to specifically not have this and you now have me offering my help to implement it.

By reading (parts of) this thread again, it looks like i need a consensus from Martin Gräßlin and Eike Hein. Could you two decide where it needs to be implemented, please? Once i have that, expect a patch for it within a few days :)

Deal?

Option in the profie + TerminalDisplay needs to track its position inside its host window and merge its geometry with the blur region. Even then it's technically possible for it to screw up though.

(In reply to Eike Hein from comment #68)
> Option in the profie + TerminalDisplay needs to track its position inside
> its host window and merge its geometry with the blur region. Even then it's
> technically possible for it to screw up though.

Just curious.
Why is there a need for TerminalDisplay to track it's position inside the host window and merge the geometry? (by merge i guess you mean rectFromHost.united(rectFromTerminal) where both are of QRect or QRectF).

I obviously need to test that it works, but how would i test that? Can you give me a clear usecase that will go wrong if i enable blurring that will be just right if i add geometry tracking? That would help me a lot in implementing this and getting it right the first time (oke, technically the second time since i already made a patch for this the easy way a couple years back, hehe).

Because TerminalDisplay can be resized at runtime, e.g. when it's embedded into Dolphin or Yakuake and the window or dock/split are resized. And there can be multiple instances of it in the same window (e.g. Yakuake splits).

Re merging: Because the hosting application might already be setting a blur region for other reasons (imagine a Yakuake theme that wants to have blurred translucent elements). The unfixable case is when TerminalDisplay unsets part of the blur region that the host app wants blurred anyway (which it can't know ...).

Isn't it far easier to allow the blur setting to be ticked if the application is a main application and not set the blur hint if it isn't? Wouldn't that fix all the cases? Or something like if the root window is the konsole main window.

If you're saying you only want blur support in Konsole: TerminalDisplay is private API, so it can have a setBlurSupported or whatever that only Konsole calls but not the KPart. But that means no blur for e.g. Yakuake, which means many users won't be satisfied by the solution.

(In reply to Eike Hein from comment #73)
> If you're saying you only want blur support in Konsole: TerminalDisplay is
> private API, so it can have a setBlurSupported or whatever that only Konsole
> calls but not the KPart. But that means no blur for e.g. Yakuake, which
> means many users won't be satisfied by the solution.

We're mixing things up here. That's probably because you know a lot more about Konsole then I do :)

I want to implement this in a way that satisfies everyone.

You just told me that - for instance - konsole shouldn't set the blur region if the parent app in which it lives sets the blur (Yakuake for instance). Therefore i'm proposing an idea to only have the blur be set when the application itself is Konsole, not embedded. That way, if it gets embedded it should still behave nicely when the parent sets the blur hint for the region it wants. If Konsole happens to be in that region, it would be blurred as well, right?

I don't know how the internals work, but in my mind this "idea" should work and allows other parties that embed it to blur whatever they want.

Please elaborate in detail if this doesn't work in principle for whatever reason.

> konsole shouldn't set the blur region if the parent app in which it lives sets the blur (Yakuake for instance).

No, I'm saying when TerminalDisplay sets the blur region, it needs to not replace the blur region but merge its intended blur region with whatever is already set. This is technically still problematic in the case where TerminalDisplay's blur region fully contains a blur region "write" by someone else that it might later unset when disabling blur in the profile, but that's an extreme edge case probably not worth worrying too much about - I don't know of any existing app where it would actually be a problem.

> That way, if it gets embedded it should still behave nicely when the parent sets the blur hint for the region it wants.

Then Dolphin needs it's own "Blur behind terminal" option - not really smart. It's nicer to place it in the Konsole profile options.

The algo is basically:

- catch relevant events for widget geometry change
- get current blur region
- map old widget geo to window
- remove from blur region
- map new widget geo to window
- add to blur region
- set blur region

(In reply to Eike Hein from comment #75)
> > konsole shouldn't set the blur region if the parent app in which it lives sets the blur (Yakuake for instance).
> 
> No, I'm saying when TerminalDisplay sets the blur region, it needs to not
> replace the blur region but merge its intended blur region with whatever is
> already set. This is technically still problematic in the case where
> TerminalDisplay's blur region fully contains a blur region "write" by
> someone else that it might later unset when disabling blur in the profile,
> but that's an extreme edge case probably not worth worrying too much about -
> I don't know of any existing app where it would actually be a problem.

But there is a catch.. How do you get the blur region that might already be set?
There is no function for that in KWindowSystem (which is used to set the region).

If you can clarify this last thing with a possible way to implement it, then i can go right ahead and make a nice patch :)
> 
> > That way, if it gets embedded it should still behave nicely when the parent sets the blur hint for the region it wants.
> 
> Then Dolphin needs it's own "Blur behind terminal" option - not really
> smart. It's nicer to place it in the Konsole profile options.
> 
> The algo is basically:
> 
> - catch relevant events for widget geometry change
> - get current blur region
> - map old widget geo to window
> - remove from blur region
> - map new widget geo to window
> - add to blur region
> - set blur region

Thank you for that elaborate explanation. That certainly makes it clear how you want it to be implemented.

It's an X11 property - you can query it using XLib/xcb API.
Adding a KWindowSystem getter sounds a bit off for technically only the WM/compositor should ever read it.

The discussion back then was to shovel this  to the GUI style (for it may also have wanted to impact this but since Qt5 doesn't support depth changes of existing windows, that point is now more or less void)

I'd suggest to go for a relaxed protocol (gentleman's agreement) on some dynamic Qt property on the widgets and a static KStyle helper to traverse all widgets in a window for the blur props, merge them into a region and set the X11 property via KWindowSystem

You'd then
myWidget->setProperty("kwin_fx_blur", QRegion);
KStyle::updateBlur(myWidget->window()); // schedules a run for the end of the event cycle

(In reply to Thomas Lübking from comment #77)
> It's an X11 property - you can query it using XLib/xcb API.
> Adding a KWindowSystem getter sounds a bit off for technically only the
> WM/compositor should ever read it.
> 
> The discussion back then was to shovel this  to the GUI style (for it may
> also have wanted to impact this but since Qt5 doesn't support depth changes
> of existing windows, that point is now more or less void)
> 
> I'd suggest to go for a relaxed protocol (gentleman's agreement) on some
> dynamic Qt property on the widgets and a static KStyle helper to traverse
> all widgets in a window for the blur props, merge them into a region and set
> the X11 property via KWindowSystem
> 
> You'd then
> myWidget->setProperty("kwin_fx_blur", QRegion);
> KStyle::updateBlur(myWidget->window()); // schedules a run for the end of
> the event cycle

Hi Thomas,

Thank you for that information.

I was already getting a bit of a feeling like "oh boy, this is not on a simple patch level anymore". And your explanation confirms that. 

I'm sorry, but this is not on a patch level anymore that i feel comfortable with.
I would have been fine by touching Konsole code and perhaps a few other framework libraries to get this implemented. But touching XLib/XCB is a showstopper for me, that's where i drop out.

We're back to one of my earlier assessments for this issue. It's very difficult to implement while the basic functionality is so easy to get.

Good thing is that every aspect of this issue and how to implement it is now described in this bug report, hehe.

*** Bug 365780 has been marked as a duplicate of this bug. ***

I think implementing it separately in Konsole and e. g. Yakuake is the best solution, tbh. Blurring is something that looks weird if only behind part of the window anyways.

Anyone care to comment on this patch?  https://phabricator.kde.org/D10015

(In reply to Kurt Hindenburg from comment #81)

I like it! Thank you for making that patch! I sincerely hope it gets accepted, I see no reason why it shouldn't.

I created 2 patches to add blur option.
One for Konsole (standalone only): https://phabricator.kde.org/D10015
One for Yakuake: https://phabricator.kde.org/D10063

Git commit c63525fcdc52b3c3d6a82364bb21e8b41bd60c4d by Kurt Hindenburg.
Committed on 01/02/2018 at 13:52.
Pushed by hindenburg into branch 'master'.

Add option to ColorScheme to blur transparent background

Note that this does not affect KonsolePart; it is up to the app using
it to enable transparency (see src/tests/demo_konsolepart).

Patch by anemeth
Differential Revision: https://phabricator.kde.org/D10015

M  +14   -0    src/ColorScheme.cpp
M  +14   -0    src/ColorScheme.h
M  +12   -0    src/ColorSchemeEditor.cpp
M  +1    -0    src/ColorSchemeEditor.h
M  +7    -0    src/ColorSchemeEditor.ui
M  +16   -0    src/MainWindow.cpp
M  +1    -0    src/MainWindow.h
M  +3    -3    src/SessionController.h
M  +7    -0    src/ViewManager.cpp
M  +7    -0    src/ViewManager.h

https://commits.kde.org/konsole/c63525fcdc52b3c3d6a82364bb21e8b41bd60c4d

Woot! Thank you so much for committing a patch for this at last! It took over 10 years, but finally we have the ability to use a blurred background for Konsole ^_^

@Kurt, a big thank you from me as well! I for one am really happy with it :)

Hello.

Under GNOME, the blur option doesn't work. Which is sort of expected, as the documentation of KWindowSystem states plainly that not all functionality is available on all windowing systems[1].

IMHO some note should be added about this issue, either as a tooltip, or in the konsole manual, so that it's easy for users to figure out what the problem is if they're not running KDE.

[1] https://cgit.kde.org/kwindowsystem.git/tree/README.md

(In reply to Ahmad Samir from comment #87)
> Hello.
> 
> Under GNOME, the blur option doesn't work. Which is sort of expected, as the
> documentation of KWindowSystem states plainly that not all functionality is
> available on all windowing systems[1].
> 
> IMHO some note should be added about this issue, either as a tooltip, or in
> the konsole manual, so that it's easy for users to figure out what the
> problem is if they're not running KDE.
> 
> [1] https://cgit.kde.org/kwindowsystem.git/tree/README.md

I don't think konsole would be the place for that.
Perhaps the blur plugin information (in System Settings -> Desktop Behavior -> Desktop Effects -> Blur) would be more appropriate?

(In reply to Mark from comment #88)
> I don't think konsole would be the place for that.
> Perhaps the blur plugin information (in System Settings -> Desktop Behavior
> -> Desktop Effects -> Blur) would be more appropriate?
How would a GNOME user even see the description in the KDE system settings?
And why would someone use Konsole under GNOME, when GNOME has a nice terminal too?

Created attachment 110340 [details]
attachment-2706-0.html

On Feb 4, 2018 4:11 PM, "Alex Nemeth" <bugzilla_noreply@kde.org> wrote:

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

How would a GNOME user even see the description in the KDE system settings?
And why would someone use Konsole under GNOME, when GNOME has a nice
terminal
too?


Why? So many reasons, for example I use Konsole under GNOME, and I don't
have KDE's System Settings because it fits my needs.
The most appropriate place for placing the notice is where you flip the
switch, in this case, on Konsole settings.

(In reply to Alex Nemeth from comment #89)
> (In reply to Mark from comment #88)
> > I don't think konsole would be the place for that.
> > Perhaps the blur plugin information (in System Settings -> Desktop Behavior
> > -> Desktop Effects -> Blur) would be more appropriate?
> How would a GNOME user even see the description in the KDE system settings?
> And why would someone use Konsole under GNOME, when GNOME has a nice
> terminal too?

That's a matter of personal preference; I like using gnome-shell and I like using konsole, the two don't have to be mutually exclusive. :)

If not as a tooltip, then it could be in the konsole manual; my point is it needs to be documented somewhere, so that users can easily find it when/if they hit this issue and - as most users do - turn to online search engines for a solution/explanation, that's all.

I would suggest to add a tooltip to the checkbox with more clarification, e.g. "Ask the window manager to blur the background behind the Konsole window (if supported)". A user would then understand when it does not work.

*** Bug 322102 has been marked as a duplicate of this bug. ***