On 12/19/12, Luke Evans <luke.ev...@gmail.com> wrote: > I'm sure I could search all the sources for various examples of such > things, but does anybody know of a good (preferably concise) sample > that demonstrates the correct way to write GUI apps in Plan 9?
Russ Cox had a page full of trivial graphics programs to learn from on the web. This isn't swtch.com though - I think it was some .edu website. This may be what you were thinking of. I don't know if it still exists, but the source is probably on my disembodied desktop HDD from the first time I was interested in Plan 9 (searching 9fans for my name says 2010 surprisingly; it feels longer than that). > I thought I had bumped into a short example on the web for creating > a window in C, but can't seem to find it again. Plan 9 programs don't create windows, they use the window already allocated in their namespace. This is analogous to programs not creating /fd/^(0 1 2) by themselves - they use the ones inherited through fork. cinap_lenrek wrote: >its unusual for plan9 programs to make ther own windows tho. instead, >its more common to create windows/layers inside your screen (like >sam or acme). This is someone I was just thinking about the other day (Plan 9 is on my mind lately, I just resubscribed to 9fans and am planning on getting properly into it after my January exams - creating a sources account and everything) -- does sam really do its own window management -- I mean, it's got overlapping windows and everything so that's non-trivial - or does it ask devdraw? I suppose an easy way to find out would be to run Plan 9 with nothing but sam running, open alot of sam's internal windows, and ls in /dev/draw to see how many subdirectories there are. But I'm not actually installing Plan 9 until I have the time for it. Stuart - who just learned that the last IWP9 was a one-hour train ride from him. P.S. you might be interested to know that the "theoretical model" of how Plan 9's window management works -- that rio serves a fake mouse, keyboard, and screen to each of its children -- is wrong. rio serves a fake mouse and cons, but program write directly to the "real" /dev/draw. rio gives them a file called /dev/winname which contains a pointer to whereabouts in /dev/draw they are to write to (and they can violate this convention if they so wish). You could even say winname is a type of symbol link (!) You might think that this is primarily for speed instead of virtualising a whole draw device, This is partly the reason, but also Rob Pike wanted to do some sort of graphical Acme (and never got around to it), so he put the graphics somewhere where rio and acme could both have access to them. FGB slapped a sort of graphical Acme together in a few minutes one time, but it's not the same sort of thing that Rob had in mind. Stuart - surprised how much of this he remembers.
