Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0
Martin Gräßlin
mgraesslin at kde.org
Fri Nov 21 18:09:39 UTC 2014
> On Nov. 21, 2014, 4:21 nachm., Thomas Lübking wrote:
> > src/kstartupinfo.cpp, line 1010
> > <https://git.reviewboard.kde.org/r/121197/diff/1/?file=329330#file329330line1010>
> >
> > Should this not rather be ::getTimestamp() unconditionally?
> >
> > This is supposed to be a hint when the application was triggered, not when there was the last interaction in the calling client.
> >
> > ::appUserTime() might be any random value in the past, thus pollute the FSP heuristics.
you have a point. I thought the current usage assumed that e.g. when Krunner starts an application that it creates the ASN after the event which triggered it. The event contains a timestamp and Qt should(TM) update the app user time accordingly. From reading the code that is currently not the case (I checked in Kickoff), but could easily be changed to be correct and is something I wanted to look into. It would be the correct timestamp in that case and doesn't trigger another roundtrip to X during starting an application.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121197/#review70739
-----------------------------------------------------------
On Nov. 21, 2014, 11:44 vorm., Martin Gräßlin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121197/
> -----------------------------------------------------------
>
> (Updated Nov. 21, 2014, 11:44 vorm.)
>
>
> Review request for KDE Frameworks, kwin and Plasma.
>
>
> Repository: kwindowsystem
>
>
> Description
> -------
>
> KStartupInfo::createNewStartupId is supposed to return a new
> id with a properly setup user timestamp. But if QX11Info::appUserTime
> returns 0 this was included in the id and cannot be considered a
> properly setup user timestamp. An app user time of 0 is the case
> for klauncher. If an application uses this timestamp of 0 passed from
> the startup notification it causes problems with passing focus to it
> from KWin. The application sets the timestamp in the
> _NET_WM_USER_TIME property and the value "0" has the special meaning
> of requesting to not be initially mapped. KWin honors that and doesn't
> focus the window. An application is not supposed to interpret a 0 time
> stamp passed through the startup notification as a special value to get
> the current time. It is totally fine to expect that it gets a proper
> value passed. Thus one cannot blame applications for not interpreting
> this value accordingly. An example for an application passing the 0
> to the _NET_WM_USER_TIME is Firefox. Starting Firefox in a Plasma 5
> session through e.g. the launcher results in KWin not passing focus
> to it and instead demands attention. This is clearly wrong and not
> intended.
>
> The solution in this change is to get the current timestamp from
> the X server in case the appUserTime is 0. This fixes the described
> problem with Firefox: it now gets properly focused on starting
> through a launcher.
>
>
> Diffs
> -----
>
> autotests/kstartupinfo_unittest.cpp f4b607d2a21da7dcf32434c00b2bdeeaf401ee65
> src/kstartupinfo.cpp 03418fce1a154ea388d0f65665dc0c9724a5623a
>
> Diff: https://git.reviewboard.kde.org/r/121197/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Martin Gräßlin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20141121/eacb689b/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list