[Konsole-devel] Review Request 109391: Blur konsole background if transparency has been set
Thomas Lübking
thomas.luebking at gmail.com
Sun Mar 10 20:20:59 UTC 2013
> 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.
>
> Thomas Lübking wrote:
> 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.
>
> Mark Gaiser wrote:
> Right..
>
> We have a lot of text in here now in just a few hours, but i don't see a way forward here since it's all based on ideas...
> Is there any concrete suggestion on how to move forward within the KDE 4.x scope? Lets _not_ push this forward to KDE 5.x (or whatever it's name is going to be).
>
> If the "widget->setProperty" is the way you guys want to go, then please make it happen on the kwin side. I will volunteer to do the Konsole side and update the relevant parts in the tooltips for Dolphin and a few other apps where i did the same window flag stuff.
>
> Thomas Lübking wrote:
> The above is a convention to be implemented by QStyle (or the actual inheriting one) ie Oxygen, Bespin, QtCurve, Skulpture, ... for they're the one who actually know "what the application will look like".
>
> KWin is completely unaffected.
>
> At least Bespin and Oxygen(transparent) contain all the relevant code and only need to take that value into account.
>
> You'll still have to figure where and how to configure the value for the konsole part and then somewhere this convention (if it turns one) needs to be specified (ideally KStyle alongside a setter/remover function, but that /cannot/ happen for KDE4)
>
> Please add Hugo (Pereira) to this RR
>
> Mark Gaiser wrote:
> Oke, that makes it interesting.
> But are you really telling me that we cannot blur the background because kdelibs is frozen.. That really sounds odd.
> You know as well as i that "KDE 5" is at least 2 years away. It should be possible to do this in KDE 4.x.
1st off: i have no idea about the release schedule of "KDE5"
2nd: What i said is that this convention, the enum and a neat helper function *should* reside in either KStyle or maybe KWindowSystem (but rather KStyle) as the function you intended to use *should* be in KWindowSystem. As long as you don't freak it, you can just set the property directly on the implicit knowledge of the convention and the hope that you do it right (reg. the "enum" - which is not present - and the setting/clearing strategy)
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109391/#review28898
-----------------------------------------------------------
On March 10, 2013, 8:15 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, 8:15 p.m.)
>
>
> Review request for Konsole and Hugo Pereira Da Costa.
>
>
> 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/bd72f5de/attachment.html>
More information about the konsole-devel
mailing list