D8519: do not make the context menu a Window; do not force raise a window
Martin Flöser
noreply at phabricator.kde.org
Fri Oct 27 14:54:23 UTC 2017
graesslin added a comment.
In https://phabricator.kde.org/D8519#160909, @davidedmundson wrote:
> In https://phabricator.kde.org/D8519#160879, @graesslin wrote:
>
> > Actually even on X it is quite simple to get it right. We have the window Id, so the host needs to update the xTime in the window. The only question is whether Qt reads it back. With an up to date xTime a simple activate without a force should work.
>
>
> You're basing off an assumption. That clicking should raise the window. It isn't necessarily the case.
> There could be no window, (see current keyboard layout item), or new windows or something completely different.
>
> We could guess some heuristic based on if WindowId is set, dont' call activated, but do stuff, but that's in random guessing client-behaviour territory.
Sorry I didn't express myself correctly. If we have the window id the host should update the xTime on the window whenever the associated item is clicked. Then the window can raise/activate itself as it has an up to date xTime.
This is for example done in kglobalaccell: the timestamp of the shortcut is sent to the application through dbus. The application updates the xTime and activates the window. The window manager is happy, the xTime allows it.
REPOSITORY
R289 KNotifications
REVISION DETAIL
https://phabricator.kde.org/D8519
To: mkoller, davidedmundson, graesslin
Cc: #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20171027/8be981f9/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list