[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: [Kwin] Repost: Technical Review Request
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2003-05-22 16:37:38
[Download RAW message or body]

On Tuesday 20 of May 2003 03:20, David Johnson wrote:
> On Monday 19 May 2003 06:45 am, Lubos Lunak wrote:
> >  When I asked you to send it here, I meant the article itself, not
> > this mail ;).
>
> Since it's part of a binary tarball (which includes example source code
> and images) I didn't want to send it to the list. I still can't send it
> to the list because it's larger than the 40K limit. But I'm attaching
> the bare article sans complete source, stylesheet and images...

 Looks good in general.

 Some comments on it:

"If we didn't change this, then a right mouse click on the maximize button 
would be passed on to KWin, which would then dutifully move our window to the 
back." - That seems to be a KWin bug, actually. And converting all clicks to 
LeftMouse and saving the original one looks like a quick dirty hack that made 
it work. I'll note down to fix this for kwin_iii. Also note that there's a 
bugreport complaining about the fact that (titlebar) buttons react to all 
(mouse) buttons (http://bugs.kde.org/show_bug.cgi?id=58220).

When adding close button, you should check for isCloseable(), just like 
there's check for isMaximizable() for maximize button.

mousePosition() - perhaps it'd be good if you explicitly stated that for inner 
parts of the window, it should make sure to return Center. Otherwise this 
would be causing problems with some (broken) applications.

menuButtonPressed() - most KWin decorations don't support closing windows by 
doubleclicking them, for usability reasons. And apparently some people 
disagree (http://bugs.kde.org/show_bug.cgi?id=56922). As I don't want to 
decide this, I don't know what the result will be. But either way, the code 
in your example is not correct. See how it's done e.g. in the Redmond style 
in KDE3.1.
 - also, "We also set the menu button to the "down" state." The call actually 
sets the button to the "up" state. It's necessary to reset the button to 
unpressed state due to some complicated reasons (popup menu grab).

"When you're subclassing a Qt based window manager, you can do a lot of 
things." - the first half of this doesn't make any sense to me. "subclassing 
a Qt based window manager"?

"A double click on the title bar should shade the window." - as said elsewhere 
in the HOWTO, this is configurable.

"if the window is shaded, there is still a one pixel high region for the 
client window" - I've been told this is a feature of QLayout.

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

_______________________________________________
Kwin mailing list
Kwin@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]