[9fans] GSoC proposal: Alternative window system
Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
We already have a lot of hacks to make rio tiling. In my opinion the most interesting/worthwhile projects mentioned on that wiki is to make things touchscreen friendly. 2014-03-19 9:36 GMT+01:00 Caleb Malchik cmalc...@gmail.com: Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_ window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
Cohesive compilation of hacks? On Wed, Mar 19, 2014 at 7:56 PM, Bence Fábián beg...@gmail.com wrote: We already have a lot of hacks to make rio tiling. In my opinion the most interesting/worthwhile projects mentioned on that wiki is to make things touchscreen friendly. 2014-03-19 9:36 GMT+01:00 Caleb Malchik cmalc...@gmail.com: Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_ window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
It would be nice to have something like old Oberon OS had; I think acme was inspired in part by it (I may be wrong). Some time ago, I had some ideas on windowing design; were anyone interested, they're here: http/www.gli.cas.cz/home/cejchan/plan9/newUI.pdf http/www.gli.cas.cz/home/cejchan/plan9/newUI+page.pdf http/www.gli.cas.cz/home/cejchan/plan9/newUI+page-fullscreen.pdf Best regards, Peter. On Wed, Mar 19, 2014 at 10:01 AM, Shane Morris edgecombe...@gmail.comwrote: Cohesive compilation of hacks? On Wed, Mar 19, 2014 at 7:56 PM, Bence Fábián beg...@gmail.com wrote: We already have a lot of hacks to make rio tiling. In my opinion the most interesting/worthwhile projects mentioned on that wiki is to make things touchscreen friendly. 2014-03-19 9:36 GMT+01:00 Caleb Malchik cmalc...@gmail.com: Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_ window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
What did old Oberon have? -- Aram Hăvărneanu
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 10:14:26 EDT 2014, ara...@mgk.ro wrote: What did old Oberon have? http://en.wikipedia.org/wiki/Oberon_(operating_system) - erik
Re: [9fans] GSoC proposal: Alternative window system
I think Plan B / Octopus's omero does these things already. I'm still voting for touch interface 2014-03-19 15:17 GMT+01:00, erik quanstrom quans...@quanstro.net: On Wed Mar 19 10:14:26 EDT 2014, ara...@mgk.ro wrote: What did old Oberon have? http://en.wikipedia.org/wiki/Oberon_(operating_system) - erik
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 11:01:54 EDT 2014, beg...@gmail.com wrote: I think Plan B / Octopus's omero does these things already. I'm still voting for touch interface we don't drive any touch hardware, so in the interest of success, i would not be interested in a gsoc project that required as step 0: identify, purchase and write driver for enabling hardware. next year if there is such a hardware driver, and we're accepted into gsoc, it might be interesting. especially if a student signs up for it. - erik
Re: [9fans] GSoC proposal: Alternative window system
we don't drive any touch hardware, so in the interest of success, i would not be interested in a gsoc project that required as step 0: identify, purchase and write driver for enabling hardware. If someone were interested in doing this in the short term, the best option is likely tying it to reviving the iOS drawterm port. One could also do some interesting UI experiments with drawterm from laptops with multitouch devices; that would be less ambitious, but you'd get past step 0 quicker. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 11:33:58 EDT 2014, a...@9srv.net wrote: I'm still voting for touch interface Not to be pedantic, but note that there isn't any voting here. Students come up with a proposal for something they'd be interested in working on for the summer, and the prospective mentors order them and fill however many slots we get (short version). I'd love a touch interface, too, but if a student is interested in doing a dwm-like interface but not interested in touch, they should write a proposal for a dwm-like interface. thanks, i was too subtile about this point. - erik
Re: [9fans] GSoC proposal: Alternative window system
I'm still voting for touch interface Not to be pedantic, but note that there isn't any voting here. Students come up with a proposal for something they'd be interested in working on for the summer, and the prospective mentors order them and fill however many slots we get (short version). I'd love a touch interface, too, but if a student is interested in doing a dwm-like interface but not interested in touch, they should write a proposal for a dwm-like interface. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 11:36:39 EDT 2014, a...@9srv.net wrote: we don't drive any touch hardware, so in the interest of success, i would not be interested in a gsoc project that required as step 0: identify, purchase and write driver for enabling hardware. If someone were interested in doing this in the short term, the best option is likely tying it to reviving the iOS drawterm port. One could also do some interesting UI experiments with drawterm from laptops with multitouch devices; that would be less ambitious, but you'd get past step 0 quicker. given that that port was done many releases of ios ago, it is likly that a different step 0 would be required: bring the ios drawterm port back to life. - erik
Re: [9fans] GSoC proposal: Alternative window system
given that that port was done many releases of ios ago, it is likly that a different step 0 would be required: bring the ios drawterm port back to life. Certainly. It doesn't currently build. Old binaries start up but quickly crash. From memory, I don't believe keyboard input currently works. It's still a substantial step 0. signature.asc Description: Message signed with OpenPGP using GPGMail
[9fans] GSoC: ~2 days left to apply!
Folks: If you're thinking about applying to GSoC, do it quick: students have just over two days to apply. The application period ends at 19:00 UTC this Friday. We're seeing some really excellent proposals. Prospective mentors, if you've not signed up in Melange yet, you should do so now. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] GSoC: ~2 days left to apply!
On Wed Mar 19 13:37:24 EDT 2014, joseph.stew...@gmail.com wrote: Did the 2013 projects get put in a public place? I was especially lustful of the dis in a browser and web-drawterm. the drawterm in js and websocket project is ongoing, and the current code is part of 9atom. - erik
Re: [9fans] GSoC: ~2 days left to apply!
Did the 2013 projects get put in a public place? I was especially lustful of the dis in a browser and web-drawterm. -joe On Wed, Mar 19, 2014 at 10:01 AM, Anthony Sorace a...@9srv.net wrote: Folks: If you're thinking about applying to GSoC, do it quick: students have just over two days to apply. The application period ends at 19:00 UTC this Friday. We're seeing some really excellent proposals. Prospective mentors, if you've not signed up in Melange yet, you should do so now. Anthony
[9fans] GSoC proposal - Improvements to the HTML5 draw server
Hello 9fans, I'm applying to the Plan 9 GSoC again this year. I propose to continue work on the HTML5 drawterm I started in last year's GSoC, in the hope of making it a usable alternative to the native drawterm. I have identified three major areas for improvement: * cleaning up and fixing bugs in the graphics and input code * using the authenticated and encrypted cpu(1) protocol * multithreading the 9p library If you would like to read my proposal, I have posted it here: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/drh/5662278724616192 -- David
Re: [9fans] GSoC proposal: Alternative window system
On Wed, Mar 19, 2014 at 3:17 PM, erik quanstrom quans...@quanstro.net wrote: On Wed Mar 19 10:14:26 EDT 2014, ara...@mgk.ro wrote: What did old Oberon have? http://en.wikipedia.org/wiki/Oberon_(operating_system) - erik Yes, I know what Oberon is, I even used it. Peter mentioned something old Oberon had, which suggests it is something new Oberon doesn't have. Even if that isn't the case (why mention old then?), wanting Oberon features in rio means nothing unless it is specified what features that are. -- Aram Hăvărneanu
[9fans] (no subject)
On Sun, 16 Mar 2014 10:51:37 -0400, erik quanstrom wrote: since you mention the host's hardware, i'm a little confused. the host's hardware doesn't make any difference. it's drawterm's bridge between #A and the host's audio device that's the question. has someone done this for os-x? if so, where's the code? http://h1ro.dyndns.org/drawterm/ http://9fans.net/archive/2012/06/205
Re: [9fans] GSoC proposal: Alternative window system
On Mar 19, 2014, at 10:49 AM, Anthony Sorace a...@9srv.net wrote: given that that port was done many releases of ios ago, it is likly that a different step 0 would be required: bring the ios drawterm port back to life. Certainly. It doesn't currently build. Old binaries start up but quickly crash. From memory, I don't believe keyboard input currently works. It's still a substantial step 0. The GSOC 2010 iOS drawterm port does build and run on iOS 7+: https://bitbucket.org/jas/drawterm Pull it, open iphone/drawterm.xcodeproj in the latest Xcode 5.x, and you should be able to build and install it on an iOS device. It actually works a bit better on iPads since the keyboard doesn’t cover up everything you need in rio. -jas
Re: [9fans] GSoC proposal: Alternative window system
On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik cmalc...@gmail.com wrote: For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. I will throw out some rio/acme related ideas. Hope people find them interesting enough to want to experiment. - display size aware (when attached to an external display vs the builtin one of a laptop). - dpi aware (pick the right size font) - borderless windows (adjoining windows have different color) (but edges are sensitive to resizing etc) - auto splitting of windows. The idea is to see if window size fiddling can be minimized (ideally it should /learn/ personal preferences) - allow the window with focus to be made much much larger to help a user's focus (make other windows less distracting -- IIRC there was a web based spreadsheet that did that. Don't recall its name). - allow windows to be scrolled in lockstep (in x, y or both directions) - support for multiple displays - allow programmatic control of all this via a synthetic FS Not sure if there exists a usable unification of acme + rio but that would be nice.
[9fans] Multi monitor setup
Hi, as a new to Plan 9 I would like to know is there any support to dual monitor setup? Can I rotate monitor in plan 9? How does support of video cards looks like in general? BR, Szymon
Re: [9fans] GSoC proposal - Improvements to the HTML5 draw server
On Wed, Mar 19, 2014 at 1:07 PM, David Hoskin r...@davidrhoskin.com wrote: Hello 9fans, I'm applying to the Plan 9 GSoC again this year. I propose to continue work on the HTML5 drawterm I started in last year's GSoC, in the hope of making it a usable alternative to the native drawterm. I have identified three major areas for improvement: * cleaning up and fixing bugs in the graphics and input code * using the authenticated and encrypted cpu(1) protocol * multithreading the 9p library If you would like to read my proposal, I have posted it here: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/drh/5662278724616192 I'd like to see this proposal get priority since David is a returning student and last year's effort was a success. Steve
Re: [9fans] GSoC proposal: Alternative window system
Multiple displays and display dpi awareness in acme would make my day! Multi-display looks easy - we just need handling for adding a new row, which is already handily abstracted. Fitt's law aware mouse movement would be nice too, particularly on large screens. You could slightly trap the mouse on narrow edges (scroll bars and resize edges in particular) when the mouse is moving slowly. Probably a pain to tune, but would make acme much easier to use on large screens. Paul On Wed, Mar 19, 2014 at 12:02 PM, Bakul Shah ba...@bitblocks.com wrote: On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik cmalc...@gmail.com wrote: For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. I will throw out some rio/acme related ideas. Hope people find them interesting enough to want to experiment. - display size aware (when attached to an external display vs the builtin one of a laptop). - dpi aware (pick the right size font) - borderless windows (adjoining windows have different color) (but edges are sensitive to resizing etc) - auto splitting of windows. The idea is to see if window size fiddling can be minimized (ideally it should /learn/ personal preferences) - allow the window with focus to be made much much larger to help a user's focus (make other windows less distracting -- IIRC there was a web based spreadsheet that did that. Don't recall its name). - allow windows to be scrolled in lockstep (in x, y or both directions) - support for multiple displays - allow programmatic control of all this via a synthetic FS Not sure if there exists a usable unification of acme + rio but that would be nice.
