8th October, 2008tuxo

Thanks a lot for your hard work!

8th October, 2008anon

Would it be possible to disable the wobbly effect when resizing windows?

I really like it, but having the windows shake like crazy on resize is kind of frightening.

Thanks a lot for your work, KDE people!

8th October, 2008Lucas Murray

“Would it be possible to disable the wobbly effect when resizing windows?”

That configuration setting was added to trunk on the 4th of last month and was quoted in this development status post.

8th October, 2008knue

 Hi,

I noticed that in 4.1.1 the shadow of a wobbly window wasn’t wobbling, too. Thus in 4.1.2 shadows are disabled while a window is wobbling. Perhaps it would be nicer if the shadow stays enabled but wobbles just like the window does?

Another thing I notices: The desktop grid assumes that the panel looks the same on every desktop. But this is not always the case (for example when you “Only show tasks from the current desktop” is enabled).

Anyway: Thx for the hard work. Kwin does a really great job here with nvidida geforce 7600.

8th October, 2008Vedran

Thanks for this. Btw., what’s the status of non-eye-candy kwin wishes. For example tiling support or PWM-like tabbing.

8th October, 2008Lucas Murray

“Perhaps it would be nicer if the shadow stays enabled but wobbles just like the window does?”

This is exactly what I’m working on right now. It will be in trunk before soft-freeze at the end of next week.

“what’s the status of non-eye-candy kwin wishes. For example tiling support or PWM-like tabbing.”

Tiling has stalled, my available time is a lot lower than I had originally estimated and therefore it won’t be complete anytime soon. Window tabbing currently has no developer working on it but if it’s still up in the air by the time I finish tiling I’ll be picking it up and adding it myself.

8th October, 2008Aaron Seigo

loving the improving fit, finish and polish in kwin’s graphics related code. keep it up, bug fixes included! =))

8th October, 2008Anonyminus

Thanks for all the work, and for the extra work of sharing your progress!

If you have time, I’d love read an update on the possibility of anti-aliased window decorations? I read somewhere, maybe in the kde bug tracker, that it’s waiting on Qt 4.5…

8th October, 2008Lucas Murray

“If you have time, I’d love read an update on the possibility of anti-aliased window decorations? I read somewhere, maybe in the kde bug tracker, that it’s waiting on Qt 4.5…”

I think I saw Qt 4.6 somewhere but yes, we are waiting for a fix for Qt so we don’t need to do extremely ugly hacks (That didn’t even work the last time I tried to port) like what Plasma did to get ARGB visuals.

However, when this new shadow code is in decorations will be able to work around the problem by using the shadow texture as a pseudo anti-aliased border as the shadows themselves support transparency.

9th October, 2008kanttu

I don’t know how the window shadows are implemented in current development head but previously the whole shadow was just a dark layer (with blurred edges) under the window. This solution satisfies most common cases but there are some situations (like in Konsole with real transparency) where this makes no sense since you can see the shadowed background through the transparent pixels in the middle of the window.

I think better (and maybe faster) solution would be drawing just the shadowed “edges” rather than a layer slightly bigger than window we are shadowing. I think that OSX renders shadows this way.

Also the shadows should be disabled when the application decides to disable the windows decorations (some games do this). Window decorations can be disabled using XLIB API.

9th October, 2008kanttu

Just an addition to my previous post. If you test this http://macslow.thepimp.net/?p=41 in KDE4 with shadows enabled, you can still see the dark box with blurred edges (the shadow) under the ARGB window even though the decorations are disabled by the application.

9th October, 2008shamaz

Thank you for your ‘weekly’ reports. This is good to know there is a lot happening on kwin, and that this is not _only_ thanks to Lubos Lunak :)

9th October, 2008Lucas Murray

“I think better (and maybe faster) solution would be drawing just the shadowed “edges” rather than a layer slightly bigger than window we are shadowing. I think that OSX renders shadows this way.”

I am lead to believe this is what the Oxygen team also want (Something about glass shadows being more intense on the edges in reality…), as shadows will be defined by the decorations soon this idea might actually make it into 4.2.

“If you test this http://macslow.thepimp.net/?p=41 in KDE4 with shadows enabled, you can still see the dark box with blurred edges (the shadow) under the ARGB window even though the decorations are disabled by the application.”

The reason why shadows are still displayed for windows like these is because most windows that do not have decorations still look fine with shadows. As KWin has no way of determining whether or not a window has ARGB visuals it doesn’t know if there should be a shadow on those windows or not, so it always displays them.

Shadows really are just a hack on X, lots of guessing and no guarantees on anything. =(

9th October, 2008kanttu

“The reason why shadows are still displayed for windows like these is because most windows that do not have decorations still look fine with shadows. As KWin has no way of determining whether or not a window has ARGB visuals it doesn’t know if there should be a shadow on those windows or not, so it always displays them. ”

Ok. I understand. But how about an environment value KWIN_DISABLE_SHADOWS, so the users could choose it when running the application, like $ KWIN_DISABLE_SHADOWS=1 /path/to/executable ? Yes, it’s hack as well but couldn’t hurt anyone.

9th October, 2008kanttu

Never mind that previous post. Since if the shadows will be defined by the decorations, then disabling decorations with XLIB would remove the shadows as well?

9th October, 2008Lucas Murray

“Since if the shadows will be defined by the decorations, then disabling decorations with XLIB would remove the shadows as well?”

I have yet to work out what to do with this, it’s possible to have the decoration define the shadow for non-decoration windows but there are multiple ways of implementing it (Also it’s worth noting that context menus and tooltips are also classified as “windows” and they look nice with shadows as well). I think I’ll just play it by ear and work out what’s best through trial and error.

10th October, 2008kanttu

In that case the environment flag (KWIN_DISABLE_SHADOWS) would be useful. Atleast I’d appreciate it in my work :)