Ignoring window snapping
l.lunak at suse.cz
Fri Jan 6 18:16:16 GMT 2006
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
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
>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
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/
More information about the kde-core-devel