[9fans] [GSOC] graphics projects

[9fans] [GSOC] graphics projects

[David Hoskin]

Hello 9fans,

I am interested in working on either of the graphics-related projects
suggested on the GSOC wiki page.

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.

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.

Thanks,
--
David Hoskin <root@davidrhoskin.com>

Re: [9fans] [GSOC] graphics projects

[yy]

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

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: 4201 bytes --]

Re: [9fans] [GSOC] graphics projects

[Peter A. Cejchan]

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

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

[-- Attachment #2: Type: text/html, Size: 5121 bytes --]

Re: [9fans] [GSOC] graphics projects

[Devon H. O'Dell]

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

Re: [9fans] [GSOC] graphics projects

[Peter A. Cejchan]

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

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: 6194 bytes --]

Re: [9fans] [GSOC] graphics projects

[Charles Forsyth]

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

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: 6917 bytes --]

Re: [9fans] [GSOC] graphics projects

[Peter A. Cejchan]

[-- 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 --]

Re: [9fans] [GSOC] graphics projects

[erik quanstrom]

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.

perhaps too large for a summer's work.

at a lower level, there are a number of drawing issues that really should be addressed.
for example, the current draw model has stringwidth() but not stringheight().
the font is assumed to have a uniform height.  this is a fine assumption for ascii,
but breaks down for even latin1, e.g. Â.  either the A needs to be unreasonablly
cramped to fit the hat, or every line (regardless of height) needs too much inter-line
spacing.  a better solution would be to lower the baseline as necessary to fit the line.

- erik

Re: [9fans] [GSOC] graphics projects

[David Hoskin]

Hello again,

Thanks for the discussion!

I wound up submitting a proposal for the web draw server:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/drh/1

--
David Hoskin <root@davidrhoskin.com>