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

List:       kde-devel
Subject:    Re: Problems with WFlags
From:       Christian Nitschkowski <segfault_ii () web ! de>
Date:       2003-10-27 22:52:11
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 27 October 2003 18:45, Lubos Lunak wrote:
> On Monday 27 of October 2003 18:13, Christian Nitschkowski wrote:

>  That's a bug of KDE-3.1's KWin. Or maybe a feature, make your pick, with
> window managers it's sometimes difficult to say what's a bug and what's a
> feature.
>
Ah - a very interesting bug :-)
I now have three top-level widgets in my app (which aren't shown at the same 
time) and two of them get correct window-decorations, one doesn't.
It's especially strange because two of them are created exact the same way - 
and behave differently.
Both derived from QWidget, both have a
setFixedSize( sizeHint() );
KWin::setType( winId(), NET::Toolbar );
in their constructor.

But it doesn't matter - if one window (which is shown usually only for a few 
seconds) doesn't want to work as expected, it's fine for me.
The others do.

>  Yes. First, to make sure we're both talking about the same thing - you
> want to be able to specify exactly which buttons will be and won't be in
> the decoration, don't you?
>
To be more precise I wanted to get rid of the Maximize- and Close-Buttons.
But the Close-Button isn't that important and now after your tips the 
Maximize-Button dissappeared from one of the two windows I had the problems 
with.

>  The better solution is: Forget it. You'll never achieve that. Even if I
> made some special hints only for KDE, or reused the Motif ones, there still
> will be plenty of other window managers that will happily ignore it, and
> use whatever buttons they'll like.
>
>  Moreover, I won't do that - as I already said, it's not done that way. You
> describe the window and its restrictions, and the buttons depend on these
> things and on the mood of the window manager. If you e.g. try to hide the
> maximize button, but don't restrict the maximum size, the user will be able
> to enlarge the window anyway, effectively maximizing it. If you specify the
> maximum size, KWin will see maximizing the window doesn't make sense, and
> won't show the button (well, the 3.1 one will, and do that crappy thing
> when you click it, but it still won't make it larger).
>
>  The close button may be somewhat special in this case, because currently
> the only way to hide it is to specify a window type which shouldn't be
> closed (e.g. the dock type used by Kicker). The window manager
> specification has no means to make normal windows non-closeable. Which can
> either mean that it's missing there, or more likely that you actually don't
> want to have a normal window that cannot be closed. (Hmm, and even in case
> you do, it might be much simpler to live with the button and ignore the
> close event than to try to get that into the specification - some window
> manager will allow the user to close it anyway).

Ok.
I'll go on without this nasty WM-stuff :-)

Regards and thanks again for your help
Christian Nitschkowski

- -- 
- --: Christian Nitschkowski <segfault_ii@web.de> :--
- --: Jabber: segfault_ii@a-message.de :--
- --: ICQ#: 66190597 :--

Go where the silence is and say something
- - Chumbawamba
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/na8G119BwfrC2gIRAtqCAKDeIkQxcYKQMxagw2xC9cFT0BcBjgCg0o3W
hqQUeXKZNdrlYPgES/+ycmU=
=Hx87
-----END PGP SIGNATURE-----

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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