Review Request 118909: Imply SkipTaskbar and SkipPager depending on Window Type

[Martin Gräßlin]

> On June 23, 2014, 10:08 p.m., Thomas Lübking wrote:
> > What about (non override) utility windows (eg. assume Qt would not set floating dock override to bring its own titlebar)?
> > While kwin (iirc by default) hides them for inactive windows, that's rather a feature.
> > 
> > -> By their nature, they should not be in the taskbar. But should they not appear in pagers?

> What about (non override) utility windows

Eike, what's your opinion on that from task manager perspective? Is the nature of a utility window to skip taskbar?

> But should they not appear in pagers?

yes, it has the same text: "This hint should be requested by the application, i.e. it indicates that the window by nature is never in the Pager."


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118909/#review60843
-----------------------------------------------------------


On June 23, 2014, 8:50 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118909/
> -----------------------------------------------------------
> 
> (Updated June 23, 2014, 8:50 p.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Eike Hein.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> -------
> 
> Imply SkipTaskbar and SkipPager depending on Window Type
> 
> Quoting EWMH:
> "Applications should not set this hint if _NET_WM_WINDOW_TYPE already
> conveys the exact nature of the window."
> 
> This means if the window type implies a SkipPager or SkipTaskbar the
> window will not have it set. To simplify the life of our API users we
> should add the state and not require our users to check that manually.
> 
> Every Normal or Dialog window does not imply that it shouldn't be shown.
> As our KDE Override is not a proper window type we can assume that it's
> also a Normal window or a Dialog.
> 
> The change is done in KWindowInfo and requires that the API user adds
> NET::WMWindowType explicitly to the properties. NETWinInfo is not
> adjusted to have it reflect the actual state of the atoms. Here we can
> assume that the users of the more low-level API are aware of the EWMH
> spec and will implement these checks themselves.
> 
> 
> Diffs
> -----
> 
>   autotests/kwindowinfox11test.cpp 50ce806add5ea8f6cb19e537609e936c3d0275bd 
>   src/kwindowinfo.h e9b7a0af66a1e0e0c4e4b84496157dd53035abc8 
>   src/kwindowinfo_x11.cpp 87a887c7e068f71cffc58c184bcd4b4722564047 
> 
> Diff: https://git.reviewboard.kde.org/r/118909/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140623/77b662fc/attachment.html>