Re: cwm tiling
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 christiano...@gmail.com wrote: On Jun 8, 2012 9:22 PM, J??r??mie Courr??ges-Anglas jca+o...@wxcvbn.org wrote: Antoine Jacoutot ajacou...@bsdfrog.org 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 -- -=[rpe]=-
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.
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
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: 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 christiano...@gmail.com wrote: On Jun 8, 2012 9:22 PM, J??r??mie Courr??ges-Anglas jca+o...@wxcvbn.org wrote: Antoine Jacoutot ajacou...@bsdfrog.org 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
Re: cwm tiling
* Tobias Ulmer tobi...@tmux.org [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
+1 On Jun 9, 2012 5:46 AM, Christiano F. Haesbaert christiano...@gmail.com wrote: On Jun 8, 2012 9:22 PM, Jérémie Courrèges-Anglas jca+o...@wxcvbn.org wrote: Antoine Jacoutot ajacou...@bsdfrog.org 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
* Thomas Pfaff tpf...@tp76.info [120608 23:06]: On Fri, 8 Jun 2012 13:57:35 -0400 Okan Demirmen o...@demirmen.com wrote: On Fri 2012.06.08 at 19:40 +0200, Thomas Pfaff wrote: On Sun, 3 Jun 2012 21:07:13 +0400 Alexander Polakov p...@sdf.org 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
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.
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 Sat, Jun 9, 2012 at 12:41 PM, Stuart Henderson s...@spacehopper.org 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.
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 s...@spacehopper.org :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
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 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
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
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: cwm tiling
On Sat, Jun 9, 2012 at 9:53 AM, Weldon Goree wel...@b.rontosaur.us 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!
Re: cwm tiling
On Sat, Jun 9, 2012 at 2:22 AM, Tobias Ulmer tobi...@tmux.org 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: 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: funmap.c
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 s...@spacehopper.org | 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
