[9fans] Plan9Ports libdraw open-in-same-window

[9fans] Plan9Ports libdraw open-in-same-window

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a patch to libdraw that makes graphical applications open in
the window that invoked them, as in Plan 9.  I've added a "window"
command, and it all seems to work pretty well, at least with rio as
my WM (my window program isn't ICCCM compliant, and I really don't
know or want to know enough X11 to fix it).  I'm also using a little
hack new-namespace script to generate new namespaces on demand and
propagate the parent namespace sockets to it (thanks to Eric
Quanstrom for the suggestion on how to make them nicely
hierarchical).  Does anybody want these?  I'd love for someone with a
different usage pattern than me to try them out.

On a possibly related note, I use synergy to manage my mouse pointer
from my mac to my linux box (which is running my dev environment).
Every time I switch screens it propagates my cut buffer to X11.
Sometimes the buffer contains object acme doesn't understand, and it
generates an error message.  If the window those messages are going
to isn't set to scroll it eventually freezes until I scroll down or
make the window scroll.  What's the right way to fix that?  (this is
particularly disastrous if you opened acme in the 9term window this
output is going to - there is no way to set the 9term to scroll, and
it won't let me save my work.)

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEEJ/MpJeHo/Fbu1wRArV1AJ9EX7zHXKye0NADu52X5f9msWaJlACfcTWJ
/r4r8FGNTDuZBT719adglDQ=
=ceOP
-----END PGP SIGNATURE-----

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> I have a patch to libdraw that makes graphical applications open in
> the window that invoked them, as in Plan 9.  I've added a "window"

Even if you're not using a 9term to invoke them?

> make the window scroll.  What's the right way to fix that?  (this is
> particularly disastrous if you opened acme in the 9term window this
> output is going to - there is no way to set the 9term to scroll, and
> it won't let me save my work.)

Presumably there should be a way to make 9term scroll
while its window has been taken over.  But you could
just silence the error message instead.  What is generating
the error message?

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't know what you mean by even when not using 9term.  For an
example of use: in a win in acme I call perforce with EDITOR=sam; sam
takes over my acme window until I'm done, as expected.  Can you give
me an example?

  I didn't go hack a rio to run in a window, though - it's not a
libdraw tool under p9p.

The acme errors that spew are of the flavour:
/home/plalonde/plan9/bin/acme: cannot handle selection request for
'text/plain;charset=UTF-8' (239)

and happen when X11 gets a selection passed to it by synergy (the
multi-computer mouse/keyboard sharing tool).

Paul

On 9-Mar-06, at 1:40 PM, Russ Cox wrote:

>> I have a patch to libdraw that makes graphical applications open in
>> the window that invoked them, as in Plan 9.  I've added a "window"
>
> Even if you're not using a 9term to invoke them?
>
>> make the window scroll.  What's the right way to fix that?  (this is
>> particularly disastrous if you opened acme in the 9term window this
>> output is going to - there is no way to set the 9term to scroll, and
>> it won't let me save my work.)
>
> Presumably there should be a way to make 9term scroll
> while its window has been taken over.  But you could
> just silence the error message instead.  What is generating
> the error message?
>
> Russ
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEEKp7pJeHo/Fbu1wRAv6aAKCuvWGc5KiRo3NvpVxk2XjsXgOogQCdETOs
TbrNt+ibVcAFDaGLv4ZcNk4=
=yJFB
-----END PGP SIGNATURE-----

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> I don't know what you mean by even when not using 9term.  For an
> example of use: in a win in acme I call perforce with EDITOR=sam; sam
> takes over my acme window until I'm done, as expected.  Can you give
> me an example?

If I start an xterm, and then I run acme from the shell inside
that xterm, does acme take over the xterm window?
What happens if I run "acme &"?

> The acme errors that spew are of the flavour:
> /home/plalonde/plan9/bin/acme: cannot handle selection request for
> 'text/plain;charset=UTF-8' (239)

That's an unexpected name.  But okay.  Fixed in libdraw.

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 9-Mar-06, at 4:38 PM, Russ Cox wrote:
> If I start an xterm, and then I run acme from the shell inside
> that xterm, does acme take over the xterm window?
> What happens if I run "acme &"?

I doesn't work there.  I'll poke at it some more :-)
That said, the hack is cheesy - set WINDOW_ID to the X11 window id
and it works.
I've not yet found an automated way to discover the id of the current
window (rio would know it, but I've not dug there).
I'll poke at it some more in my copious spare time.

>
> That's an unexpected name.  But okay.  Fixed in libdraw.
Thanks!

Paul


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEEM+opJeHo/Fbu1wRAi3gAJ98gCr/H+CEH6R4NDfhEvQa/VKoygCfRvmm
spyzhtu7OGT6uW1E75ntPms=
=s3Cn
-----END PGP SIGNATURE-----

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

If I run sam from inside acme, how does acme know
not to draw over sam's screen?  Does sam get a new
X11 drawable that is above acme's?

(For example, if I run sam inside acme and then in
a separate window I run B /etc/passwd, presumably
both sam and acme would try to display the file.)

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah, I see now.  I'll go think on it some more, and write some more
code (can't have one without the other!)

I've been recycling the drawable, but I need to keep a cross-process
lock there; what's a good way to keep a lock in P9P?

Paul

On 9-Mar-06, at 5:14 PM, Russ Cox wrote:

> If I run sam from inside acme, how does acme know
> not to draw over sam's screen?  Does sam get a new
> X11 drawable that is above acme's?
>
> (For example, if I run sam inside acme and then in
> a separate window I run B /etc/passwd, presumably
> both sam and acme would try to display the file.)
>
> Russ
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEEO86pJeHo/Fbu1wRAoM7AJoDwF+eFWvlXtUnDph24K2VHaAyqACfRQN3
06Xq4/rXFNkP9qyBAQzfZQA=
=9m3V
-----END PGP SIGNATURE-----

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> I've been recycling the drawable, but I need to keep a cross-process
> lock there; what's a good way to keep a lock in P9P?

I don't know how you keep a cross-process lock anywhere.

In Plan 9, rio provides the terminal windows - there is no 9term.
If an app opens /dev/mouse (which rio provides), then rio knows
an app is taking over the window and stops doing the terminal
things for that window.  You can't run sam inside acme - only
one program can open /dev/mouse at a time.

I'm less worried about sam inside acme than I am about
programs fighting over windows because of lack of coordination.
It sounds like this requires significant coordination between
the programs.

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> I've been recycling the drawable, but I need to keep a cross-process
> lock there; what's a good way to keep a lock in P9P?

I didn't answer this.  I don't know how to do a cross-process lock.
Perhaps you could create a temporary file and fcntl lock it.

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Makes me dislike X11's design even more.  My "solution" works well
enough for libdraw apps, but falls apart in the presence of standard
X11.  Grump.

Paul

On 9-Mar-06, at 7:34 PM, Russ Cox wrote:

>> I've been recycling the drawable, but I need to keep a cross-process
>> lock there; what's a good way to keep a lock in P9P?
>
> I don't know how you keep a cross-process lock anywhere.
>
> In Plan 9, rio provides the terminal windows - there is no 9term.
> If an app opens /dev/mouse (which rio provides), then rio knows
> an app is taking over the window and stops doing the terminal
> things for that window.  You can't run sam inside acme - only
> one program can open /dev/mouse at a time.
>
> I'm less worried about sam inside acme than I am about
> programs fighting over windows because of lack of coordination.
> It sounds like this requires significant coordination between
> the programs.
>
> Russ
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEEP/fpJeHo/Fbu1wRAj2XAJ0V9LORlIWta6YSiPuhEdbw+PKksgCeI7qX
s+LFHSr1tRIMW3ZIh2W/YOA=
=U+Ht
-----END PGP SIGNATURE-----

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Bruce Ellis]

20 year old technology.  it just works in inferno.

brucee

On 3/10/06, Russ Cox <rsc@swtch.com> wrote:
> > I've been recycling the drawable, but I need to keep a cross-process
> > lock there; what's a good way to keep a lock in P9P?
>
> I didn't answer this.  I don't know how to do a cross-process lock.
> Perhaps you could create a temporary file and fcntl lock it.
>
> Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[erik quanstrom]

semctl(2) is probablly the cleanest way on unix. if things really
get hosed, you can use ipcrm to get rid of the semaphore.
i've never had success with unix locking /really/ working.

however, i think the way to address this (and get what paul's after)
is to split src/libdraw/devdraw.c into two parts. _drawmsgwrite
would really write to "/dev/draw" (a p9p filesystem living in
$NAMESPACE like $NAMESPACE/devdraw.$WINDOWID).
access to the mouse and keyboard would need to be similarly
multiplexed.

window(1) could then provide "/dev/{draw,mouse,cons,consctl,label}";
so rio could run this to start a 9term:

#!/usr/local/bin/rc
WINDOWID=`{window}
if (~ $#WINDOWID 1)
	exec the.9term
exit 1

the upside of all this is that window and rio would be the only programs
linked against X. the downside would be extra 9p traffic.

- erik

"Russ Cox" <rsc@swtch.com> writes

|
| > I've been recycling the drawable, but I need to keep a cross-process
| > lock there; what's a good way to keep a lock in P9P?
|
| I didn't answer this.  I don't know how to do a cross-process lock.
| Perhaps you could create a temporary file and fcntl lock it.
|
| Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> 20 year old technology.  it just works in inferno.

There are a lot of things that just work in Inferno.
Unfortunately Plan 9 from User Space is not about
running on top of Inferno.

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> the upside of all this is that window and rio would be the only programs
> linked against X. the downside would be extra 9p traffic.

and requiring libthread (for lib9pclient) to write a gui program.
i'm not thrilled about that.  also, i did something similar before
with the windows port attempt, and it was very annoying when
the devdraw-like server would crash and take everything with it.

russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[erik quanstrom]

i agree that requiring libthread would be a downside.
however, there are few p9p programs which libdraw and are still
single threaded. i did a little search and came up with these:

	scat, proof, plot, page, htmlfmt, jpg/*

they might not even need modification to work.

to make X happy, you'd want a 1:1 correspondence
between devdraw servers and windows. then if the
devdraw-like server crashes, only one window would go
down.

i think the bottom line is that X is a pain in the rear.

- erik

"Russ Cox" <rsc@swtch.com> writes

|
| > the upside of all this is that window and rio would be the only programs
| > linked against X. the downside would be extra 9p traffic.
|
| and requiring libthread (for lib9pclient) to write a gui program.
| i'm not thrilled about that.  also, i did something similar before
| with the windows port attempt, and it was very annoying when
| the devdraw-like server would crash and take everything with it.
|
| russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> to make X happy, you'd want a 1:1 correspondence
> between devdraw servers and windows.

I do not believe this is true at all.  I would want just
one devdraw server for all the windows, so that
there could be a single /dev/draw tree just like in Plan 9.

By all means try it, but I'm not convinced yet.
At the least it will be useful for drawterm.

Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[erik quanstrom]

perhaps you're right. i have avoided writing X programs.
paul would know better than i.

perhaps you're right about creating a single /dev/draw tree.
the tradeoff would be a little more bookkeeping within
the server, and and more sensitivity to bugs in the server,
but it really would mimic plan9.

btw, in plan9 is it possible to change any of env variables
that an already-running rio uses for new windows?
one advantage of the current p9p setup is that 9term -f $font
allows one to start a new window with a different font.

- erik

"Russ Cox" <rsc@swtch.com> writes

|
| > to make X happy, you'd want a 1:1 correspondence
| > between devdraw servers and windows.
|
| I do not believe this is true at all.  I would want just
| one devdraw server for all the windows, so that
| there could be a single /dev/draw tree just like in Plan 9.
|
| By all means try it, but I'm not convinced yet.
| At the least it will be useful for drawterm.
|
| Russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[Russ Cox]

> btw, in plan9 is it possible to change any of env variables
> that an already-running rio uses for new windows?
> one advantage of the current p9p setup is that 9term -f $font
> allows one to start a new window with a different font.

in plan 9 you can run font=whatever rio
and start a whole new window system with
a different font!

russ

Re: [9fans] Plan9Ports libdraw open-in-same-window

[erik quanstrom]

i know. you can do that in X, too with Xnest.
that wasn't quite what i was looking for.

- erik

"Russ Cox" <rsc@swtch.com> writes

|
| > btw, in plan9 is it possible to change any of env variables
| > that an already-running rio uses for new windows?
| > one advantage of the current p9p setup is that 9term -f $font
| > allows one to start a new window with a different font.
|
| in plan 9 you can run font=whatever rio
| and start a whole new window system with
| a different font!
|
| russ