On Tue, 28 Sep 2010 10:36:45 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > then why not just use xgrabserver during the "security sensitive" time to
> > lock out all other clients... though composite manager will be locked out.
> > u wont see any rendering on th
Carsten Haitzler (The Rasterman) writes:
> then why not just use xgrabserver during the "security sensitive" time to lock
> out all other clients... though composite manager will be locked out. u wont
> see any rendering on the screen then. :) so u may have a custom solution just
That is a good q
On Tue, 28 Sep 2010 07:13:46 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > do you have a cm? (composite manager) - sure. if you steal focus from the
> > wm's manageme3nt by doing it via another client pipe - yes. u can get
> > focus. wm is still hung. u cant mov
Carsten Haitzler (The Rasterman) writes:
> do you have a cm? (composite manager) - sure. if you steal focus from the wm's
> manageme3nt by doing it via another client pipe - yes. u can get focus. wm is
> still hung. u cant move, resize, restack or do anything else.
No I'm not using a cm. And I'm
On Tue, 28 Sep 2010 00:58:52 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > ugh! horrible usability. one should not rely on vt switching as a
>
> Agreed, this needs to be resolved.
>
> >> The xterm spawned by root can still be used. It is ok in my use case
> >>
Carsten Haitzler (The Rasterman) writes:
> ugh! horrible usability. one should not rely on vt switching as a
Agreed, this needs to be resolved.
>> The xterm spawned by root can still be used. It is ok in my use case
>> that it is not possible to move/resize this SAK "menu".
>
> it can only be us
On Mon, 27 Sep 2010 17:01:24 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > 1. if user client does an xgrab(server/keyboard/pointer) and u stop socat
> > before the grab is released.. you're SOL. a "race condition" or more a
> > "state condition" you havent accou
Carsten Haitzler (The Rasterman) writes:
> 1. if user client does an xgrab(server/keyboard/pointer) and u stop socat
> before the grab is released.. you're SOL. a "race condition" or more a "state
> condition" you havent accounted for.
It seems that ctrl-alt-/ is enough to kill such a grab. At le
On 09/27/2010 05:36 PM, Timo Juhani Lindfors
wrote:
> 3) show-window is just a quick'n'dirty helper application to make the
> xterm visible:
alternatively, how about
xterm -xrm 'XTerm.overrideRedirect: true' -geometry 100x100+100+100
and
XSetInputFocus (dpy, PointerRoot, RevertToPointerRoot
Julien Cristau writes:
> That doesn't quite work for abstract domain sockets though?
Aha, good catch! Indeed it doesn't. Is there any way to configure Xorg
to not listen on those?
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.free
On Mon, Sep 27, 2010 at 18:11:04 +0300, Timo Juhani Lindfors wrote:
> Julien Cristau writes:
> > Sorry if I missed it, but what prevents normal users from connecting
> > to :1 directly?
>
> chmod og-rwx /tmp/.X11-unix/X1
>
> (I forgot this from the email indeed.)
That doesn't quite work for ab
Julien Cristau writes:
> Sorry if I missed it, but what prevents normal users from connecting
> to :1 directly?
chmod og-rwx /tmp/.X11-unix/X1
(I forgot this from the email indeed.)
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.f
On Mon, Sep 27, 2010 at 16:13:34 +0300, Timo Juhani Lindfors wrote:
> Carsten Haitzler (The Rasterman) writes:
> > logged in user is king. you'd have to modify the xserver itself to have
> > such a
> > separation and provide a back-channel that can only be accessed by root to
> > implement what
Carsten Haitzler (The Rasterman) writes:
> 1. if user client does an xgrab(server/keyboard/pointer) and u stop socat
> before the grab is released.. you're SOL. a "race condition" or more a "state
> condition" you havent accounted for.
A possible solution is to just revert to the old "switch to a
On Mon, 27 Sep 2010 16:13:34 +0300 Timo Juhani Lindfors
said:
ok. this, though it seems to work for you, will have problems. though an
interesting hack and i'm glad you were inspired! i'm so happy to see the
"scratch an itch" thing still alive. :) problems you have.
1. if user client does an xgr
Carsten Haitzler (The Rasterman) writes:
> logged in user is king. you'd have to modify the xserver itself to have such a
> separation and provide a back-channel that can only be accessed by root to
> implement what you want. reality otherwise is that any x client can kill off
Thank you, this dis
On Fri, 24 Sep 2010 11:10:45 +0200 Eeri Kask
said:
> On 09/23/2010 04:43 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 23 Sep 2010 15:40:47 +0200 Eeri Kask
> > said:
> >> No I don't, though it looks like the current server implementation
> >> only ensures WMs have no advantage in know
On 09/23/2010 04:43 PM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 23 Sep 2010 15:40:47 +0200 Eeri Kask
> said:
>> No I don't, though it looks like the current server implementation
>> only ensures WMs have no advantage in knowing something about their
>> geometrical structure '_in_advance
On Thu, 23 Sep 2010 18:19:16 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > luck. in the x11 world access gets flattened. the user is pretty much king.
>
> That's the impression I've unfortunately got too.
>
> > my suggestions is to stand back and totally rethi
Carsten Haitzler (The Rasterman) writes:
> luck. in the x11 world access gets flattened. the user is pretty much king.
That's the impression I've unfortunately got too.
> my suggestions is to stand back and totally rethink what you are
> trying to do.
I have several different use cases but main
On Thu, 23 Sep 2010 15:40:47 +0200 Eeri Kask
said:
> On 09/23/2010 03:06 PM, Carsten Haitzler (The Rasterman)
> wrote:
> >> BTW, as most WMs also deal with input focus management,
> >> and as most WMs wrongly ignore OverrideRedirect windows
> >> in practise, you have to forcefully 'recover' focu
On Thu, 23 Sep 2010 16:53:37 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > modules/plugins at least in enlightenment (0.17 devel) can let you do just
> > about anything as they run inside the wm and have all privileges the wm
> > enjoys.
>
> Thanks for the hint
Eeri Kask wrote:
> > wrongfully ignore override-redirect? they have little choice.
> > x11 core has defined that they are to bypass the wm.
> > no map redirects for them. dont blame wm's.
>
> No I don't, though it looks like the current server implementation
> only ensures WMs have no advantage
Carsten Haitzler (The Rasterman) writes:
> modules/plugins at least in enlightenment (0.17 devel) can let you do just
> about anything as they run inside the wm and have all privileges the wm
> enjoys.
Thanks for the hints. However, if the window manager runs as normal
user then normal user can
On 09/23/2010 03:06 PM, Carsten Haitzler (The Rasterman)
wrote:
>> BTW, as most WMs also deal with input focus management,
>> and as most WMs wrongly ignore OverrideRedirect windows
>> in practise, you have to forcefully 'recover' focus too
>> on each FocusOut event... the same you raise the windo
On Thu, 23 Sep 2010 14:40:11 +0200 Eeri Kask
said:
> On 09/21/2010 09:00 PM, Adam Jackson wrote:
> >On Wed, 2010-09-15 at 15:49 -0600, Burton Samograd wrote:
> >> I'm looking for a way to create a full screen window that is
> >> 'always on top' no matter what is currently running. I am
> >> cur
On Thu, 23 Sep 2010 15:08:10 +0300 Timo Juhani Lindfors
said:
> Carsten Haitzler (The Rasterman) writes:
> > in the end what you want requires either the wm+cm implements it - or it
> > supports it specifically. it's all about mechanism not policy in x11 and in
> > x11 the wm+cm (wm in older day
On 09/21/2010 09:00 PM, Adam Jackson wrote:
>On Wed, 2010-09-15 at 15:49 -0600, Burton Samograd wrote:
>> I'm looking for a way to create a full screen window that is
>> 'always on top' no matter what is currently running. I am
>> currently using a standard window with OverrideRedirect set
>> tha
Carsten Haitzler (The Rasterman) writes:
> in the end what you want requires either the wm+cm implements it - or it
> supports it specifically. it's all about mechanism not policy in x11 and in
> x11
> the wm+cm (wm in older days alone) define such policies.
I don't know what Burton's original m
On Tue, 21 Sep 2010 09:40:44 -0400 Adam Jackson said:
> On Wed, 2010-09-15 at 15:49 -0600, Burton Samograd wrote:
> > Hello,
> >
> > I'm looking for a way to create a full screen window that is 'always on
> > top' no matter what is currently running. I am currently using a
> > standard window w
On Wed, 2010-09-15 at 15:49 -0600, Burton Samograd wrote:
> Hello,
>
> I'm looking for a way to create a full screen window that is 'always on
> top' no matter what is currently running. I am currently using a
> standard window with OverrideRedirect set that raises itself every few
> seconds, whi
Hello,
I'm looking for a way to create a full screen window that is 'always on
top' no matter what is currently running. I am currently using a
standard window with OverrideRedirect set that raises itself every few
seconds, which works in pretty much all cases that I need it to except
when the us
32 matches
Mail list logo
