[9fans] oneko for rio

[9fans] oneko for rio

[YAMANASHI Takeshi]

Hi.

I feel like porting a fun X11 application called `oneko'.
Executing oneko, a kitten appears on the screen and
chases the mouse cursor running all over windows.

How can I do this for rio?  Any pointer or suggestion
on implementation is great.

Thank you.
--
YAMANASHI Takeshi

Re: [9fans] oneko for rio

[Boyd Roberts]

> I feel like porting a fun X11 application called `oneko'.
> Executing oneko, a kitten appears on the screen and
> chases the mouse cursor running all over windows.

IIRC it's trivial.  the cat ['neko' and the 'o' honorific
has to be a joke:  "it's better than a cat"] is cleverly
constructed out of 8-16? bitmaps.  so all you gotta do is take
the bitmaps and write a bit of code to blit them at the right
time.

on plan 9 this should be trivial (read 'hello world').  on
X11 oneko is a huge chunk of code, just to do a few bit blits.

btw: it's better than a cat = it's better than nothing.

     demo, gaijin da kara, wakaranai

Re: [9fans] oneko for rio

[rob pike]

I agree.  I think I could probably puzzle out a way to implement
oneko but it will not be easy, to put it mildly.

-rob

Re: [9fans] oneko for rio

[Boyd Roberts]

i had an idea to get oneko to run rio or namespace
trikery to get the mouse events and then pass them
on to rio.

gotta be easier than in X11.

IIRC the bitmaps are very clever.

Re: [9fans] oneko for rio

[YAMANASHI Takeshi]

> i had an idea to get oneko to run rio or namespace
> trikery to get the mouse events and then pass them
> on to rio.

Ok.  I will start with `pipefile' and `tee'-like program
to provide /dev/^(mouse mouse2).  Thank you.
--
YAMANASHI Takeshi

Re: [9fans] oneko for rio

[Douglas A. Gwyn]

rob pike wrote:
> I agree.  I think I could probably puzzle out a way to implement
> oneko but it will not be easy, to put it mildly.

Similar apps on the DMD/MTG were able to use the full-display
Bitmap data structure (named "display"), also Smouse/RealMouse
for the full-display mouse cursor location.  Since the draw(3)
device interposes a file system between any (sub)window and the
root bitmap (background/desktop), there is no direct path for a
(sub)window process to access its containing window, and
furthermore, rio(1) is not in a position to intervene.

However, it would appear that all that is needed for this kind
of app is for /dev/screen to be writable (it is read-only for
some reason I don't understand).  Perhaps /dev/screen can
support chmod so even if it is provided to the process in a
read-only state that could be changed and then top-level
drawing could be done.  Or, anyone want to change line 31 of
/sys/src/cmd/rio/fsys.c to
	{ "screen",	Qscreen,	0600 ),
and try the experiment?  The absolute mouse position would be
determinable by adding the local position to the difference
in LLCs of /dev/screen and /dev/window; I don't know whether
the mouse position is allowed to be reported as negative, but
it should be.  (Some apps might then have to start checking,
but I suspect most would be okay.)

I have DMD/MTG source for eyes, swarm, and crabs if anyone
wants to try porting them.

Re: [9fans] oneko for rio

[rog]

> on plan 9 this should be trivial (read 'hello world').

actually, i doubt if it would be so entirely trivial, as it's not that
easy to get the current position of the mouse cursor outside the
current window.  you could get around this by writing a little file
server (easiest using lib9p) that serves not only /dev/mouse, but
/dev/mouse2 as well; it would have to be run before rio (or run rio
inside a rio window)

then oneko would be able to get the current mouse position from
/dev/mouse2, despite the fact that rio had covered up /dev/mouse with
its own version. window position information is trivially found
in /dev/wsys/*/wctl

maybe i'm missing something.

Re: [9fans] oneko for rio

[rob pike]

	Or, anyone want to change line 31 of
	/sys/src/cmd/rio/fsys.c to
		{ "screen",	Qscreen,	0600 ),
	and try the experiment?

It takes more than a chmod of a file to implement a driver.  /dev/screen
is provided by rio; the write interface to the underlying /dev/draw is
provided through an RPC protocol, not direct data writes, which don't
match well to the 2-d quality of the data.  /dev/screen could in principle
be writable but it will take changes to a lot more than line 31.

	The absolute mouse position would be
	determinable by adding the local position to the difference
	in LLCs of /dev/screen and /dev/window;

False.  The mouse position is always in absolute coordinates unless
the user program does extra work.

And as for the return value of main: enough already!  The subject
isn't worth all this clutter in our mailboxes.

-rob

Re: [9fans] oneko for rio

[Douglas A. Gwyn]

rob pike wrote:
> The mouse position is always in absolute coordinates unless
> the user program does extra work.

As you can tell I haven't yet tried graphics programming
on Plan 9, apart from the patches to "vt" and "sam" where
somebody else had already done the hard part.

I suppose that window coordinates must also be absolute;
presumably in order to avoid having to intercept data and
add offsets.  This fortunately simplifies the subject task.
The only thing missing seems to be writability of /dev/screen.

Re: [9fans] oneko for rio

[YAMANASHI Takeshi]

Hi.

As my first try, I made `jneko', a cat runs in a window (jail)
chasing the mouse cursor.  The cat can't run out of the window,
but at least, you can see whether the bitmaps are clever or not.

% hget http://bata.cc.titech.ac.jp/uncover/liking/plan9/oneko.tgz | gunzip | tar x
% cd oneko; mk jneko.install
% bind -a face /lib/face; jneko


boyd>
> gotta be easier than in X11.

I agree. Writing `jneko' was far easier than X11.
But beyond removing the jail, I might see in time.

By the way, can somebody provide a set of Glenda bitmap?
-- 
YAMANASHI Takeshi

Re: [9fans] oneko for rio

[okamoto]

>By the way, can somebody provide a set of Glenda bitmap?

Are you going to make jglenda? :-)