I fully support any patch that removes the phrase "modelview".
On Fri, Apr 25, 2014 at 5:07 PM, Kristian Høgsberg wrote:
> On Fri, Apr 25, 2014 at 01:19:37PM +0100, Neil Roberts wrote:
> > In order to apply the zoom transformation to the output matrix, Weston
> was
> > doing the following:
> >
>
It looks OK, but the upstream is at https://github.com/anholt/libepoxy
On Tue, Apr 22, 2014 at 10:54 PM, Bill Spitzak wrote:
> On 04/22/2014 05:34 PM, Peter Hutterer wrote:
>
> Config with --enable-xwayland is not working however:
>>>
>>> checking whether to build XWin DDX... no
>>> checking d
On Thu, Apr 17, 2014 at 11:20 AM, Ander Conselvan de Oliveira <
conselv...@gmail.com> wrote:
> From: Ander Conselvan de Oliveira
>
> If a message was too big to fit in the connection buffer, the code
> in wl_buffer_put would just write past the end of it.
>
> I haven't seen any real world use cas
On Wed, Apr 16, 2014 at 2:27 PM, Pekka Paalanen wrote:
> Hi,
>
> I'm moving this conversation to where it belongs.
>
> On Wed, 16 Apr 2014 11:25:26 +
> bugzilla-dae...@freedesktop.org wrote:
>
> > https://bugs.freedesktop.org/show_bug.cgi?id=77521
> >
> > Priority: medium
> >
I'd imagine this is something like _NET_WM_FULLSCREEN_MONITORS, which
allows an application to full-screen across multiple outputs. This is a use
case xdg-shell doesn't handle right now. I don't know of anything but games
that would like to use such a feature, though.
On Mon, Apr 14, 2014 at 2:30
Recent gdm has support for Wayland sessions. You'll have to write the
session file yourself if you want to launch weston, though.
Something like this should work.
# mkdir -p /usr/share/wayland-sessions/
# echo << /usr/share/wayland-sessions/weston.desktop
On Sun, Apr 13, 2014 at 9:21 AM, Pekka
Why is this necessary? Won't events never be delivered while locked anyway?
On Apr 9, 2014 8:36 AM, "Neil Roberts" wrote:
> Before commit 2f5faff7f9142 when the compositor is locked it would
> reset the keyboard focus on all of the seats as part of pushing the
> focus_state. This was removed beca
Does this help clean up client code? Can you give an example of how a
client would use this?
On Wed, Apr 2, 2014 at 10:48 AM, Jason Ekstrand wrote:
> It's worth noting that there is one small backwards-compatability issue
> here. Namely, if the client is built against protocol stubs from an
> e
simply not offer the user a broken mode in the first place, but I don't
want to get a scolding from Adam Jackson, so I'll shut up.
On Thu, Mar 27, 2014 at 9:05 AM, Pekka Paalanen wrote:
> On Thu, 27 Mar 2014 08:31:34 -0400
> "Jasper St. Pierre" wrote:
>
> > I d
I don't think the user really knows what refresh is either.
I'm actually curious: is there a reason to ever expose different modes to
the user that have the same width/height but different timings? What's the
rationale for choosing one instead of the other? I know nothing about
display panels, kee
Yes. I'd say that realistically, you should never have more than one client
trying to set the mode at once. If you somehow do, your machine is already
messing up in some way. No need to design for a broken edge case in the
protocol.
Relying on message ordering is fine. We, of course, still want a
Yeah, this is fine with me.
Reviewed-by: Jasper St. Pierre
On Mon, Mar 24, 2014 at 8:13 AM, Giulio Camuffo wrote:
> 'close' is more consistent with the purpose of the event than
> 'delete', and it is also c++ friendly, since 'delete' is a keyword.
> ---
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
I suppose I just never thought of that. On first though, I don't see
anything wrong with that.
If that's what we should do, should
For very simple use cases, it's fairly mature. You can use it on embedded
systems quite well.
For complex desktops, it's not quite. There's a lot of protocols that are
traditionally in something like the ICCCM or EWMH that we have to reinvent
on Wayland.
We're working on them all the time, so it'
On Thu, Mar 13, 2014 at 3:12 PM, Bill Spitzak wrote:
> John Kåre Alsaker wrote:
>
>> On Wed, Mar 12, 2014 at 7:32 PM, Bill Spitzak wrote:
>>
>>> Isn't Wayland differentiating between the "selection" and the clipboard?
>>>
>> It is not doing that at the moment. Only explicit clipboard actions
>>
There's two different things here. There's the protocol and the "UI". (By
UI I also mean a command-line tool like /usr/bin/xrandr, I just mean the
way the user does a mode-set).
I think to build a good UI, we need a list of available modes that the user
can choose from. Having a tool where the use
hat would be better
> served by a more specific interface.
>
> Thanks,
> --Jason Ekstrand
>
> On Mar 4, 2014 9:22 PM, "Wang, Quanxian" wrote:
> >
> >
> >
> >
> >
> > From: wayland-devel-boun...@lists.freedesktop.org [mailto:
> way
So, before we go further on this, I need to ask three basic questions: what
are the goals of this interface? Who is supposed to use this interface? Why
would they use this interface?
On Tue, Mar 4, 2014 at 9:07 PM, Wang, Quanxian wrote:
> Hi, All
>
> With the first version of randr protol, I got
libinput is supposed to take a close callback in its interface
to allow you to call out to a privileged API to close FDs. But
the FD that libinput passes you is bogus, because
libinput_remove_source closes the FD on which it's passed. This
is really bad, as the libinput_source really doesn't own th
Hi Steve, thanks for the thoughtful response.
On Thu, Feb 27, 2014 at 3:27 PM, Dodier-Lazaro, Steve <
s.dodier-lazaro...@ucl.ac.uk> wrote:
> Hello Jasper,
>
> A quick reply on some of your emails (grouped to avoid spamming the ML).
>
> > My experience with PAM and similar "pluggable security mod
notification_shell, but they still can't use
org.freedesktop.Telepathy.
Your pluggable WSM just made the user unhappy.
Am 2014-02-26 23:05, schrieb Jasper St. Pierre:
>
>> Hi Martin,
>>
>> My experience with PAM and similar "pluggable security modules" is
>&g
For what it's worth, mutter treats wl_surface.damage coordinates as buffer
coordinates right now. So we're broken for buffer transformations, but
doing the intuitive correct thing.
Having them be in buffer coordinates is the intuitive thing to do here, and
I think it's what most implementers do ri
Hi Martin,
My experience with PAM and similar "pluggable security modules" is that
they provide a subpar user experience, are hard to integrate properly into
the system, and have large pain points that stem from having such
flexibility.
My compositor, mutter, will probably never call out to your
Aha. I just sort of assumed that we could have a long description of an
by using the contents, and it didn't seem to break. I didn't find
anything else doing it. I didn't know we needed a .
Reviewed-by: Jasper St. Pierre
On Mon, Feb 24, 2014 at 11:49 AM, Jonny Lamb wrote:
... and what if it fails? I'd say that requiring CLOCK_MONOTONIC is fine.
Are there any popular Linux setups that don't have CLOCK_MONOTONIC?
On Tue, Feb 18, 2014 at 10:13 PM, Thiago Macieira wrote:
> Em qua 19 fev 2014, às 08:47:32, Peter Hutterer escreveu:
> > + libevdev_set_clock_id(d
On Tue, Feb 18, 2014 at 2:22 PM, Bill Spitzak wrote:
> On 02/18/2014 11:09 AM, Mark Thomas wrote:
>
> I think the above description can be greatly simplified by removing
>>> the "hole" and "plug" objects and just using a subsurface:
>>>
>>> A creates a main surface
>>> A creates a subsurface f
In some cases, like Xwayland, stdout and stderr are redirected to
/dev/null, losing us valuable information, while wl_log can be
overridden, allowing us to send it to a log file instead. This
can help debugging immensely.
---
src/connection.c | 36 ++--
1 file chang
GtkPlug and GtkSocket are really implemented in terms of XEmbed. As we've
found, XEmbed has a surprising number of problems in real-world use cases,
so it's considered deprecated.
Building something special-case for panels seems much better than trying to
implement something generic like WaylandEm
errno is supposed to be positive, not negative. It seems that
everything else that calls display_fatal_error() calls it with
a positive error code, so do it here as well.
---
src/wayland-client.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/wayland-client.c b/src/w
The code very intentionally emits a lot of redundant declarations
to simplify the scanner code. Somebody building with -Wredundant-decls
would have compile errors, so emit special pragmas to turn those
warnings off.
These pragmas should be ignored outside of gcc/clang.
---
src/scanner.c | 4 +++-
What reschedules the frame being drawn when focused is gained / lost, then?
On Wed, Feb 12, 2014 at 3:08 AM, Emilio Pozuelo Monfort
wrote:
> On 12/02/14 01:04, Bryce W. Harrington wrote:
> > (For full disclosure - On one test run against master, I noticed the
> > flower changed shape every time
ient
> to tell when resizing it initiated stops and other resizes start, so that
> it can change how it is handling the edges. Is this already solved in some
> other way?
>
>
> Jasper St. Pierre wrote:
>
>> The parameter was dropped...
>> ---
>> protocol/
It's unused except for one easily-replaceable place.
---
clients/window.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 91c1ea0..fad4793 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -395,22 +395,6 @@ e
The client had logic to adjust the dx/dy parameter of the window when
resizing, but it was broken: nothing enabled that code, and it would only
work for the first resize.
To make up for it, desktop-shell had code to flat out ignore the dx/dy
parameters when resizing and anchor it its own way. This
The parameter was dropped...
---
protocol/xdg-shell.xml | 6 --
1 file changed, 6 deletions(-)
diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
index f0d04aa..7e4193b 100644
--- a/protocol/xdg-shell.xml
+++ b/protocol/xdg-shell.xml
@@ -243,12 +243,6 @@
ignore it if it does
ail.com] *On Behalf Of *Jasper
> St. Pierre
> *Sent:* Sunday, February 09, 2014 12:23 AM
>
> *To:* Wang, Quanxian
> *Cc:* wayland-devel@lists.freedesktop.org
> *Subject:* Re: Is there any way to let compositor set the data in client
> space and then return back to client?
&g
Well, there's not really anything that allows process A to arbitrarily
modify process B's memory. The only thing that's close is memory-mapped
files, and that's already what we use to share image data between the
client and the compositor.
There's also memfd, which is "more secure" than a memory-m
wlshm is old. You should just be able to just install xf86-video-wayland
and have everything work.
On Wed, Feb 5, 2014 at 12:46 PM, Bill Spitzak wrote:
> On 02/05/2014 09:21 AM, Jasper St. Pierre wrote:
>
>> What compositor are you using
>>
>
> The X11 compositor you get
What compositor are you using, and how did you build Xwayland? Did you
build xf86-video-wayland as well?
On Wed, Feb 5, 2014 at 12:18 PM, Bill Spitzak wrote:
> I was wondering if my problem is not something anybody else is seeing.
>
> I have Wayland X11 compositor running. This is on an Nvidia
You can see our layers here:
https://git.gnome.org/browse/mutter/tree/src/meta/common.h#n572
On Tue, Feb 4, 2014 at 2:45 AM, Emilio Pozuelo Monfort wrote:
> On 03/02/14 17:14, Emilio Pozuelo Monfort wrote:
> > Hi Bill,
> >
> > On 30/01/14 23:33, Bill Spitzak wrote:
> >> There really should not
On Sun, Feb 2, 2014 at 1:06 AM, Kristian Høgsberg wrote:
> On Sat, Feb 01, 2014 at 09:39:12PM +0100, Quentin Glidic wrote:
> > From: Quentin Glidic
> >
> > Signed-off-by: Quentin Glidic
> > ---
> >
> > v2: Update .gitignore (Thanks Jasper)
>
> I looked into this and I did have generated .c and .
On Thu, Jan 30, 2014 at 9:03 PM, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>
> A simple problem is a floating window shared by two main windows.
>>
>> Can you give a concrete example of such a case? Not because I'm assuming
>> none exist, but beca
On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>
> Hiding windows should not have any influence over the client, as many
>> desktop environments, including Weston, want to show live previews for
>> minimized or hidden windows in alt
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak wrote:
>
> - When the compositor creates a shell_surface having the TOPLEVEL type,
>> it sets a numeral ID for it, and sends a "map" event to the desktop_shell
>> client ;
>>
>
> You must allow a "toplevel" to become a non-toplevel and vice-versa,
>
Reviewed-by: Jasper St. Pierre
On Sun, Jan 19, 2014 at 4:32 AM, Jonas Ådahl wrote:
> Make it clear that multiple requests before commit are allowed and how it
> is handled.
>
> Signed-off-by: Jonas Ådahl
> ---
> protocol/wayland.xml | 4
> 1 file changed, 4 inserti
Yeah, this makes sense.
Reviewed-by: Jasper St. Pierre
On Sun, Jan 19, 2014 at 4:32 AM, Jonas Ådahl wrote:
> Clarify some semantics of wl_subsurface.place_below and
> wl_subsurface.place_below that were not specified.
>
> Signed-off-by: Jonas Ådahl
> ---
>
> Hi,
>
&g
If we respect the ICCCM, we need to map the child window when the client
asks for it to be mapped. If the WM_TRANSIENT_FOR hint specifies an invalid
window, we just ignore it.
Looking through the mutter code, it seems that if we don't recognize a
window specified in WM_TRANSIENT_FOR, we warn and i
Hey,
This came up during the mutter implementation. See my questions here for
what prompted this. I found the proposed phrasing a bit confusing as well...
https://bugzilla.gnome.org/show_bug.cgi?id=705502#c16
On Fri, Jan 17, 2014 at 6:37 AM, Jonas Ådahl wrote:
> On Fri, Jan 17, 2014 at 12:20:
On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres wrote:
> Le 10/01/2014 16:44, Maarten Baert a écrit :
>
> On 10/01/14 14:56, Martin Peres wrote:
>>
>>> Please provide a detailed explanation for that and tell me how likely it
>>> is to ever end up upstream.
>>>
>> If by 'upstream' you mean the ker
On Thu, Jan 9, 2014 at 7:05 PM, Martin Peres wrote:
> On 09/01/2014 23:57, Maarten Baert wrote:
>
>>
>> On 09/01/14 21:54, Martin Peres wrote:
>>
>>> The worse thing that can happen is an application running with the
>>> user's uid grabbing and sending periodical screenshots to a distant server
>
On Thu, Jan 9, 2014 at 3:54 PM, Martin Peres wrote:
> Le 09/01/2014 20:36, Jasper St. Pierre a écrit :
>
> Security is based on trust. If you trust nothing, the computer won't do
>> very much for you. You can't even trust it to compute correctly.
>>
>
>
Security is based on trust. If you trust nothing, the computer won't do
very much for you. You can't even trust it to compute correctly.
What's the threat model here? Let's say that we design a screenshot API,
and in your opinion it's the worst thing ever. Who's attacking? How are
they attacking?
If the user installed an app that takes screenshots of the screen
periodically and dumps them to a disk, I'd imagine that's functionality he
wanted. Why would we prompt him?
On Wed, Jan 8, 2014 at 2:17 PM, Martin Peres wrote:
> Le 08/01/2014 19:47, Jasper St. Pierre a écrit :
&
ck a écrit :
>
> Am 2014-01-08 13:02, schrieb Martin Peres:
>>
>>> On 07/01/2014 20:26, Jasper St. Pierre wrote:
>>>
>>>>
>>>> Would it be ok for you if the compositor asked the user to agree
>>>> for the program to
&
le
Hangouts" so that it could show up as an application that could request
access.
[0] http://www.superlectures.com/guadec2013/more-secure-with-less-security
On Wed, Jan 8, 2014 at 2:34 AM, Pekka Paalanen wrote:
> On Tue, 7 Jan 2014 15:00:31 -0500
> "Jasper St. Pierre&q
On Tue, Jan 7, 2014 at 2:43 PM, Pekka Paalanen wrote:
> On Tue, 7 Jan 2014 14:26:36 -0500
> "Jasper St. Pierre" wrote:
>
> > On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres
> > wrote:
> >
> > > Would it be ok for you if the compositor asked the user
On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres wrote:
> Le 07/01/2014 01:45, Sebastian Wick a écrit :
>
> Am 2014-01-06 19:33, schrieb Martin Peres:
>>
>>> Le 06/01/2014 19:10, Sebastian Wick a écrit :
>>>
Am 2014-01-06 16:05, schrieb Martin Peres:
> As I said before, I think trustin
Sorry if this was discussed before, but any reason this is being put in
Wayland, and in the "wl_" namespace? DMA-BUF is a private Linux kernel
feature that's really semi-stable, not used by all drivers, and I'd hate
for it to bit-rot and tell people not to use it, the same way wl_shell
went. Having
7;s a lot more details, but this might get
you to understand what's going on.
[1] http://wayland.freedesktop.org/architecture.html
http://nouveau.freedesktop.org/wiki/IntroductoryCourse/ - this is a good
> example of getting people involved.
>
> Now I'm ready for starting to dig the
Wayland has a lot of components: the code generator, the protocol, the
client/server lib implementation, the design decisions we made to tie it
all together. Yes, we aren't the greatest at documentation and we know that
a lot is missing, but in general we assume experience with traditional
toolkits
---
desktop-shell/shell.c | 57 ++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 9fbac00..52d82f6 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -176,6 +176,8 @@
On Fri, Dec 13, 2013 at 12:57 PM, Maarten Baert
wrote:
> On 13/12/13 16:01, Martin Peres wrote:
> > I may be wrong, but other unix users shouldn't be able to
> > communicate with another user's compositor unless this
> > user specifically allowed that by adding him to his/her group.
> Okay, then t
Well yes, if you don't load the color management module, you won't get
color management. Seems to be what I'd expect.
On Sun, Dec 1, 2013 at 9:30 PM, Michel Dänzer wrote:
>
> Without loading the cms-colord module, weston never calls
> drmModeCrtcSetGamma(). This means that weston's gamma ramp i
On Fri, Nov 29, 2013 at 7:09 PM, Kristian Høgsberg wrote:
> On Fri, Nov 29, 2013 at 06:41:59PM -0500, Jasper St. Pierre wrote:
> > On Fri, Nov 29, 2013 at 5:43 PM, Kristian Høgsberg >wrote:
> >
> > > On Wed, Nov 27, 2013 at 03:50:17PM -0200, Rafael Antognolli wr
On Fri, Nov 29, 2013 at 5:43 PM, Kristian Høgsberg wrote:
> On Wed, Nov 27, 2013 at 03:50:17PM -0200, Rafael Antognolli wrote:
> > xdg_shell is a protocol aimed to substitute wl_shell in the long term,
> > but will not be part of the wayland core protocol. It starts as a
> > non-stable API, aimed
Wasn't EGLStreams supposed to solve the use case of passing hardware
buffers around in a standard way?
On Wed, Nov 27, 2013 at 1:22 PM, Jason Ekstrand wrote:
>
> On Nov 27, 2013 10:53 AM, "Benjamin Gaignard" <
> benjamin.gaign...@linaro.org> wrote:
> >
> > Hi all,
> >
> > I'm working for Linaro
Is there any reason we can't make vertex-clipping.c take floats everywhere,
and adapt our code to take floats as well? I don't think GLfloat will ever
be a typedef for anything but float...
On Tue, Nov 19, 2013 at 4:52 PM, Emilio Pozuelo Monfort
wrote:
> On 19/11/13 22:21, Kristian Høgsberg wrot
If you (or anyone else) wants to write the code and spec for
Qt/GTK+/EFL/westoy, go for it.
I, personally, am not going to do any engineering effort to implement such
a cross-toolkit theme definition.
On Tue, Nov 19, 2013 at 5:09 AM, Jesse K wrote:
> Hi,
>
> What about having a theme definitio
So, let me be clear:
I'm not fundamentally opposed to any of this. Personally, I feel that
decorations aren't something that we need server-side support for to
establish consistency between apps, and that there's a myriad of other
cross-app consistency bugs and issues that we should solve first (i
ss we get to heads one day). So y do
> one want to have some input processed on the level of compositor and some
> input on the level of a client. So I would assume sort of input linear flow
> (meaning it won't split at some point). And if it's not split on some
> level so
If by libxcbcommon you mean libxkbcommon, no.
libxkbcommon is about the complex ways of interpreting key events, with
client-side key maps, modifiers, accessibility features (latched keys,
sticky keys, etc.). It's meant to be used from both the compositor and the
client.
libinput is about replaci
On Fri, Nov 15, 2013 at 8:07 AM, Alex Elsayed wrote:
> Jasper St. Pierre wrote:
>
> > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
> > wrote:
> >
>
> >
> > I think the trap that I personally don't want to run into is the case
> > where we
5, 2013 at 7:14 AM, Jasper St. Pierre wrote:
> On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin wrote:
>
>> Hi all,
>>
>> this is a reply to the topic of whether to have information about
>> decorations
>> in the xdg_shell at all (see [1]). Sorry that I don
On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin wrote:
> Hi all,
>
> this is a reply to the topic of whether to have information about
> decorations
> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> message, had not been subscribed to the list.
>
> I want to outline why
And as I explained on IRC, I don't want this in an initial dump. The
motivation of this xdg_shell approach is to keep it small and land it now.
We can add functionality later, but I'd rather not spend too much time in
heated discussions on the list about client-side vs. server-side
decorations.
If
any case this looks a lot like you are hiding a bug that perhaps should
> be investigated, especially if it is in weston or your compositor, rather
> than in the toytoolkit.
>
It is not a bug in the compositor. It's a bug in toytoolkit.
Jasper St. Pierre wrote:
>
>>
On Wed, Nov 13, 2013 at 3:36 PM, Bill Spitzak wrote:
> Jasper St. Pierre wrote:
>
> Transient windows, at least not as they are today, don't exist in
>> xdg_shell. Subsurfaces allow for specially placed surfaces relative
>> to a window, so use these instead.
On Wed, Nov 13, 2013 at 3:37 PM, Bill Spitzak wrote:
> Did you see my suggestion that the move and resize requests also be merged?
>
Yes, but I don't see what that has to do with this patch. This is about toy
toolkit cleanup...
> Jasper St. Pierre wrote:
>
>> It
On Wed, Nov 13, 2013 at 12:01 AM, wuzhiwen wrote:
> Hi all,
> I am trying to enabling sprites for drm-backend on Intel Tizen IVI platform
> using Intel Gen Graphic, and found a commit (de37d67ac5a3d6, Fri Nov 2
> 10:14:40 2012) which always disable sprites by setting "sprites_are_broken
> =
> 1".
A bug in Weston's toytoolkit gave me an hour of debugging headaches.
Improve the error messages that we send if a client requests an invalid
global, either by name or by version.
---
src/wayland-server.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/wayland-ser
---
protocol/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/protocol/.gitignore b/protocol/.gitignore
index a67e944..78f49d2 100644
--- a/protocol/.gitignore
+++ b/protocol/.gitignore
@@ -1 +1,2 @@
wayland.html
+.wayland.xml.valid
--
1.8.4.2
_
These aren't supported under xdg_shell, at least not right now.
If xdg_shell ever gets support for them, we can revert this commit
and adapt it.
---
clients/fullscreen.c | 19 +++
clients/transformed.c | 21 +
clients/window.c | 11 +--
clients/win
If a client adds a subsurface, we need to make sure it's allocated
properly, so queue a resize and redraw on the parent window.
---
clients/window.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/clients/window.c b/clients/window.c
index 5a1c8ec..df56bd9 100644
--- a/clients/window.c
+++ b
Transient windows, at least not as they are today, don't exist in
xdg_shell. Subsurfaces allow for specially placed surfaces relative
to a window, so use these instead.
---
clients/window.c | 47 ---
1 file changed, 8 insertions(+), 39 deletions(-)
diff
_shell and
wl_shell_surface directly. I have not ported these over for now, and
I'm not really going to port them over in the near future. Maybe in
a month or two...
Jasper St. Pierre (8):
westoy: Remove window_touch_move
westoy: Remove unused support for window parents
westoy: Use
It seems to be the same as window_move, except it ignores the passed
in serial (???) and instead just uses the one of the display.
---
clients/flower.c | 3 +--
clients/fullscreen.c | 3 +--
clients/transformed.c | 3 +--
clients/window.c | 10 --
clients/window.h | 2 -
We want to remove support for these deprecated interfaces. Since
nothing is using them, this is a simple change.
---
clients/window.c | 12
clients/window.h | 6 --
2 files changed, 18 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 0e5fce2..29ca42d 100644
--
It seems that this was only used by the popup menu infrastructure,
which can handle this all on its own. Implementing e.g. transients
in the future can be done with a simple xdg_shell_set_transient_for.
---
clients/image.c| 2 +-
clients/terminal.c | 2 +-
clients/view.c | 2 +-
clients
xdg_shell changes this around so that they are flags on the remote
object itself, not separate surface types. Move to a system where
we calculate the state from the flags ourselves and set the appropriate
wl_shell_surface type.
When we port to xdg_shell, we'll drop these flags and simply sync
on t
sitor_destroy(display->subcompositor);
- if (display->shell)
- wl_shell_destroy(display->shell);
+ if (display->xdg_shell)
+ xdg_shell_destroy(display->xdg_shell);
if (display->shm)
wl_shm_destroy(display->shm);
d
emented in xdg_shell when
that time comes.
I fully intend to support the three major focus modes (click-to-focus,
sloppy focus, FFM) in mutter, for both X and Wayland clients, as our
customers require it.
On Mon, Nov 11, 2013 at 1:23 PM, Gregory Merchan
wrote:
> On Fri, Nov 8, 2013 at 3:29 PM
ile mode 100644
> index 000..66b8d29
> --- /dev/null
> +++ b/protocol/xdg-surface.xml
> @@ -0,0 +1,378 @@
> +
> +
> +
> +
> +Copyright © 2008-2013 Kristian Høgsberg
> +Copyright © 2013 Rafael Antognolli
> +Copyright © 2013 Jasper S
On Sat, Nov 2, 2013 at 11:50 AM, Jason Ekstrand wrote:
> On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre
> wrote:
>
>> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand wrote:
>>
>> ... snip
>>
>>
>>> Gregory,
>>> Thank you very much for
On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand wrote:
... snip
> Gregory,
> Thank you very much for your e-mail. I think that helps a lot. The lack
> of code is ok because I think Rafael is planning to start implementing as
> soon as things settle a bit. Sometimes protocol discussions can en
301 - 394 of 394 matches
Mail list logo
