Yeas, I know it. I once had Oberon installed, before they downgraded it to Bluebottle. It had a clean design and a single language for everything: Oberon...
++pac On Fri, Apr 26, 2013 at 9:15 AM, Charles Forsyth <charles.fors...@gmail.com>wrote: > The Oberon system interface, which inspired help/help (which led to Acme), > had graphics, and live rich text. > You could cut a running animation and paste it in somewhere else. > > > On 26 April 2013 08:11, Peter A. Cejchan <tyap...@gmail.com> wrote: > >> 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 >> <devon.od...@gmail.com>wrote: >> >>> 2013/4/26 Peter A. Cejchan <tyap...@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 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 <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 . >>> > >>> > >>> >>> >> >
