>
> The idea is that having unmapped by null-attach means the
> xdg_surface/xdg_toplevel etc is reset to the exact same state that it
> had when first created, thus to map again, one would do what one would
> do the same as when mapping it for the first time: set up the state
> (set_title,
Can you clarify something here.
>A newly-unmapped surface is considered to have met condition (1) out
+ of the 3 required conditions for mapping a surface if its role
surface
+ has not been destroyed.
Attaching a null buffer unmaps the surface
Unmapping the surface resets the state
> I was thinking more of e.g. Qt (or any other toolkit) that supports
> wl_shell, xdg_shell unstable v5 and v6 (albeit to a wildly differing
> extent sadly) and would now have to drop unstable v5 in order to
> support xdg_wm_base. Also, I think both KWin and Qt did only support
> unstable v5 until
I don't understand what we gain by sending the position again in global
compositor space, it will always match the position of the wl_output.
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
n, it's a position.
I've changed it in a way that still keeps the concept of direction, but
with a slightly different wording.
From 4e5fa5bf4bebe3c06d7172e2dcf13194278deb0c Mon Sep 17 00:00:00 2001
From: David Edmundson <k...@davidedmundson.co.uk>
Date: Tue, 20 Jun 2017 18:51:45 +0100
Subject: [
>
> For flipping, it's a bit more non straight forward, as
> flipping and the offset are not very useful in combination,
>
Yes, I think it's only when flipped where we need some additional
clarification.
> How about we add the following paragraph to the flip_x/y descriptions:
>
> The
You missed a line in "xdg-shell/positioner: Allow empty anchor_rect"
You might want to squash this with that.
From 0a21378302d63a83a10723b41adf35e605fb35f5 Mon Sep 17 00:00:00 2001
From: David Edmundson <k...@davidedmundson.co.uk>
Date: Tue, 20 Jun 2017 18:29:59 +0100
Subject:
From 093ed1a17a483792e316f932e15a566ab2653838 Mon Sep 17 00:00:00 2001
From: David Edmundson <k...@davidedmundson.co.uk>
Date: Tue, 20 Jun 2017 18:51:45 +0100
Subject: [PATCH 2/2] xdg-shell/positioner: Replace edge bitfield with extended
enum
Bitfields allowed for impossible combin
I have some comments/questions on the current v6 interface which I'd like
clarifying before we make it stable.
The Positioner anchor and gravity both takes the edge as a bitfield of
flags.
It's then part of the protocol to say "If two parallel anchor edges are
specified (e.g. 'left' and
Looks good to me!
Reviewed-by: David Edmundson <davidedmund...@kde.org>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Mon, Oct 30, 2017 at 5:03 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> On Fri, Oct 27, 2017 at 01:13:15PM +0100, David Edmundson wrote:
> > The server decoration protocol negotiates between the client and server
> > whether the client should default to drawi
The server decoration protocol negotiates between the client and server
whether the client should default to drawing window decorations, and
informs the compositor what the client is doing.
This is useful not just for a compostior that is doing decorations
itself, but much more importantly for a
This protocol is to address the following use case.
A user clicks on a URL link in an IRC chat and a web browser opens. We want
an existing browser window to raise or if it's a newly spawned application
to claim focus on startup.
Naturally we also don't want any arbitrary client to be able to
On Thu, Jul 5, 2018 at 4:56 PM, Drew DeVault wrote:
> I'm not sure why an activiation request has to jump through these
> surface export hoops first.
>
I think it's important to distinguish focus/raising from urgent/needs
attention hints.
I'm only interested in focus/raising.
Historically on
>Hm. If you wanted to, you could make this explicit by requiring an event
>serial in the export_surface request rather than the wl_surface.
Certainly an option. Though I'm not sure we have a use case of needing
to limit a client releasing its focus?
>Does this interface need to exist?
It
Reviewed-by: David Edmundson
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
set_reactive
Everything about this part makes sense.
+1
-
move request + moved
Concept of having explicit updating makes sense.
Might be worth considering calling it xdg_popup.reposition as
xdg_toplevel.move is very different
Would it be valid to re-use the same positioner object each
> +
> +
> +
> +
> +
Passing a serial also needs a wl_seat object to relate the two
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Thanks for working on this, activation is something key that we are
sorely missing.
If we want a complete 1:1 port of the X11 protocol, this certainly
technically fine, other than my one minor comment.
I dislike the X11 spec, so it's not my preference moving forward.
The main thing I dislike is
I need to patch either a client toolkit or a compositor and I'm not sure which.
There are some cases where we don't have a physical size for an output.
For example projectors or headless virtual machines,
Currently we (kwin) can send a physical size of 0,0 which is causing
some client issues
This may be a question for the general xdg mailing list.
>All of the above are exposed as $XDG_DATA_DIRS whatever application you pin
depends on the priority the lookup is done, very often it will not pin
the application it should!
I wouldn't remotely call it "broken by design". There are
For non-Gnome people, what does "lower" mean in this context?
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>would you typically have one surface for the decorations and an embedded
sub-surface for the content area?
For optimisation reasons you would probably do 5 subsurfaces.
top,left,right,bottom, main contents.
And that would allow the mixing of GL and raster as they are different
surfaces.
I
> FYI we did this a few years back for efl and enlightenment... on a loss of the
Yeah, it's good stuff.
I'm forced to go a bit lower as I'm trying to retroactively support
applications that have some pre-existing assumptions, but overall the
idea is the same.
> we added an extended protocol for
Hi all,
I have been working on a method of "Compositor handoffs"--allowing
clients to switch between compositors at runtime--and I wanted to
share my progress with everyone and gather some feedback.
# Overview
The design is very simple at it's core. A client knows everything
about the state of
>And that is where positioning is necessary: to not occlude the line of
text where the cursor is, and to show the documentation at a sensible
place (near the cursor position).
xdg-foreign will just get that window on top. You don't have any
control of where on top it is, merely a child-parent
The generated C code be full of conflicts. The
MY_PROTOCOL_REQUESTEVENT_SINCE_VERSION define for a start.
I think it might compile in C, but other generators exist that might
not and it's making life much more confusing than it needs to be. I
would strongly avoid it.
David
can follow it up on Qt's
Jira if there is a Qt issue.
David Edmundson - QtWayland Maintainer
28 matches
Mail list logo
