Ignoring window snapping

[Lubos Lunak]

On Sunday 18 December 2005 20:18, Ryan wrote:
> 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.

 I didn't mean to blame you or anything like that. I simply stated the fact 
that for some reason most people have difficulties grasping the WM concept.

> >  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.

 As mentioned in the WM spec 
http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2511313 , 
KeepAbove/Below are rather meant as user preference and apps shouldn't use 
them. Generally the window type describes what a window is and other flags 
are only small adjustments.

> >  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.

 Well, AFAIK SK is a couple of views placed on the desktop that show various 
information. But I wasn't asking for user description. I was asking what SK 
window is supposed to be from the technical point of view (border? movable by 
the user? can get focus? where in the stacking order? etc.).

> 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 could add a new window type even for 3.5.x if really needed, the code would 
be rather simple and I don't see a problem. Is SK supposed to run also 
outside of KDE? If not, I could just add a new type only for KDE that we'd 
use for KDE3.5 that fix all the problems. Otherwise I guess it'd be better to 
find a good set of already existing flags as a workaround for now, and then 
we'll worry only about KDE4.

> 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?

 Yes. No. KDesktop is just one window and doesn't have any functionality for 
adding anything inside it, especially not out-of-process. And adding that 
seems to be out of question for 3.5.

>
> >  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.cp
>p?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.

 That's again trying to work around individual problems using already existing 
flags instead of supporting a new window type.

 I suggest that you give me a technical description of what SK windows should 
do. Then I'll either give you a set of flags that'll give you closest match 
to the functionality you need (plus possibly some KDE3.5 workarounds if 
needed), or will try with a new window type, or I'll see :). As for KDE4, I 
have no idea how you plan to integrate this with plasma, but if the windows 
will be standalone there too, then that'll very likely need a new window 
type.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/