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

List:       kwin
Subject:    Re: Notifications behavior
From:       Rob Scheepmaker <r.scheepmaker () student ! utwente ! nl>
Date:       2008-10-29 14:26:23
Message-ID: 200810291526.23410.r.scheepmaker () student ! utwente ! nl
[Download RAW message or body]

On Wednesday 29 October 2008 10:58:28 Lubos Lunak wrote:
>  You were also told:
>
> [15:57:16] <Seli> pinda: can you please mail kwin@ with a description of
> what you want?
> [15:57:30] <Seli> mind you, not what you think you want, but what you want
> [15:58:18] <pinda> behavior wise for that window?
> [15:58:26] <Seli> yes, like that
>
>  Now, where is that :) ?

Hehe, let me explain it better. The window should:
* Never steal focus. I'm not sure it's ok to not allow it to get focus at all. 
What if in the future we decide we want to have a text input widget on one of 
the extenders (for example, on kopete notifications so you can directly type a 
response or something like that). Ability to get focus is required to make 
that possible right?
* Never appear in task manager.
* Never appear in pager.
* Never appear in alt-tab switcher.
* When manually opened, should be able to get closed by clicking anywhere else 
on the screen. I currently do this by installing an event filter and 
monitoring for QEvent::WindowDeactivate.

That's about it, I think.

>  The options now are basically two, depending on what you actually want:
>
> - You use Qt::X11BypassWindowManagerHint and handle everything in the app.
> KWin won't interfere, so no Alt+Tab, no taskbar, no focus stealing. This is
> suitable if the windows will basically just pop up and be handled quickly
> (in other words, it'll be like KPassivePopup) and will get increasingly
> complicated if more will be wanted (such windows will stay while switching
> virtual desktops, other windows won't raise above them, etc.). Even if you
> do this, still set NET::Notification window type, since even with
> Qt::X11BypassWindowManagerHint the window type can be used by the
> compositing manager.

According to chani, this gives issues when used on the screensaver (the plasma 
on screensaver thing). Also, since these windows are not only used for 
notifications, I fear handling everything correctly could get a bit 
complicated.

> - You leave it up to the window manager (where 'leave' means you'll
> probably have to write that code though, sorry :), and it'll be probably
> slightly more work than the first case). The app sets only
> NET::Notification window type and KWin code will detect this and handle
> placement, not listing the window in Alt+Tab, special focus handling or
> whatever. Actually, the app should detect if the WM supports this and if
> not, will have to fall back to those various flags like Net::SkipTaskbar to
> get it working somehow with those WMs too.

I think this is the saver and more correct approach. I've never even had a 
glimpse at the kwin code before, but this doesn't sound like something that is 
very difficult to accomplish, so I'll probably will have a look at it soon.

>  Depends on what you want.

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