Ignoring window snapping

[Ryan]

On Sunday 18 December 2005 13:40, Lubos Lunak wrote:
>  I see. The reason I always ask "why?" when somebody asks a KWin-related
> question and doesn't say much more is that usually all answers are wrong
> because the question is wrong. Just like here.

Understandable.  My question didn't provide much background and that's my 
fault.  I normally try to be pretty thorough before asking any questions on 
lists by reading through source code, googling, or other by using any other 
resources first.

>
>  With window managers it's like say with the post office. You take a
> package there and say where you want to send it, but you don't tell them
> how to get it there, because they know, and they usually know it better. If
> the package is special in some way, fragile or you need it to get there
> fast, you stick "fragile" or "express" on it and leave it to them, you
> don't tell them "please be careful" or "tell the driver to go fast" or even
> do part of their work.

This too is what lead me to look through kwin code for the solution.  It was 
obvious that fixing this is probably outside the scope of a SuperKarmba 
theme.  Btw, a SuperKaramba theme is merely a QWidget that is 
pseudo-transparent and has python extensions and callbacks.  SuperKaramba 
itself is just a manager of those "themes".  So for example I can use the 
static functions to force a "theme" to be behind all windows by calling 
KWIN::setState(winId(), NET::KeepBelow).  Since kwin had the ability to set 
the window state, I figured that if there was a way to do it, it would be 
something that kwin managed.

>
>  So, in this case, the question should have been something like "how do I
> tell KWin this is a Superkaramba window and not a normal window, so that it
> doesn't treat it like a normal window?". To which the question is roughly
> that I don't know what "Superkaramba window" really means but I think it
> will require a new window type. After you describe what such window type
> should do. And also, if I'm getting right what Superkaramba is (I've never
> seen it running actually), the question is also whether they really should
> be standalone windows and not part of the KDesktop window.

I explained briefly earlier what SK is, so if you have more questions about 
that, please ask.  In regards to a new window type, is that a realistic 
solution this late in 3.5.x release cycle?  If you're referring to kde4 
development, it would be something to consider when designing how interactive 
applets will behave in plasma.  I'm not highly familiar with what kdesktop 
controls, but I'm assuming it manages things like wallpaper, desktop icons, 
etc.  Is it already possible to add a "window" to kdesktop?

>
>  On a slightly related note, could you please point me to the alleged fix
> for http://bugs.kde.org/show_bug.cgi?id=114955 ? From the description in
> the comment it seems to me like you're trying to do part of the package
> delivery yourself.

Here's the other related bug:  http://bugs.kde.org/show_bug.cgi?id=116227

http://websvn.kde.org/branches/KDE/3.5/kdeutils/superkaramba/src/karamba.cpp?rev=489288&view=log
The last three changes relate to the fix of changing the KWIN::setType() calls 
depending on if a theme is "docked" or not, meaning that it should be stuck 
to either the top, bottom, left or right side of your desktop.

Hope this clears things up somewhat.  If it isn't possible to do currently, 
that's fine.  It's definitely something to think about in regards to 
kde4/plasma.

Thanks,
Ryan