[9fans] GSoC proposal: Alternative window system

[9fans] GSoC proposal: Alternative window system

[Caleb Malchik]

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

[Bence Fábián]

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

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 <cmalchik@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
>
>

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

Re: [9fans] GSoC proposal: Alternative window system

[Shane Morris]

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

Cohesive compilation of hacks?


On Wed, Mar 19, 2014 at 7:56 PM, Bence Fábián <begnoc@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 <cmalchik@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
>>
>>
>

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

Re: [9fans] GSoC proposal: Alternative window system

[Peter A. Cejchan]

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

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 <edgecomberts@gmail.com>wrote:

> Cohesive compilation of hacks?
>
>
> On Wed, Mar 19, 2014 at 7:56 PM, Bence Fábián <begnoc@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 <cmalchik@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
>>>
>>>
>>
>

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

Re: [9fans] GSoC proposal: Alternative window system

[Aram Hăvărneanu]

What did old Oberon have?

-- 
Aram Hăvărneanu

Re: [9fans] GSoC proposal: Alternative window system

[erik quanstrom]

On Wed Mar 19 10:14:26 EDT 2014, aram.h@mgk.ro wrote:
> What did old Oberon have?
>

http://en.wikipedia.org/wiki/Oberon_(operating_system)

- erik

Re: [9fans] GSoC proposal: Alternative window system

[Bence Fábián]

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 <quanstro@quanstro.net>:
> On Wed Mar 19 10:14:26 EDT 2014, aram.h@mgk.ro wrote:
>> What did old Oberon have?
>>
>
> http://en.wikipedia.org/wiki/Oberon_(operating_system)
>
> - erik
>
>

Re: [9fans] GSoC proposal: Alternative window system

[erik quanstrom]

On Wed Mar 19 11:01:54 EDT 2014, begnoc@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

[Anthony Sorace]

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

> 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



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [9fans] GSoC proposal: Alternative window system

[erik quanstrom]

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

[Anthony Sorace]

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

> 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


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [9fans] GSoC proposal: Alternative window system

[erik quanstrom]

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

[Anthony Sorace]

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

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



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: [9fans] GSoC proposal: Alternative window system

[Aram Hăvărneanu]

On Wed, Mar 19, 2014 at 3:17 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Wed Mar 19 10:14:26 EDT 2014, aram.h@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

Re: [9fans] GSoC proposal: Alternative window system

[Jeff Sickel]

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

[Bakul Shah]

On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik <cmalchik@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.

Re: [9fans] GSoC proposal: Alternative window system

[Paul Lalonde]

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

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 <bakul@bitblocks.com> wrote:

> On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik <cmalchik@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.
>
>

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