9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: yy <yiyu.jgl@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] [GSOC] graphics projects
Date: Wed, 24 Apr 2013 09:34:18 +0200	[thread overview]
Message-ID: <CADErNDufWDKVSUENSogD5EBctCtEjAKY3Rgrwz7xHMacd89goA@mail.gmail.com> (raw)
In-Reply-To: <20130423.225549.100804076576453919.root@davidrhoskin.com>

[-- Attachment #1: Type: text/plain, Size: 3189 bytes --]

On 24 April 2013 07:55, David Hoskin <root@davidrhoskin.com> wrote:

> Hello 9fans,
>
> I am interested in working on either of the graphics-related projects
> suggested on the GSOC wiki page.
>
>
Nice.


> For the window system enhancements, my immediate idea would be to
> implement title bars and dwm-style keyboard commands and tiling, but I
> fear that this would not be a large enough project for the whole
> summer.
>
>
Just porting dwm or some of its features to rio would probably be not
enough for a gsoc project. However, you have lots of interesting options to
expand on that.

First, whatever you do must have, at some point, the form of a file server,
and you will have to play with the design until you find the right one.
It's easy to think in wmii-like file servers where you copy a window to a
tag with cp (or bind) and remove it with rm. Maybe even some interesting
new feature comes up naturally (the rio design makes natural running rio
inside rio, maybe whatever you do makes natural to have tags inside tags or
whatever). You also have to keep in mind that most of the Plan 9 programs
were intended to be used with a mouse, so although key bindings may be
implemented it should be comfortable for mouse users too (you also have
interesting options here, just now I'm using a mouse-controlled dwm version
and works quite well).

Also, keep in mind that there is already a well known and popular tiling
environment in Plan 9. If you are able to make a window manager with an
acme feeling I'm sure many users would be interested. The challenge here is
to have the good taste required to come up with the right design, and
that's quite a challenge.


> I have the opposite concern about the Web /dev/draw; would it be
> acceptable to move some of the logic to the Go client rather than use
> it as a dumb proxy?  I am not sure what division of labour I would
> settle on here.
>
>
I don't think nobody is sure about anything. Certainly, there is a way to
have a "drawterm in the browser", but it is not clear how to do it. I guess
figuring this out may be the first task. You will need some way to draw to
the screen and read input events, and you will need to provide a 9P servers
for applications to use. Drawing to the screen will probably involve the
HTML5 canvas and some dynamic language. The 9P server could be implemented
at different levels. There are many 9P libraries for different languages
and platforms which may be used, or you could use a custom protocol like
p9p's devdraw and then implement the 9P server in Inferno, Plan9 or some
program in the local host. And then, you need to glue both parts together.

There are many options here, I think many of us have our own opinion on the
best way to achieve this. You will have to discuss the details with your
mentor. In any case, I think if you are confident to implement the "web
part" of the project, serving 9P is not going to be a significant problem,
and you could easily get some help for that.

I think it is feasible to finish this project in a summer, but it won't be
easy.


Thanks,
>

 Good luck!


--
- yiyus || JGL .

[-- Attachment #2: Type: text/html, Size: 4201 bytes --]

  reply	other threads:[~2013-04-24  7:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-24  5:55 David Hoskin
2013-04-24  7:34 ` yy [this message]
2013-04-26  6:46   ` Peter A. Cejchan
2013-04-26  7:02     ` Devon H. O'Dell
2013-04-26  7:11       ` Peter A. Cejchan
2013-04-26  7:15         ` Charles Forsyth
2013-04-26  7:30           ` Peter A. Cejchan
2013-04-26 12:13       ` erik quanstrom
2013-05-02 12:35 ` David Hoskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADErNDufWDKVSUENSogD5EBctCtEjAKY3Rgrwz7xHMacd89goA@mail.gmail.com \
    --to=yiyu.jgl@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).