> 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....@gmail.com> wrote: > On 24 April 2013 07:55, David Hoskin <r...@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 . >
