On Sun, Apr 23, 2006 at 09:41:02PM +0100, David Tweed wrote: > > Maybe doing this with the unique client id (which is > > wmii's > > internal client address) might be better, because > > window id's > > look pretty cryptic... > > This would be pretty useful for programs which want > the window manager to do their tiling for them. One > question: so I've got a program with multiple windows, > can the program in some way find out the mapping from > XWindow stuff it knows about to the wmii identifier?
Only if we'd use the window id, otherwise the internal wmii identifier is wmii-specific (basically a value which is unique, but increased for each new window). > Also, I remember you saying that Linux technology (I > forget whether it was FUSE on the 9p filesystem) would > enable direct mounting of the wmii filesystem. Is that > something which still needs changes to the wmii set of > programs, or is the wmii end of this finished? The wmii end is finished, wmii speaks the same 9protocol as acme. The other end, the 9p2000.ko module is also finished and included in Linux kernel. Though there are following issues at the moment: - It seems that 9p2000.ko has problems to mount wmii'fs as well as plumber'fs and acme'fs, - in all cases I get a 'bad superblock' error message on attempt to mount. - The 9p2000.ko allows only mounting with superuser priviledges due the limitations of Unix. That is quite bad and could only be solved with the introduction of real process-based vfs namespaces in Linux, though that seems to be a longterm goal. 9p(1) from plan9port and wmiir(1) from wmii work fine with accessing the wmii'fs though. Regards, -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
