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