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