9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Peter A. Cejchan" <tyapca7@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] [GSOC] graphics projects
Date: Fri, 26 Apr 2013 08:46:42 +0200	[thread overview]
Message-ID: <CAM6ozu6Zkc3OvMUt_Suk+6Dk_V1YZ35VdCZOr7Pmm36rZEZh0A@mail.gmail.com> (raw)
In-Reply-To: <CADErNDufWDKVSUENSogD5EBctCtEjAKY3Rgrwz7xHMacd89goA@mail.gmail.com>

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

> 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.

Adding graphics capabilities to Acme would be nice. Just IMHO.

++pac


On Wed, Apr 24, 2013 at 9:34 AM, yy <yiyu.jgl@gmail.com> wrote:

> 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: 5121 bytes --]

  reply	other threads:[~2013-04-26  6:46 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
2013-04-26  6:46   ` Peter A. Cejchan [this message]
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=CAM6ozu6Zkc3OvMUt_Suk+6Dk_V1YZ35VdCZOr7Pmm36rZEZh0A@mail.gmail.com \
    --to=tyapca7@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).