Alan is right with the modify surface *could* possibly confine a surface
thats unfocused though this would quickly resolve it self if someone where
to switch windows. The issue is we dont check if the surface we are
modifying in AbstractShell:modify_surface() is focused. Ill get a fix up
for that.
On 02/09/16 15:42, Thomas Voß wrote:
> This only works in the fullscreen case and I
> cannot think of a scenario where this impacts overall
> user experience. The app already is the one "owning" the display in
> fullscreen.
Why would you think it only work in the fullscreen case?
--
Mir-devel
On Thu, Sep 1, 2016 at 1:02 PM, Alan Griffiths
wrote:
> When clients toolkits provide hints to place child surfaces using the
> existing functions:
>
> mir_surface_spec_attach_to_foreign_parent();
> mir_connection_create_spec_for_tip();
> mir_connection_create_spec_for_menu(); or the proposed,
> m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I asked Jonas Adahl how the Wayland side is dealing with this, and
roughly:
Wayland doesn't see any of this as a security concern and broadcasts
the geometry of the display to clients:
https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayl
On 01/09/16 12:02, Alan Griffiths wrote:
>
>
> Thoughts and suggestions for the right way forward please.
>
A data point from Wayland
(https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v6.xml#n1018):
This event asks the popup surface
Hi,
On Thu, Sep 1, 2016 at 1:02 PM, Alan Griffiths wrote:
> Inspired by a discussion with Chris I've been reading our code and spotted
> some inconsistencies:
>
> 1. In AbstractShell::modify_surface() we carefully consume the streams
> settings *and apply* them before giving window management a
