On 2018/7月/11 09:42, Sichem Zhou wrote:
> Hi All,
>
> I have a question related to the wl_client creation in the compositor. I
> followed these step like weston did:
>
> 1. create socketpair.
> 2. fork a process and close `socket[0]` in child, close `socket[1]` in in
> parent process.
> 3. set th
On 2018/July/13 05:40, Simon Ser wrote:
> This new function allows listeners to remove themselves or any
> other listener when called. This version only works if listeners
> are properly cleaned up when the wl_signal is free'd.
This is about free()ing the wl_listener in the actual handler, not the
On 2018/7月/05 04:26, David Edmundson wrote:
> 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
ether the supplied whitelist approach is the best way to
go, or this should be a blacklist in practice.
On 2018/6月/29 10:43, w...@ongy.net wrote:
> From: Markus Ongyerth
>
> Add environment variable WAYLAND_DEBUG_INTERFACES for filtering the
> output of WAYLAND_DEBUG logs.
> Whil
Hi,
I once again seem to be missing the original message for some reason, so if I
failed to properly fix up my headers again, I'm refering to [1]
Reviewed-By: Markus Ongyerth
[1] https://patchwork.freedesktop.org/patch/204915/
Cheers,
ongy
signature.asc
Description: PGP sign
On 2018/6月/22 08:00, Dorota Czaplejewicz wrote:
> On Fri, 22 Jun 2018 12:36:16 -0400
> Simon Ser wrote:
>
> > On June 22, 2018 4:20 PM, Dorota Czaplejewicz
> > wrote:
> > > Provides the ability to emulate keyboards by applications. Complementary
> > > to input-method protocol.
> > >
> > > The
On 2018/6月/19 01:39, Simon McVittie wrote:
> On Tue, 19 Jun 2018 at 13:56:22 +0200, Markus Ongyerth wrote:
> > P.S. I just thought about this ab it more, and something else came to my
> > mind:
> > How is env passed with dbus activation? afaik the session bus does not run
On 2018/6月/19 01:22, Simon McVittie wrote:
> On Tue, 19 Jun 2018 at 11:18:17 +0200, Markus Ongyerth wrote:
> > On 2018/6月/18 05:05, Roman Gilg wrote:
> > > * using D-Bus interface only to secure against sandboxed clients
> > What? Why exactly? When I first read this, I exp
On 2018/6月/19 11:18, Markus Ongyerth wrote:
> Hey Roman,
>
> first a general remark:
> I don't see any mention of which state is supposed to be restored. The
> workspace (virtual desktops), geometry (session-restore), just client-side
> window (the embedded u
Hey Roman,
first a general remark:
I don't see any mention of which state is supposed to be restored. The
workspace (virtual desktops), geometry (session-restore), just client-side
window (the embedded usecase)?
Is this left implementation-defined intentionally? If so, I think it would be
nice
On 2018/5月/18 07:23, roderick.colenbran...@sony.com wrote:
> Hi Dorota,
>
> Thanks for sharing your proposal. Ourselves we have interest in this
> kind of capability as well. Looking at our own use cases, I wonder if
> this proposal goes far enough.
>
> We are basically interested in the abilit
On 2018/5月/11 10:12, Peter Hutterer wrote:
>
> > Never the less, a few pointers to the varlink approach from my side:
> > From your quick outline in the mail, I asume you plan to have the varlink
> > fd
> > libinput owned? I don't think that fits the current scope of libinput (or
> > that
> >
A quick glance at varlink makes me like it more than dbus, but I'm not sure
it's the best choice to provide debug information about libinput configuration
in compositors.
All compositors I'm aware of, provide an IPC method for some (more or less)
internals. GNOME (and afaik KDE) have dbus, sway
Hi, butting in
On 2018/May/08 04:17, Daniel Stone wrote:
>
> > [... details snipped ...]
> >
> > These ideas are still somewhat nebulous but I'm confident enough that
> > it'll work that I think we can proceed with the discussion on protocols
> > like layer-shell. Compositors which are interested
Hi,
thanks for the feedback, I'll provide a v3 shortly.
I just have a few follow up questions, before I do so.
On 2018/April/27 04:55, Peter Hutterer wrote:
> On Thu, Apr 26, 2018 at 05:01:23PM +0200, w...@ongy.net wrote:
> > From: Markus Ongyerth
> >
> &
3
shows. But I don't think that's a deal breaker.
For Patch 1/2:
Reviewed-by: Markus Ongyerth
I'm fine with moving/resubmit of my code and am happy I could provide the
testcase that shows an issue.
Since it's originally authored by me, I guess my R-B would be weird there :)
aying 'but the clients
> never asked _not_ to be decorated' wouldn't really help you get out of
> it either.
Which is in a specialised environment that usually wants no deco (probably
fullscreen shell by default etc.) but may run xdg-shell for reasons.
On 2018/3月/18 03:40, Markus
On 2018/3月/18 01:45, Daniel Stone wrote:
> Hi Drew,
>
> On 15 March 2018 at 16:53, Drew DeVault wrote:
> >> > In fact, I have done so. Before we started working on this protocol,
> >> > Sway did exactly this. We have provided users the means of overriding
> >> > the approach to decorations, inclu
On 2018/3月/18 10:50, Eike Hein wrote:
>
>
> On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has
> always - well, until you got the patches
> > for this protocol merged a month or two ago - decorated its own
> > windows under Wayland. Same with Qt. Same with EFL. These are too
On 2018/2月/26 08:58, Mike Blumenkrantz wrote:
> for a variety of cases it's desirable to have a method for negotiating
> the restoration of previously-used states for a client's windows. this
> helps for e.g., a compositor/client crashing (definitely not due to
> bugs) or a backgrounded client deci
On 2018/2月/23 08:53, Derek Foreman wrote:
> On 2018-02-23 07:44 AM, Markus Ongyerth wrote:
> > On 2018/2月/23 07:31, Derek Foreman wrote:
> > > On 2018-02-23 03:52 AM, w...@ongy.net wrote:
> > > > From: Markus Ongyerth
> > > >
> > > > This is
On 2018/2月/23 07:31, Derek Foreman wrote:
> On 2018-02-23 03:52 AM, w...@ongy.net wrote:
> > From: Markus Ongyerth
> >
> > This is related to the discussion earlier on the mailing list and
> > demonstrates a problem with current wl_priv_signal_emit and wl_listener
&g
Hi, I have a v2 RFC _emit_final based on your idea.
It passes `make check` of libwayland and weston.
It also passes the remove-without-free test I sent in another mail.
---
(This patch isn't quite intended to be merged, but to get feedback on
the approach)
This adds a wl_priv_signal_emit_final a
On 2018/2月/22 12:31, Derek Foreman wrote:
> On 2018-02-22 10:48 AM, Markus Ongyerth wrote:
> > On 2018/2月/22 09:34, Derek Foreman wrote:
> > > On 2018-02-22 08:58 AM, Daniel Stone wrote:
> > > > Hi,
> > > >
> > > > On 22 February 2018 at 14
On 2018/2月/22 04:53, Daniel Stone wrote:
> Hi ongy,
>
> On 22 February 2018 at 16:03, Markus Ongyerth wrote:
> > On 2018/2月/22 02:58, Daniel Stone wrote:
> >> On 22 February 2018 at 14:14, Markus Ongyerth wrote:
> >> > The code was buggy the whole time.
On 2018/2月/22 09:34, Derek Foreman wrote:
> On 2018-02-22 08:58 AM, Daniel Stone wrote:
> > Hi,
> >
> > On 22 February 2018 at 14:14, Markus Ongyerth wrote:
> > > > It seems that this patch makes that assumption invalid, and we would
> > > > need pa
On 2018/2月/22 02:58, Daniel Stone wrote:
> Hi,
>
> On 22 February 2018 at 14:14, Markus Ongyerth wrote:
> >> It seems that this patch makes that assumption invalid, and we would
> >> need patches to weston, enlightenment, and mutter to prevent a
> >> use-aft
> Since a destroy signal inidicates the object is utterly dead, I don't think
> it's unreasonable for users to have assumed that they don't have to clean up
> their listener link. It's *never* going to fire again, so why should
> anything need to be removed?
This only implies that the signal
28 matches
Mail list logo