From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20130423.225549.100804076576453919.root@davidrhoskin.com> Date: Fri, 26 Apr 2013 09:11:02 +0200 Message-ID: From: "Peter A. Cejchan" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b2e41a4de562c04db3e3c4e Subject: Re: [9fans] [GSOC] graphics projects Topicbox-Message-UUID: 48915cac-ead8-11e9-9d60-3106f5b1d025 --047d7b2e41a4de562c04db3e3c4e Content-Type: text/plain; charset=UTF-8 I also like very much the Acme's replacement of hard-coded menus by customizable taglines with support of guide files, among others. With a support of interactive graphics, we could have , e.g., an image editor within Acme. Just a dream... ++pac On Fri, Apr 26, 2013 at 9:02 AM, Devon H. O'Dell wrote: > 2013/4/26 Peter A. Cejchan : > >> 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. > > I agree. I think fgb did this (or at least part of it?) at some point > in the past (for abaco maybe?), but I'm not sure what happened. Maybe > it's just sitting in his contrib. Haven't looked yet. > > If it's not complete, I think that'd be pretty great. > > --dho > > > ++pac > > > > > > On Wed, Apr 24, 2013 at 9:34 AM, yy wrote: > >> > >> On 24 April 2013 07:55, David Hoskin 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 . > > > > > > --047d7b2e41a4de562c04db3e3c4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also like very much the Acme's replacement= of hard-coded menus by customizable taglines with support of guide files, = among others.
With a support of interactive graphics, we could hav= e , e.g., an image editor within Acme. Just a dream...

++pac



On Fri, Apr 26, 2013 at 9:02 AM, Devon H. O'Dell <devon.odell@gmail.com> wrote:
2013/4/26 Peter A. Cejchan <tyapca7@gmail.com>:
>> 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 wi= th 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.

I agree. I think fgb did this (or at least part of it?) at some point=
in the past (for abaco maybe?), but I'm not sure what happened. Maybe it's just sitting in his contrib. Haven't looked yet.

If it's not complete, I think that'd be pretty great.

--dho

> ++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 p= rojects
>>> 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 tilin= g, but I
>>> fear that this would not be a large enough project for the who= le
>>> 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 o= ptions to
>> expand on that.
>>
>> First, whatever you do must have, at some point, the form of a fil= e
>> server, and you will have to play with the design until you find t= he right
>> one. It's easy to think in wmii-like file servers where you co= py a window to
>> a tag with cp (or bind) and remove it with rm. Maybe even some int= eresting
>> new feature comes up naturally (the rio design makes natural runni= ng rio
>> inside rio, maybe whatever you do makes natural to have tags insid= e tags or
>> whatever). You also have to keep in mind that most of the Plan 9 p= rograms
>> were intended to be used with a mouse, so although key bindings ma= y be
>> implemented it should be comfortable for mouse users too (you also= have
>> interesting options here, just now I'm using a mouse-controlle= d 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 wi= th 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 t= han use
>>> it as a dumb proxy? =C2=A0I am not sure what division of labou= r 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 ho= w 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 9= P servers
>> for applications to use. Drawing to the screen will probably invol= ve the
>> HTML5 canvas and some dynamic language. The 9P server could be imp= lemented
>> at different levels. There are many 9P libraries for different lan= guages and
>> platforms which may be used, or you could use a custom protocol li= ke 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 opini= on 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 signifi= cant 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,
>>
>>
>> =C2=A0Good luck!
>>
>>
>> --
>> - yiyus || JGL .
>
>


--047d7b2e41a4de562c04db3e3c4e--