Re: [9fans] [GSOC] graphics projects
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 .
Re: [9fans] [GSOC] graphics projects
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 .
Re: [9fans] German USB keyboard on Raspberry Pi
2013/4/25 Holger Sebert holger.seb...@ruhr-uni-bochum.de: If not, how do I recompile and install the kbd-module on the Raspberry Pi? I changed kbd.c for testing purposes and executed mk install in the directory /sys/src/9/. Although the build succeeded the changes did not seem to be incorporated. mk install usually installs the kernel to /$objtype, but rpi boots from dos partition of an SD card, therefore you also need to copy it over there: ; dosmnt 1 /n/dos ; cp /arm/9pi /n/dos/ ; unmount /n/dos # or simply close the window -- - Yaroslav
Re: [9fans] [GSOC] graphics projects
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.comwrote: 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 .
Re: [9fans] [GSOC] graphics projects
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.comwrote: 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 .
Re: [9fans] [GSOC] graphics projects
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.comwrote: 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.comwrote: 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 .
[9fans] Trouble building Inferno on Linux
Hello, I have followed these build instructions: www.ueber.net/who/mjl/inferno/getting-started.html It builds mk without error but when mk -s nuke mkdirs install is run I get the following errors: warning: skipping missing include file: ~/inferno/mkfiles/mkhost-Linux: No such file or directory warning: skipping missing include file: ~/inferno/mkfiles/mkfile-Linux-386: No such file or directory mk: don't know how to make 'nuke-' I checked those files and they are in fact there, they can be read and contain data (not zero size). If I run mk without arguments I get the same missing include file errors.
Re: [9fans] Trouble building Inferno on Linux
I checked those files and they are in fact there, they can be read and contain data (not zero size). If I run mk without arguments I get the same missing include file errors. You seem to be assuming that ~ is resolved to a $HOME, which is not the case in the Plan 9 and Inferno contexts. Maybe you need to specify $HOME explicitly? ++L
Re: [9fans] German USB keyboard on Raspberry Pi
2013/4/25 Holger Sebert holger.seb...@ruhr-uni-bochum.de: If not, how do I recompile and install the kbd-module on the Raspberry Pi? I changed kbd.c for testing purposes and executed mk install in the directory /sys/src/9/. Although the build succeeded the changes did not seem to be incorporated. mk install usually installs the kernel to /$objtype, but rpi boots from dos partition of an SD card, therefore you also need to copy it over there: ; dosmnt 1 /n/dos ; cp /arm/9pi /n/dos/ ; unmount /n/dos # or simply close the window simply 9fat: should work. no need to unmount. - erik
Re: [9fans] [GSOC] graphics projects
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. 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] German USB keyboard on Raspberry Pi
simply 9fat: should work. Not on a normal 9pi SD card, which has a dos partition and no 9fat.
Re: [9fans] German USB keyboard on Raspberry Pi
On Fri Apr 26 08:35:10 EDT 2013, 9f...@hamnavoe.com wrote:
simply 9fat: should work.
Not on a normal 9pi SD card, which has a dos partition and no 9fat.
i missed this fix:
minooka; 9diff /rc/bin/9fat:
/n/sources/plan9/rc/bin/9fat::1,7 - /rc/bin/9fat::1,7
#!/bin/rc
rfork e
- part=`{ls /dev/fs/9fat /dev/sd*/9fat [2]/dev/null}
+ part=`{ls /dev/fs/9fat /dev/sd*/9fat /dev/sd*/dos [2]/dev/null}
if(~ $#part 0) {
echo 'no 9fat partition found' [1=2]
exit no.9fat
- erik
[9fans] anyone use 9vx with root from kenfs?
if so, does it involve aux/trampoline? i looked through the archives and can't see any mention of IL. i'm using sources from yiyus' repo on bitbucket. -Skip
Re: [9fans] anyone use 9vx with root from kenfs?
I did that just after 9vx was announced. /net was ported from plan9 by devon iirc. and il was easy to port then mod some sign issues. it depended on raw networking. I stopped using it since drawterm didn't crash and 9vx did at the time. - erik Skip Tavakkolian skip.tavakkol...@gmail.com wrote: if so, does it involve aux/trampoline? i looked through the archives and can't see any mention of IL. i'm using sources from yiyus' repo on bitbucket. -Skip
