Zarin wrote:We need someone to fix the blur effect as it's just broken on way too many levels. It even crashes 64-bit systems for some reason. >_<

Yes I noticed it was broken. What's the story? Why do you say "too many levels". I had not followed the bug trail with this one partly because I had no idea what the effect was (until today . The code all looks very dependent on GL.

Well, it's just broken.

http://bugs.kde.org/show_bug.cgi?id=156018
http://bugs.kde.org/show_bug.cgi?id=158255
http://bugs.kde.org/show_bug.cgi?id=164889

It's the only effect that causes black screens, continued screen corruptions and crashes. The only other bugs that produce the same results are in the core and affect compositing in general.

Unless something is done about it I'm contemplating trying to get it disabled in 4.2 due to its instability.

Edit: Looks like the crashing was a nVidia driver bug that has since been fixed. The other two are still valid though.

Hi Zarin,

I'm interested in looking at this further but am not getting a response on the kde-devel list. How much do you know about this - especially design decisions behind current implementation?

Thanks

Martin replied to you on the list, I assume you are not subscribed so you never got the response.

What he said was:

On Wednesday 03 December 2008 14:11:00 Andrew wrote:
> Hi,
>
> Am a little interested in this effect as it is useful. I have been told
> that it has problems and it doesn't appear to work on my svn build with
> X3100 hardware.
>
> I notice that some of the bugs relating to this effect are being flagged as
> up- stream (drivers). However my first thought is that this effect should
> not cause problems.
that's great that you want to work on the blur effect. We are happy about
everyone who wants to give as a helping hand. And it would be great to get rid
of the problems

Probably the best place to discuss the effects is the KWin mailinglist or the
IRC channel.
>
> So, is this worth looking into and would anyone be willing to help with
> some pointers, especially WRT the design decisions behind the current
> implementation?
The effect has been written by Rivo Laks. I guess you have to ask him about
design decisions

Regards Martin Gräßlin

First off kwin#kde.org is the KWin mailing list, anything that goes on there all KWin developers get and is better to use than the general kde-devel#kde.org list. Also if you are planning on working with us it is a good idea to subscribe to the list itself so you will get the replies. It is also recommended to join us on #kwin on irc.freenode.net .

And secondly: Rivo Laks is very busy with other stuff so he is very difficult to contact. If you send him an E-mail don't expect a quick reply.

Edit: Thirdly if the effect isn't working on your X3100 then it is most likely because of a core bug that is causing KWin to not detect the correct driver making it think shaders are not supported.

Thanks for that... I subscribed to kdewin but in digestified form and probably missed it. I'll change over to non-digest.

Re not working on x3100 - yes I got that impression but was not aware that the relevant code was in core. That's the sort of thing I've got to work out.

I have the OpenGL book and shader language guide but what I'd really like is a pointer to the threads or docs that discuss the effects architecture in kwin. I've also grabbed qshaderedit to have a play with shader code.

andre_orwell wrote:... what I'd really like is a pointer to the threads or docs that discuss the effects architecture in kwin.

You would be interested in reading:

• the README file in the KWin module directory,
• the HACKING file also in the module directory,
• the KWin project page on TechBase, and
• the KWin effects library API documentation.

I think the idea is nifty, but I feel that tying this feature to the transparency of the windows is not the way to go. I would rather see a keyboard-shortcut that would make the windows transparent, and then you could click on the buttons. That way you could have fully opeque windows normally, but you could make them semi-transparent quickly, so you could click on other windows.

Of course this could get confyusing if you had several windows tacked on top of each other. So I would think that it would only work with one window behind the topmost window. It would be very confusing if you had four windows on top of each other, and you wanted to click on the buttons on the bottomest (is that a word?) window. It just would not work.

I'm new to these forums, but KDE is one of my favorite projects. My laptops tend to be on the smaller side (12" Apple Powerbook, Eee 701), so I run into the not-enough-screen-space issue all the time. My thoughts...

From what I see described here, I envision the ghost feature (clairvoyance would be a nice term) as having an alt-tab style picker that will pull an image of a background window to the forefront and ghost it on top of the main active window. I agree that this feature would be great but might cause a cluttered display depending on the situation.

When on OS X, I tend to use expose to peek at the contents of a background window when I need a quick glance. This can get chaotic if too many windows are open, however. Perhaps this could be enhanced in KDE by fading out the rest of the screen and arranging a scaled view of the foreground and a selected background window side-by-side while retaining input to both. Maybe some buttons at the bottom of the screen could let the user zoom into one window more than the other. Naturally, it'd be convenient to have a key command exit this mode and restore the prior layout of the screen. The one drawback is that this method could make small fonts unreadable.

One other possibility related to the small screen space issue would be a "dig" feature that would fade out top windows one at a time to let you see the contents of a buried window. The real value of this feature would be restoring the prior arrangement/layering of windows once the command is finished. This feature is really just an enhanced bring to forefront function. EDIT: It might be similar to a Windows 7 feature... I haven't been keeping track of every piece of MS news.

EDIT again: Haha, I realized the dig function is really similar to what Janne has been mentioning the whole time. The one difference is I think this feature could be really useful without keeping top windows semi-transparent, although it wouldn't be as useful concerning the Op's original issue.