On 05/09/16 17:21, Alan Griffiths wrote:
> On 02/09/16 15:44, Alan Griffiths wrote:
>> 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
On 06/09/16 00:41, Christopher James Halse Rogers wrote:
>
>
> On Tue, Sep 6, 2016 at 2:21 AM, Alan Griffiths
> wrote:
>> On 02/09/16 15:44, Alan Griffiths wrote:
>>> 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 i
On Tue, Sep 6, 2016 at 2:21 AM, Alan Griffiths
wrote:
On 02/09/16 15:44, Alan Griffiths wrote:
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 dis
On 02/09/16 15:44, Alan Griffiths wrote:
> 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 on
That's an important point worth highlighting again:
"Wayland does prevent clients from knowing the absolute positions of
surfaces, but not for security reasons. More for being able to do
input transformations and non-traditional compositing."
Indeed compositing is potentially free-form if you ge
Hi,
replt inline
On 01/09/16 13:02, 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
On Thu, Sep 1, 2016 at 9: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,
mir_sur
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
A relative {x,y} would make sense and be much simpler than the currently
over-engineered "attach to a rectangle". In Xmir and toolkits we tend to
see empty rectangles being used:
MirRectangle placement = {dx, dy, 0, 0};
already. It should have been a simple relative {x,y} from the beginning..
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,
mir_surface_spec_set_placement()
the toolkit wants t
13 matches
Mail list logo
