Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0

2014-11-24 Thread Martin Gräßlin 

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

(Updated Nov. 24, 2014, 9:09 a.m.)


Review request for KDE Frameworks, kwin and Plasma.


Changes
---

added bug


Bugs: 337798
https://bugs.kde.org/show_bug.cgi?id=337798


Repository: kwindowsystem


Description (updated)
---

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

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0

2014-11-21 Thread Martin Gräßlin 


> On Nov. 21, 2014, 4:21 nachm., Thomas Lübking wrote:
> > src/kstartupinfo.cpp, line 1010
> > 
> >
> > 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.
> 
> Martin Gräßlin wrote:
> 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.

additional idea: changing createNewStartupId() to createNewStartupId(quint32 
timestamp = 0)

It would allow users having the up to date timestamp to pass it in and in all 
other cases to just use the one from getTimestamp.


- 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
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0

2014-11-21 Thread Martin Gräßlin 


> On Nov. 21, 2014, 4:21 nachm., Thomas Lübking wrote:
> > src/kstartupinfo.cpp, line 1010
> > 
> >
> > 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
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0

2014-11-21 Thread Thomas Lübking 

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



src/kstartupinfo.cpp


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.


- Thomas Lübking


On Nov. 21, 2014, 10: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, 10: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
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel