Re: cwm tiling
Penned by Thomas Pfaff on 20120610 4:35.00, we have: | On Sun, 10 Jun 2012 00:23:42 -0500 | Todd T. Fries t...@fries.net wrote: | Penned by Mike Belopuhov on 20120609 6:17.29, we have: | | On Sat, Jun 9, 2012 at 12:41 PM, Stuart Henderson s...@spacehopper.org | | wrote: | | personally, I do see benefit to having your diff or something like it with | | commands which can be bound that rearrange windows into certain layouts | | on-demand (though I think vtile would be a lot more useful than htile to | | many people with restricted vertical space ;) | | | | but I think that's far enough; to get cwm to work as a full-time tiling | | WM with window rearranging taking place all the time is going to need | | various hacks which just seem at odds with the basic design of cwm. | | On the tiling thread, so long as tiling is contained behind non default | options and not seen otherwise, I don't see the harm. Yes there's more | code, but in this day and age size of the binary is not going to make a | huge difference. | | I'm not worried about the size of the binary, I'm more worried about | the number of lines of code this will end up adding; soon enough people | will send patches for this and that to suit their tiling needs. Once | you go down that road ... You missed the rest of my email, but the sentiment remains the same. Let those that wish to hack on tiling have a playpen to work in that is not effecting the rest of us. Why not let tiling take on a life of its own especially if it is an optional disabled-by-default part of cwm? Is there reason not to promote new development? Best possible outcome would be a spectrwm compat mode to cwm, with perhaps some options to do other manners of tiling as well. I could honestly see myself using the ability to shuffle all windows in a desktop into a cascade manner briefly if only to identify what all is going on. I could also use a layout shuffling function to (given space) move all windows on a given desktop into a visible spot, without adjusting the size of a given window. My dream would be the ability to utilize cwm simplicity with the 3d GL API and do some true 3d style windows management where it is more like navigating the universe to get to all the open windows versus a limited single plane of existence with z ordering. That's a bit outside the scope of tiling, yet it shows one could have fun and extend existing functionality. Thanks, -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
ip6(4) manpage update
Hi, I just got through a thread in misc@, http://marc.info/?l=openbsd-miscm=133934252713974w=2 and it seems like the sample code in ip6(4) is wrong. I've made adjustments but it doesn't look as nice anymore, perhaps someone can look over it? These changes will really help someone first time trying the sample code, I think. Credit should be given to Simon Perreault, I just did what he suggested. -peter patch below (against 5.1): Index: ip6.4 === RCS file: /cvs/src/share/man/man4/ip6.4,v retrieving revision 1.25 diff -u -r1.25 ip6.4 --- ip6.4 8 Sep 2011 16:43:56 - 1.25 +++ ip6.4 11 Jun 2012 19:26:44 - @@ -251,6 +251,7 @@ }; .Ed .It Dv IPV6_HOPLIMIT Fa int * +.It Dv IPV6_RECVHOPLIMIT Fa int * Get or set whether the hop limit header field from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -590,7 +591,7 @@ * returned along with the payload. */ optval = 1; -if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval, +if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval, sizeof(optval)) == -1) err(1, setsockopt); @@ -685,6 +686,15 @@ .%A B. Fenner .%A A. Rudoff .%T UNIX Network Programming, third edition +.Re +.Rs +.%A W. Stevens +.%A M. Thomas +.%A E. Nordmark +.%A T. Jinmei +.%T Advanced Sockets Application Program Interface (API) for IPv6 +.%R RFC 3542 +.%D May 2003 .Re .Sh STANDARDS Most of the socket options are defined in RFC 2292 or RFC 2553.
Re: ip6(4) manpage update
On 2012-06-11 15:31, Peter J. Philipp wrote: I just got through a thread in misc@, http://marc.info/?l=openbsd-miscm=133934252713974w=2 and it seems like the sample code in ip6(4) is wrong. I've made adjustments but it doesn't look as nice anymore, perhaps someone can look over it? These changes will really help someone first time trying the sample code, I think. Credit should be given to Simon Perreault, I just did what he suggested. You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS, IPV6_DSTOPTS, and IPV6_RTHDR. The RECV part was added to them in RFC3542. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
