[Konsole-devel] Review Request 109391: Blur konsole background if transparency has been set

[Thomas Lübking]

> On March 10, 2013, 6:02 p.m., Martin Gräßlin wrote:
> > This patch shows the same problem as any previous attempt to that problem. For a full record of the issues please see history of e.g. https://bugs.kde.org/show_bug.cgi?id=198175
> 
> Mark Gaiser wrote:
>     Hi Martin,
>     
>     The "record" is scattered throughout that bug report and there doesn't seem to be any summing up of how you would think this is acceptable.
>     So let me try to make a small summary of what seems to be the case.
>     
>     1. Blurring the entire window should not be done (which is what i did in this patch).
>     2. Blurring should be done through the kpart from konsole.
>     3. You are apposed to that since you see a blurred konsole as a bug.
>     4. A config option should be added to allow blurring if the window is transparent.
>     
>     The easy approach is the one i did here. It's not dependent on the kpart of konsole and works on an application basis. This means every other application using the console kpart will also have to (manually) add the one liner to add blurring.
>     
>     Next up is a blur fundamental. In my opinion blur is meant to blur (partly) transparent areas on the desktop. Whatever ones opinion is about that. That makes it consistent and should be how it works. So for konsole the default (and i know you disagree here) should be blurred when it's partly transparent.
>     
>     What i guess needs to happen is:
>     - Add in a config option (per profile) to enable/disable blur when there is some form of transparency.
>     - That option should be enabled by default as said for the above reasons of consistency.
>     
>     Do you agree to those steps? The result would probably be like this: http://bugsfiles.kde.org/attachment.cgi?id=70130
>     
>     Another possible alternative is probably to blur it be default without any option to change that. Then with custom window flags you could probably disable blur.
> 
> Martin Gräßlin wrote:
>     IIRC Eike Hein once did a complete write up on the issues.
>     
>     Obviously I do not agree as (as you have noticed) I consider a blurred console as a bug and not as a feature. I also disagree on the point that if there's translucency it needs to be blurred. There are valid usecases for non blur and I would say konsole belongs to them (as well the Plasma Dashboard).
> 
> Thomas Lübking wrote:
>     Long story short:
>     we need a complete blur infrastructure across all widgets since we pass only one region to the WM.
>     This means widgets must be able to toggle themself to blur and the GUI style must have a word in this (see comment #40 in that bug)
>     
>     On top of that resides the demand to configure whether konsole (or its part) should be blurred in a certain context.
>     
>     As for konsole or yakuake, just blur the entire window by the suggested hint in the bug. That's a workaround, but this here is no solution.
>     Not to mention that it's bloat to link konsole against plasma in order to set a window property.
>
> 
> Mark Gaiser wrote:
>     Hi Thomas,
>     
>     Could you elaborate a bit more on what exactly you are suggesting now? Since it "sounds" like you want a "Blur" class in which i can define the app window that "could" be blurred and the regions within that rectangle that "should" be blurred?
>     
>     lets say:
>     class Blur
>     {
>     public:
>       Blur(QRect appWindow);
>       addBlurRegion(QRect region)
>       // .. some more magic glue to add it to kwin
>     }
>     
>     Where in this case the "addBlurRegion" function call would contain the Konsole KPart?
>     
>     Is that what you're suggesting?
>     
>     As for "Not to mention that it's bloat to link konsole against plasma in order to set a window property." .. Please do give me another option then :) You along with Martin are the folks that can make it easier.

No. The idea was to set a (dynamic) property on widgets that want to be blur controlled.

Snip from a mail i sent Hugo mid Janurary.

-------------------

i'd propose to have one 32bit value for this, the reason is that then style and widget do only have to resolve it once and take all relevant information from the bitmask (also we can reserve a very unique name, in doubt "BospygenFeatureRequest" ;-)

This provides us 32 settings which can be hinted to the style and set by a common Bitmask, ie. enum.

I think it'll (for the moment) be required to say

1. Shadow Me (Shadow)
2. Do Not Shadow Me (NoShadow)
(3. Shadow As You Want) ((implicit))
4. Blur Me (Blur)
5. Do Not Blur Me (NoBlur)
(6. Blur Me As You Want) ((implicit))
7. Do not make this window translucent, ever! (NoARGB)

So w/o any particular order:
enum KStyleFeatureRequest { Shadow = 1<<0, NoShadow = 1<<1, Blur = 1<<2, NoBlur = 1<<3, NoARGB = 1<<4 };

And state that the hint must be set by the widget only.
The style must only read and never write it.

Setting must occur |= only, ie.

uint kStyleFeatureRequests = widget->property("KStyleFeatureRequest").toUInt(); // 0 by default
kStyleFeatureRequests |= NoARGB;
widget->setProperty("KStyleFeatureRequest", kStyleFeatureRequests);

Withdrawing a property is only permitted for client, but never library code, ie. QIBreakOnARGBWidget can *set* NoARGB but only ever mancyApplication may withdraw this (or other) attributes.

----------------

Controlling the blur level of subregions of a widget was not considered - and probably doesn't make sense either (but *maybe* for QGraphicsScene, but that one's so much special that it's out of scope)

Reg. linking plasma: the function does not belong there anyway but into KWindowSystem (where everything else talking to the WM went before kdelibs was frozen) - otherwise you'd use XChangeProperty or xcb_change_property directly.
However with the above approach, this wouldn't be your problem at all.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109391/#review28898
-----------------------------------------------------------


On March 10, 2013, 5:02 p.m., Mark Gaiser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109391/
> -----------------------------------------------------------
> 
> (Updated March 10, 2013, 5:02 p.m.)
> 
> 
> Review request for Konsole.
> 
> 
> Description
> -------
> 
> This has apparently been a request in bug #198175 for quite a few years. Which i only found out after making the patch.
> 
> This patch blurs the Konsole window background of the transparency has been set.
> 
> 
> This addresses bug 198175.
>     http://bugs.kde.org/show_bug.cgi?id=198175
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt e9f7dea 
>   src/MainWindow.cpp 0ba82f0 
> 
> Diff: http://git.reviewboard.kde.org/r/109391/diff/
> 
> 
> Testing
> -------
> 
> Background is blurred just fine.
> 
> 
> Thanks,
> 
> Mark Gaiser
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20130310/48c80a85/attachment.html>