Re: cwm tiling
Penned by Mike Belopuhov on 20120609 6:17.29, we have: | On Sat, Jun 9, 2012 at 12:41 PM, Stuart Henderson | wrote: | > On 2012/06/09 14:09, Alexander Polakov wrote: | >> > I appreciate that the defaults would stay the same, but really, | >> > what is the point in doing this? ?cwm can't be everything to | >> > everyone. | >> | >> The point is: when you want tiling from time to time, it's impractical | >> to switch to a tiling window manager. | > | > the basic tiling isn't really a problem but tiling WMs need various | > hacks to cope with the many programs that just *don't work* with them. | > | > part of this is to cope with window layouts which are stupid when | > they're tiled, part of it to cope with programs that plain don't like | > having their windows resized on them immediately when they're created. | > | > 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. | > | > | > so +1 for manually-triggered auto rearranging, -1 for turning cwm into | > something which (dwm|ion|spectrwm|awesome|wmii|xmonad|...) already cater | for. | > | | in my very humble opinion what cwm really needs is a nice minimum | overlap window placement algorithm. currently users have to point | the mouse cursor to where they want a new window to be created. | otherwise the whole thing quickly turns into a mess of overlapped | windows in the center of the screen. Given that cwm was started as a plan9 wm alike, and you'd draw the xterm you wanted to open with the pointer, I think this is counter intuitive to the current default behavior of cwm. However, I'd be all for permitting a knob to change this behavior from the default. 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. Code that is self contained behind knobs that are not enabled by default seems quite sufficiently separated that there should not be any issue (or it is not self contained, and will be readily corrected). The point about switching wm's is rather to the heart of the matter. If one wanted tiling only, one would use spectrwm. If one wanted non tiling only, one can use cwm. If one wants a combination, one must create the diff that created this thread. Please commit, ok todd@! 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
Re: mg - save backup files to homedir (diff v2)
> So perhaps it is better for mg to behave more like emacs when it comes
> to saving backup files in a single directory. Especially if a user has
> two files open with the same name and are working on them
> simultaneously. In this diff I've added the path to the backup file
> name. Like emacs, it changes any '/' to '!'.
>
Here is a slightly modified diff; add NUL termination to backup path.
Are there objections to this going in?
-lum
Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.123
diff -u -p -r1.123 def.h
--- def.h 7 Jun 2012 15:15:04 - 1.123
+++ def.h 9 Jun 2012 20:22:10 -
@@ -446,6 +446,7 @@ struct list *make_file_list(char *);
int fisdir(const char *);
int fchecktime(struct buffer *);
int fupdstat(struct buffer *);
+int backuptohomedir(int, int);
/* kbd.c X */
int do_meta(int, int);
Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.89
diff -u -p -r1.89 fileio.c
--- fileio.c25 May 2012 04:56:58 - 1.89
+++ fileio.c9 Jun 2012 20:22:10 -
@@ -22,6 +22,10 @@
#include "kbd.h"
+static char *bkuplocation(const char *);
+
+static char *bkupdir;
+
/*
* Open a file for reading.
*/
@@ -189,6 +193,51 @@ ffgetline(FILE *ffp, char *buf, int nbuf
}
/*
+ * Location of backup file. This function creates the correct path.
+ */
+static char *
+bkuplocation(const char *fn)
+{
+ struct stat sb;
+ char *ret;
+
+ if (bkupdir != NULL && (stat(bkupdir, &sb) == 0) &&
+ S_ISDIR(sb.st_mode)) {
+ char fname[NFILEN];
+ const char *c;
+ int i = 0, len;
+
+ c = fn;
+ len = strlen(bkupdir);
+
+ while (*c != '\0') {
+ /* Make sure we don't go over combined:
+* strlen(bkupdir + '/' + fname + '\0')
+*/
+ if (i >= NFILEN - len - 1)
+ return (NULL);
+ if (*c == '/') {
+ fname[i] = '!';
+ } else if (*c == '!') {
+ if (i >= NFILEN - len - 2)
+ return (NULL);
+ fname[i++] = '!';
+ fname[i] = '!';
+ } else
+ fname[i] = *c;
+ i++;
+ c++;
+ }
+ fname[i] = '\0';
+ if (asprintf(&ret, "%s/%s", bkupdir, fname) == -1)
+ return (NULL);
+ } else if ((ret = strndup(fn, NFILEN)) == NULL)
+ return (NULL);
+
+ return (ret);
+}
+
+/*
* Make a backup copy of "fname". On Unix the backup has the same
* name as the original file, with a "~" on the end; this seems to
* be newest of the new-speak. The error handling is all in "file.c".
@@ -203,23 +252,29 @@ fbackupfile(const char *fn)
int from, to, serrno;
ssize_t nread;
char buf[BUFSIZ];
- char*nname, *tname;
+ char*nname, *tname, *bkpth;
if (stat(fn, &sb) == -1) {
ewprintf("Can't stat %s : %s", fn, strerror(errno));
return (FALSE);
}
- if (asprintf(&nname, "%s~", fn) == -1) {
+ if ((bkpth = bkuplocation(fn)) == NULL)
+ return (FALSE);
+
+ if (asprintf(&nname, "%s~", bkpth) == -1) {
ewprintf("Can't allocate temp file name : %s", strerror(errno));
+ free(bkpth);
return (ABORT);
}
- if (asprintf(&tname, "%s.XX", fn) == -1) {
+ if (asprintf(&tname, "%s.XX", bkpth) == -1) {
ewprintf("Can't allocate temp file name : %s", strerror(errno));
+ free(bkpth);
free(nname);
return (ABORT);
}
+ free(bkpth);
if ((from = open(fn, O_RDONLY)) == -1) {
free(nname);
@@ -610,4 +665,28 @@ fchecktime(struct buffer *bp)
return (TRUE);
+}
+
+int
+backuptohomedir(int f, int n)
+{
+ const char *c = "~/.mg.d";
+ char*p;
+
+ if (bkupdir == NULL) {
+ p = adjustname(c, TRUE);
+ bkupdir = strndup(p, NFILEN);
+ if (bkupdir == NULL)
+ return(FALSE);
+
+ if (mkdir(bkupdir, 0700) == -1 && errno != EEXIST) {
+ free(bkupdir);
+ bkupdir = NULL;
+ }
+ } else {
+ free(bkupdir);
+ bkupdir = NULL;
+ }
+
+ return (TRUE);
}
Index:
Re: cwm tiling
On 2012/06/09 12:04, Abel Abraham Camarillo Ojeda wrote: > On Sat, Jun 9, 2012 at 2:22 AM, Tobias Ulmer wrote: > > On Sun, Jun 03, 2012 at 09:07:13PM +0400, Alexander Polakov wrote: > >> I'd like to start a discussion about adding tiling to cwm with > >> these two diffs. > > > > How hard can it be to import spectrwm... You're reinventing the wheel > > here, badly. > > > > spectrwm is full of bugs... or I'm unable to use it well with > mplayer -vo sdl ... > It probably needs another quirk adding, the existing quirk only matches MPlayer:xv windows.
Re: cwm tiling
On Sat, Jun 9, 2012 at 2:22 AM, Tobias Ulmer wrote: > On Sun, Jun 03, 2012 at 09:07:13PM +0400, Alexander Polakov wrote: >> I'd like to start a discussion about adding tiling to cwm with >> these two diffs. > > How hard can it be to import spectrwm... You're reinventing the wheel > here, badly. > spectrwm is full of bugs... or I'm unable to use it well with mplayer -vo sdl ...
Re: cwm tiling
On Sat, Jun 9, 2012 at 9:53 AM, Weldon Goree wrote: > On Sat, 2012-06-09 at 14:26 +0300, Paul Irofti wrote: >> I agree completley with you. Being able to tile just a given virtual >> desktop and leave the others intact would be pretty awesome. > > Except they aren't desktops. Desktops are exclusively selected, cwm > groups aren't (necessarily), and have a z index based on last selection. > How (eg) xmonad handles tags is a better basis for multi-desktop tiling > than how cwm handles groups. > > Weldon > +1, but I wouldn't like the tiling behavior by default though, ever. 2 reasons: 1 - author didn't intend it - it might lead old or current users feel like its not the same cwm 2 - In my personal experience the windows that I want tiled are never closed, so I like manually setting the "tiling property". Current diff to implement tiling meet the above conditions, so I like it!
New message
Royal Beach Resort & Spa, Sharjah, UAE SUMMER CORPORATE PROMOTION (01.06.2012 To 30.09.2012) Five-Stars & Brand New, Fully Operational, Ready to Welcome You ! Single Room : Dhs.240/- per night Double Room : Dhs.280/- per night Book Now ! reservati...@royalbeachresortspa.com http://www.royalbeachresortspa.com UNSUBSCRIBE : Please send e-mail with subject "Unsubscribe me" to administrat...@royalbeachresortspa.com
Re: Arc4random_uniform
> I agree that simply "min = -upper_bound % upper_bound" should be > sufficient in all cases, since u_int32_t arithmetic is defined as > modulo 2**32 by the C standard, at least as of C99 and I think C89 > too. (Even if we supported any 1s-complement architectures, the > compiler would still need to implement u_int32_t as modulo 2**32.) Indeed. I was looking at it from a correctness point of view instead of trying to determine if it would work in practice. > I also think it makes sense to get rid of the LP64 test, because > 64-bit division still takes more than twice as long as 32-bit division > on most amd64 processors for example (according to > http://gmplib.org/~tege/x86-timing.pdf). And to reduce complexity, of course. > Of course, the potential benefit here isn't that great, so I don't > know whether this really makes sense to worry about. Oh, there are certainly more important matters, but you know how these things go. You see something that can be improved and it turns into an itch that needs to be scratched. The quickest and best way to do so was to send an email to this list. Then when I wrote the message, I started thinking about whether this really was the best implementation or it could be improved further. I freely admit that it doesn't make any difference in the grand scheme of things, but there's also the minute scheme of things. ;)
Re: cwm tiling
On Sat, 2012-06-09 at 14:26 +0300, Paul Irofti wrote: > I agree completley with you. Being able to tile just a given virtual > desktop and leave the others intact would be pretty awesome. Except they aren't desktops. Desktops are exclusively selected, cwm groups aren't (necessarily), and have a z index based on last selection. How (eg) xmonad handles tags is a better basis for multi-desktop tiling than how cwm handles groups. Weldon
Re: cwm tiling
On Sat, Jun 09, 2012 at 02:26:04PM +0300, Paul Irofti wrote: > I agree completley with you. Being able to tile just a given virtual > desktop and leave the others intact would be pretty awesome. > > Turning it into a full blown tiling wm isn't what's being proposed from > what I understand. An idea is a flavored package named something like cwm-tile (or whatever) and into the precompiled packages. Everyone's happy. -- Do not use my email to mass forward chain mails. [demime 1.01d removed an attachment of type application/pgp-signature]
Re: cwm tiling
I agree completley with you. Being able to tile just a given virtual desktop and leave the others intact would be pretty awesome. Turning it into a full blown tiling wm isn't what's being proposed from what I understand.
Re: cwm tiling
On 2012 Jun 09 (Sat) at 13:17:29 +0200 (+0200), Mike Belopuhov wrote: :On Sat, Jun 9, 2012 at 12:41 PM, Stuart Henderson :wrote: :> On 2012/06/09 14:09, Alexander Polakov wrote: :>> > I appreciate that the defaults would stay the same, but really, :>> > what is the point in doing this? cwm can't be everything to :>> > everyone. :>> :>> The point is: when you want tiling from time to time, it's impractical :>> to switch to a tiling window manager. :> :> the basic tiling isn't really a problem but tiling WMs need various :> hacks to cope with the many programs that just *don't work* with them. :> :> part of this is to cope with window layouts which are stupid when :> they're tiled, part of it to cope with programs that plain don't like :> having their windows resized on them immediately when they're created. :> :> 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. :> :> :> so +1 for manually-triggered auto rearranging, -1 for turning cwm into :> something which (dwm|ion|spectrwm|awesome|wmii|xmonad|...) already cater :for. :> : :in my very humble opinion what cwm really needs is a nice minimum :overlap window placement algorithm. currently users have to point :the mouse cursor to where they want a new window to be created. :otherwise the whole thing quickly turns into a mess of overlapped :windows in the center of the screen. : ...which is exactly the behaviour I like. -- Experience is what you get when you were expecting something else.
Re: cwm tiling
On Sat, Jun 9, 2012 at 12:41 PM, Stuart Henderson wrote: > On 2012/06/09 14:09, Alexander Polakov wrote: >> > I appreciate that the defaults would stay the same, but really, >> > what is the point in doing this? cwm can't be everything to >> > everyone. >> >> The point is: when you want tiling from time to time, it's impractical >> to switch to a tiling window manager. > > the basic tiling isn't really a problem but tiling WMs need various > hacks to cope with the many programs that just *don't work* with them. > > part of this is to cope with window layouts which are stupid when > they're tiled, part of it to cope with programs that plain don't like > having their windows resized on them immediately when they're created. > > 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. > > > so +1 for manually-triggered auto rearranging, -1 for turning cwm into > something which (dwm|ion|spectrwm|awesome|wmii|xmonad|...) already cater for. > in my very humble opinion what cwm really needs is a nice minimum overlap window placement algorithm. currently users have to point the mouse cursor to where they want a new window to be created. otherwise the whole thing quickly turns into a mess of overlapped windows in the center of the screen.
ahci(4) attach function fixes for AMD chipsets
The following diff fixes a couple of small issues with the AMD chipset
attach functions..
- Have the SB700 attach routine properly call the IDE to AHCI
function and migrate the ATI_SBX00_SATA_1 PCI id to using
the SB700 attach routine. The SB600 routine was being used
because it does the proper call. This just makes it so all
of the SB700 controllers use the same attach routine, especially
incase any other workarounds/errata type things come up or
not setting SB600 things for SB700.
- Have the Hudson-2 attach routine set the AHCI_F_IPMS_PROBE
flag to resolve the issue with Port Multiplier support. The
SB700 attachment function was being used because it was
setting the flag. This also fixes the other Hudson-2 AHCI
controllers so they won't experience the same issue.
Index: ahci.c
===
RCS file: /home/cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.188
diff -u -p -r1.188 ahci.c
--- ahci.c 5 May 2012 10:10:12 - 1.188
+++ ahci.c 6 May 2012 03:46:01 -
@@ -463,7 +463,7 @@ static const struct ahci_device ahci_dev
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA_1,
NULL, ahci_amd_hudson2_attach },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA_2,
- NULL, ahci_ati_sb700_attach },
+ NULL, ahci_amd_hudson2_attach },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA_3,
NULL, ahci_amd_hudson2_attach },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SATA_4,
@@ -476,7 +476,7 @@ static const struct ahci_device ahci_dev
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB600_SATA,
NULL, ahci_ati_sb600_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
- NULL, ahci_ati_sb600_attach },
+ NULL, ahci_ati_sb700_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_2,
NULL, ahci_ati_sb700_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_3,
@@ -732,7 +732,10 @@ ahci_ati_sb600_attach(struct ahci_softc
int
ahci_ati_sb700_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
{
+ ahci_ati_sb_idetoahci(sc, pa);
+
sc->sc_flags |= AHCI_F_IPMS_PROBE;
+
return (0);
}
@@ -740,6 +743,8 @@ int
ahci_amd_hudson2_attach(struct ahci_softc *sc, struct pci_attach_args *pa)
{
ahci_ati_sb_idetoahci(sc, pa);
+
+ sc->sc_flags |= AHCI_F_IPMS_PROBE;
return (0);
}
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: cwm tiling
On 2012/06/09 14:09, Alexander Polakov wrote:
> > I appreciate that the defaults would stay the same, but really,
> > what is the point in doing this? cwm can't be everything to
> > everyone.
>
> The point is: when you want tiling from time to time, it's impractical
> to switch to a tiling window manager.
the basic tiling isn't really a problem but tiling WMs need various
hacks to cope with the many programs that just *don't work* with them.
part of this is to cope with window layouts which are stupid when
they're tiled, part of it to cope with programs that plain don't like
having their windows resized on them immediately when they're created.
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.
I'd be keen for cwm not to end up with code like this
setquirk("MPlayer", "xv", SWM_Q_FLOAT | SWM_Q_FULLSCREEN
| SWM_Q_FOCUSPREV);
setquirk("OpenOffice.org 3.2", "VCLSalFrame", SWM_Q_FLOAT);
setquirk("Firefox-bin", "firefox-bin", SWM_Q_TRANSSZ);
setquirk("Firefox", "Dialog", SWM_Q_FLOAT);
setquirk("Gimp","gimp", SWM_Q_FLOAT | SWM_Q_ANYWHERE);
setquirk("XTerm", "xterm",SWM_Q_XTERM_FONTADJ);
setquirk("xine","Xine Window", SWM_Q_FLOAT | SWM_Q_ANYWHERE);
setquirk("Xitk","Xitk Combo", SWM_Q_FLOAT | SWM_Q_ANYWHERE);
setquirk("xine","xine Panel", SWM_Q_FLOAT | SWM_Q_ANYWHERE);
setquirk("Xitk","Xine Window", SWM_Q_FLOAT | SWM_Q_ANYWHERE);
setquirk("xine","xine Video Fullscreen Window",
SWM_Q_FULLSCREEN | SWM_Q_FLOAT);
setquirk("pcb", "pcb", SWM_Q_FLOAT);
setquirk("SDL_App", "SDL_App", SWM_Q_FLOAT | SWM_Q_FULLSCREEN);
so +1 for manually-triggered auto rearranging, -1 for turning cwm into
something which (dwm|ion|spectrwm|awesome|wmii|xmonad|...) already cater for.
Re: cwm tiling
* Thomas Pfaff [120608 23:06]: > On Fri, 8 Jun 2012 13:57:35 -0400 > Okan Demirmen wrote: > > > On Fri 2012.06.08 at 19:40 +0200, Thomas Pfaff wrote: > > > On Sun, 3 Jun 2012 21:07:13 +0400 > > > Alexander Polakov wrote: > > > > > > > I'd like to start a discussion about adding tiling to cwm with > > > > these two diffs. > > > > > > I don't want it ;-) > > > > > > If I wanted a tiling window manager I'd install one of the many > > > already available. Please keep cwm clean and simple, as it is. > > > > It's not being dropped as an idea at all. Defaults will not change > > however. > > > > Doing this means more code (more now and definitely more to come), > more documentation, more configuration options, more to learn, more > more more. It adds about hundred lines of code and one binding now. You are not obliged to learn and use every possible keyboard binding, are you? > I appreciate that the defaults would stay the same, but really, > what is the point in doing this? cwm can't be everything to > everyone. The point is: when you want tiling from time to time, it's impractical to switch to a tiling window manager. -- Alexander Polakov | plhk.ru
Re: cwm tiling
+1 On Jun 9, 2012 5:46 AM, "Christiano F. Haesbaert" wrote: > On Jun 8, 2012 9:22 PM, "Jérémie Courrèges-Anglas" > wrote: > > > > Antoine Jacoutot writes: > > > I for one would love cwm to have tiling management. > > > I don't care avout the alternative, they are not in base. > > > > Same here. > > > > I might migrate to cwm just for the tilling. > > > -- > > Jérémie Courrèges-Anglas > > GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: cwm tiling
* Tobias Ulmer [120609 11:32]: > On Sun, Jun 03, 2012 at 09:07:13PM +0400, Alexander Polakov wrote: > > I'd like to start a discussion about adding tiling to cwm with > > these two diffs. > > How hard can it be to import spectrwm... You're reinventing the wheel > here, badly. No, I am not. I'm reimplementing the wheel. -- Alexander Polakov | plhk.ru
Re: cwm tiling
On Sat, Jun 09, 2012 at 08:30:59AM +0200, robert wrote: > On Fri, Jun 08, 2012 at 10:21:43PM -0500, Abel Abraham Camarillo Ojeda wrote: > > On Fri, Jun 8, 2012 at 9:43 PM, Christiano F. Haesbaert > > wrote: > > > On Jun 8, 2012 9:22 PM, "J??r??mie Courr??ges-Anglas" > > > > > > wrote: > > >> > > >> Antoine Jacoutot writes: > > >> > I for one would love cwm to have tiling management. > > >> > I don't care avout the alternative, they are not in base. > > >> > > >> Same here. > > >> > > > > > > I might migrate to cwm just for the tilling. > > > > > >> -- > > >> J??r??mie Courr??ges-Anglas > > >> GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 > > > > > > > +1 for tiling in base... > > > > +1 I'm not using tiling anymore. But I did for 2 years and would love to have this in base. I don't care if it's cwm or some other crap wm. So +1
San Rafael | Salta, Tilcara, Humahuaca, Purmamarca Los mejores viajes junto Buenas Vibras
Si no podes visualizar este mail, ingresa a: http://news1.bonuscupon.com.ar/r.html?uid=1.12.295h.j7.kdef7sal32
Re: UPDATE: xkeyboard-config 2.6
On Sun, Jun 03, 2012 at 12:45:55PM +0600, Alexandr Shadchin wrote: > Hi, > > This update xkeyboard-config to the latest release 2.6. > http://koba.devio.us/distfiles/xkeyboard-config-2.6.diff > > NOTE: Some old/unused material cleaned up > > Tested on amd64. > > Comments ? OK ? > Works well on my machines. ok matthieu@. -- Matthieu Herrb
Re: cwm tiling
On Sun, Jun 03, 2012 at 09:07:13PM +0400, Alexander Polakov wrote: > I'd like to start a discussion about adding tiling to cwm with > these two diffs. How hard can it be to import spectrwm... You're reinventing the wheel here, badly.
