Re: [9fans] [GSOC] graphics projects

["Peter A. Cejchan" <tyapca7@gmail.com>]

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

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.forsyth@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 <tyapca7@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.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 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.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: 7490 bytes --]