Seema Singh wrote:
Focus window pid is used for below check:
1. If focus window APP is not a NFC APP then launch the NFC APP
2. If already launched but not in focus then bring it to foreground.
The NFC app should always launch, but then it should just check if it is
already running, and if so
On Fri, 21 Feb 2014 06:07:59 + (GMT) Seema Singh
said:
> Hi Carsten,
>
> Thank you for your response.
>
> >first... by module... what does this code do? is it an enlightenment module?
> >or is it some external client process?
>
> it's not an enlightenment module. It's an external client pr
Hi Carsten,
Thank you for your response.
>first... by module... what does this code do? is it an enlightenment module? or
>is it some external client process?
it's not an enlightenment module. It's an external client process.
>so maybe you should first explain what you are doing, where and why
On 20/02/14 12:07, Pekka Paalanen wrote:
Hi Mario,
Ok, now i am magically subscribed. Thanks to the moderator!
I have replies to your comments below, but while reading what you said,
I started wondering whether Wayland would be good for you after all.
It seems that your timing sensitive exp
On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote:
> 20.02.2014 12:21, I wrote:
> >20.02.2014 11:14, Peter Hutterer wrote:
> >>On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote:
> >>> From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
> >>>sa
Em qui 20 fev 2014, às 14:34:39, Bill Spitzak escreveu:
> This makes it impossible for a privileged client to distribute it's
> privledges to more than one subprocess, or to both itself and a subprocess.
I think it's fine. That's hardly a common scenario.
To allow distribution of security setting
This makes it impossible for a privileged client to distribute it's
privledges to more than one subprocess, or to both itself and a subprocess.
That is why I would prefer an "id" approach, which I still think would
be a good way for parent processes to send objects to children, even if
it is n
On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > > Now, the privileged process wants to launch a sub-process. How will the
> > > sub- process connect to the compositor? Remember: WAYLAND_SOCKET
> contains
> > > a file descriptor
Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > Now, the privileged process wants to launch a sub-process. How will the
> > sub- process connect to the compositor? Remember: WAYLAND_SOCKET contains
> > a file descriptor number that isn't available to the child process.
>
> Ah, I see. Y
Le 20/02/2014 21:26, Thiago Macieira a écrit :
Em qui 20 fev 2014, às 19:56:08, Martin Peres escreveu:
Le 20/02/2014 18:42, Thiago Macieira a écrit :
Unless you meant that the WAYLAND_SOCKET variable can contain a file
descriptor number. Is that the case? In that case, how should the
privileged
Em qui 20 fev 2014, às 19:56:08, Martin Peres escreveu:
> Le 20/02/2014 18:42, Thiago Macieira a écrit :
> > Unless you meant that the WAYLAND_SOCKET variable can contain a file
> > descriptor number. Is that the case? In that case, how should the
> > privileged process clear the environment to all
Le 20/02/2014 20:43, Sebastian Wick a écrit :
Am 2014-02-20 20:02, schrieb Martin Peres:
Le 20/02/2014 13:04, Pekka Paalanen a écrit :
snip
It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing that
is always a fatal
Am 2014-02-20 20:02, schrieb Martin Peres:
Le 20/02/2014 13:04, Pekka Paalanen a écrit :
snip
It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing
that
is always a fatal error, which terminates the client connectio
20.02.2014 12:21, I wrote:
20.02.2014 11:14, Peter Hutterer wrote:
On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote:
From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synapt
Le 20/02/2014 13:04, Pekka Paalanen a écrit :
On Wed, 19 Feb 2014 17:11:03 +0100
Martin Peres wrote:
Hi Guys,
Following to the giant and impossible to read "Authorized clients"
thread, I said I would take the time and write everything we talked
about down, for convenience and to check I took
Le 20/02/2014 18:42, Thiago Macieira a écrit :
Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor
number. Is that the case? In that case, how should the privileged process
clear the environment to allow child processes to be launched?
Yes, it takes an FD as a paramete
Em qui 20 fev 2014, às 14:04:42, Pekka Paalanen escreveu:
> FWIW, Weston already does track its children by pid also, so that it
> can respawn them as needed if they e.g. crash.
Some compositors may take advantage of an external process launcher &
babysitter, like systemd --user.
> > A simpler a
Hi,
I've checked how it would behave when X closes properly,
and I think xwl_screen_close would need a new flush after the roundtrip:
. first flush: the server knows the wl_surface was destroyed
. dispatch: X gets the release
. missing flush: the server knows the wl_buffer has been destroyed.
Mo
On Wed, 19 Feb 2014 17:11:03 +0100
Martin Peres wrote:
> Hi Guys,
>
> Following to the giant and impossible to read "Authorized clients"
> thread, I said I would take the time and write everything we talked
> about down, for convenience and to check I took everyone's idea and
> needs into acc
On Thu, 20 Feb 2014 11:43:05 +0100
Rui Matos wrote:
> Destroying a wl_buffer that is still attached to a wl_surface is
> undefined behavior according to the wayland protocol. We should delay
> the destruction until we get the release event.
>
> To achieve this we need to track ownership of wl_bu
Hi Mario,
I have replies to your comments below, but while reading what you said,
I started wondering whether Wayland would be good for you after all.
It seems that your timing sensitive experiment programs and you and
your developers use a great deal of effort into
- detecting the hardware and d
Hi,
To add another use-case of wl_text_input protocol, I started a small
hack that enables XIM-based applications to use Wayland input methods:
https://github.com/ueno/xim-wayland
It runs as a standalone XIM server and translates between those
protocols. A screenshot using weston-keyboard on xte
Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.
To achieve this we need to track ownership of wl_buffers, both our own
and the compositor's which occurs from eithe
On Thu, 20 Feb 2014 09:12:50 + (GMT) Seema Singh
said:
> Hi All,
>
> In our module we have used the below mentioned ecore_x APIs.
> 1.ecore_x_window_focus_get()
> 2.ecore_x_netwm_pid_get()
>
> We are planning to move to wayland platform. But could not find the below
> APIs in ecore_wayla
Hi Semma,
Those APIs do not exist inside Ecore_Wayland yet. There is no concept of
NetWM in wayland yet so that API was never added. Getting the current
window which has focus would depend on the current shell. Due to not
wanting Ecore_Wayland to be tied to any specific shell, that API was not
Hi All,
In our module we have used the below mentioned ecore_x APIs.
1.ecore_x_window_focus_get()
2.ecore_x_netwm_pid_get()
We are planning to move to wayland platform. But could not find the below APIs
in ecore_wayland.h file
Please let me know if anyone has come across the same issue.
Than
Mark Thomas wrote:
>
> As part of my current attempts to get MATE fully working on Wayland, I was
> planning to take a look at porting mate-panel this weekend. However, I
> pretty quickly hit the first snag, which is that Gtk on Wayland doesn't
> support the GtkSocket/GtkPlug interface, which ma
27 matches
Mail list logo
