Re: [dwm] Help with the tags mask syntax
On 8/11/08, Giorgio Lando <[EMAIL PROTECTED]> wrote: > I still do not understand how this relates to tag masks like 1 << 8 - 1, > or ~0, which I have seen in some config.h, but I will look to your examples http://en.wikipedia.org/wiki/Bitwise_operation#Arithmetic_shift http://en.wikipedia.org/wiki/Bitwise_operation#NOT
[dwm] Bold font for occupied tags
I don't like those squares, but I still want some indication as to whether a
tag is occupied, so I wrote this patch. It removes the squares, and uses a
different font (specified as boldfont in config.h) for occupied tags.
This is just a quick hack, and bad things will happen if both fonts are not of
the same dimensions.
diff -r ce355cea9bb8 config.def.h
--- a/config.def.h Tue Jul 29 11:32:22 2008 +0100
+++ b/config.def.h Mon Aug 11 06:56:30 2008 +0200
@@ -2,6 +2,7 @@
/* appearance */
static const char font[]=
"-*-terminus-medium-r-normal-*-14-*-*-*-*-*-*-*";
+static const char boldfont[]=
"-*-terminus-bold-r-normal-*-14-*-*-*-*-*-*-*";
static const char normbordercolor[] = "#cc";
static const char normbgcolor[] = "#cc";
static const char normfgcolor[] = "#00";
diff -r ce355cea9bb8 dwm.1
--- a/dwm.1 Tue Jul 29 11:32:22 2008 +0100
+++ b/dwm.1 Mon Aug 11 06:56:30 2008 +0200
@@ -20,13 +20,7 @@
tags. Selecting certain tags displays all windows with these tags.
.P
dwm contains a small status bar which displays all available tags, the layout,
-the title of the focused window, and the text read from standard input. A
-floating window is indicated with an empty square and a maximised
-floating window is indicated with a filled square before the windows
-title. The selected tags are indicated with a different color. The tags of
-the focused window are indicated with a filled square in the top left
-corner. The tags which are applied to one or more windows are indicated
-with an empty square in the top left corner.
+the title of the focused window, and the text read from standard input.
.P
dwm draws a small border around windows to indicate the focus state.
.SH OPTIONS
diff -r ce355cea9bb8 dwm.c
--- a/dwm.c Tue Jul 29 11:32:22 2008 +0100
+++ b/dwm.c Mon Aug 11 06:56:30 2008 +0200
@@ -94,18 +94,21 @@
};
typedef struct {
+ int ascent;
+ int descent;
+ int height;
+ XFontSet set;
+ XFontStruct *xfont;
+} Fount;
+
+typedef struct {
int x, y, w, h;
unsigned long norm[ColLast];
unsigned long sel[ColLast];
Drawable drawable;
GC gc;
- struct {
- int ascent;
- int descent;
- int height;
- XFontSet set;
- XFontStruct *xfont;
- } font;
+ Fount font;
+ Fount boldfont;
} DC; /* draw context */
typedef struct {
@@ -145,8 +148,7 @@
static void detachstack(Client *c);
static void die(const char *errstr, ...);
static void drawbar(void);
-static void drawsquare(Bool filled, Bool empty, Bool invert, unsigned long
col[ColLast]);
-static void drawtext(const char *text, unsigned long col[ColLast], Bool
invert);
+static void drawtext(const char *text, unsigned long col[ColLast], Bool
invert, Bool occupied);
static void enternotify(XEvent *e);
static void expose(XEvent *e);
static void focus(Client *c);
@@ -158,7 +160,7 @@
static Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
static void grabbuttons(Client *c, Bool focused);
static void grabkeys(void);
-static void initfont(const char *fontstr);
+static void initfont(Fount *fount, const char *fontstr);
static Bool isoccupied(unsigned int t);
static Bool isprotodel(Client *c);
static Bool isurgent(unsigned int t);
@@ -505,19 +507,15 @@
dc.x = 0;
for(i = 0; i < LENGTH(tags); i++) {
dc.w = TEXTW(tags[i]);
- if(tagset[seltags] & 1 << i) {
- drawtext(tags[i], dc.sel, isurgent(i));
- drawsquare(sel && sel->tags & 1 << i, isoccupied(i),
isurgent(i), dc.sel);
- }
- else {
- drawtext(tags[i], dc.norm, isurgent(i));
- drawsquare(sel && sel->tags & 1 << i, isoccupied(i),
isurgent(i), dc.norm);
- }
+ if(tagset[seltags] & 1 << i)
+ drawtext(tags[i], dc.sel, isurgent(i), isoccupied(i));
+ else
+ drawtext(tags[i], dc.norm, isurgent(i), isoccupied(i));
dc.x += dc.w;
}
if(blw > 0) {
dc.w = blw;
- drawtext(lt[sellt]->symbol, dc.norm, False);
+ drawtext(lt[sellt]->symbol, dc.norm, False, False);
x = dc.x + dc.w;
}
else
@@ -528,46 +526,24 @@
dc.x = x;
dc.w = ww - x;
}
- drawtext(stext, dc.norm, False);
+ drawtext(stext, dc.norm, False, False);
if((dc.w = dc.x - x) > bh) {
dc.x = x;
- if(sel) {
- drawtext(sel->name, dc.sel, False);
- drawsquare(sel->isfixed, sel->isfloating, False,
dc.sel);
- }
+ if(sel)
+ drawtext(sel->name, dc.sel, False, False);
else
-
Re: [dwm] Help with the tags mask syntax
On Sun 10/08/08, 21:16, Filippo Erik Negroni wrote: > The tag mask is exactly that, a mask: it is not the number of the tag > to use, but a mask that modifies the bits in the tag number. > The tag mask number in config.h is therefore a 'bit-mask': if you use > decimal '4' as the tag mask, the 'bit-mask' becomes bits > 0-0-0-0-0-1-0-0, which when applied, indicates we want the third tag > (the 1 in the third bit from the right) to be selected, hence tag '3'. > I will try and post examples in the 'customisation' link on the wiki > tomorrow, for the general public. Thanks for the nice explanation. Then, if I get it, 6 as a tag mask stays for 0-0-0-0-0-0-1-1-0 and indicates that we want the second and the third tag, while 8 stays for 0-0-0-0-0-1-0-0-0 and indicates that we want the fourth one. Great, I also understand the great felxibility of this system. I still do not understand how this relates to tag masks like 1 << 8 - 1, or ~0, which I have seen in some config.h, but I will look to your examples in the wiki and will probably get it. Giorgio
Re: [dwm] some proposed changes
2008/8/10 Premysl Hruby <[EMAIL PROTECTED]>: > > Hi, > > reason for using XConfigureWindow in restack() is setting border_width > of client (and this is the only reason for not using XMoveResizeWindow > as you propose). > Any of my windows change window border width since it is setted in manage(), but anyway we could use XSetWindowBorderWidth() here. I don't know if it would be better (it saves some loc, but nothing significant), but I wonder why not. > XLowerWindow was used in past, but it makes windows flickering in > monocle layout, as windows are pushed to the bottom of the stack. > Solution currently in use prevent flickering. > I hadn't noticed the flickering, and though I could really live with it I see the point now. > -Ph > > -- > Premysl "Anydot" Hruby, http://www.redrum.cz/ > > Thanks for your answers, -- - yiyus || JGL .
Re: [dwm] xxkb, per window keyboard layout
Hello, * Alexander Polakov <[EMAIL PROTECTED]> [2008-08-10 20:52]: > xneur worked fine for me in the past, should work at the moment too. Has many features that I don't need but has the one I need :o) It works. Thanx a lot! -- cheers stanio_
Re: [dwm] Help with the tags mask syntax
2008/8/10 Giorgio Lando <[EMAIL PROTECTED]>: > Hi, I have been a long term dwm 4.7 user and I have now updated to 5.1. > So far everything goes extremely well, but I do not understand how the > tags mask in config.h works. I have looked in this mailing list for > examples, but I am not able to grasp their logic. > I have verified that I can force a window class in a certain tag n > masking all the tags till n-1: so to emulate the old tag regex 9 I have > to put 1 >> 8 as a tag mask. > But how I force a window class in the first tag? Also, how masking a > certain tag pushes a window class in a certain other (for example if I > use 4 as the tag mask for the windows related to emesene, those windows > take the tag 3; why?). > I have also seen some config.h including three digits values for the tag > mask (such as 200) or using two values with a -. Could someone be so > kind to explain me from a general point of view the syntax of the tag > mask? Hi Giorgio, The tag mask is exactly that, a mask: it is not the number of the tag to use, but a mask that modifies the bits in the tag number. The tag mask number in config.h is therefore a 'bit-mask': if you use decimal '4' as the tag mask, the 'bit-mask' becomes bits 0-0-0-0-0-1-0-0, which when applied, indicates we want the third tag (the 1 in the third bit from the right) to be selected, hence tag '3'. I will try and post examples in the 'customisation' link on the wiki tomorrow, for the general public.
Re: [dwm] grab
On Wed, 6 Aug 2008 13:33:42 -0700 "Evan Gates" <[EMAIL PROTECTED]> wrote: > I love dmenu, and just for the hell of it wanted a similar program, that > didn't display anything. So I wrote grab (more like copied the code I > needed from dmenu). It grabs all key presses until the user hits enter > or escape, and then prints out whatever was typed. It's not foolproof, > it's not very well tested, but it works for me. I run it from dwm the > same way as dmenu. Have fun and do what you will with it. > > -Evan > > P.S. compile with gcc -lX11 why not just add a flag to dmenu to perform in this way?
Re: [dwm] xxkb, per window keyboard layout
xneur worked fine for me in the past, should work at the moment too.
[dwm] Help with the tags mask syntax
Hi, I have been a long term dwm 4.7 user and I have now updated to 5.1. So far everything goes extremely well, but I do not understand how the tags mask in config.h works. I have looked in this mailing list for examples, but I am not able to grasp their logic. I have verified that I can force a window class in a certain tag n masking all the tags till n-1: so to emulate the old tag regex 9 I have to put 1 >> 8 as a tag mask. But how I force a window class in the first tag? Also, how masking a certain tag pushes a window class in a certain other (for example if I use 4 as the tag mask for the windows related to emesene, those windows take the tag 3; why?). I have also seen some config.h including three digits values for the tag mask (such as 200) or using two values with a -. Could someone be so kind to explain me from a general point of view the syntax of the tag mask? Thanks in advance Giorgio Lando
[dwm] xxkb, per window keyboard layout
Hello to all on the list. I used to be a wmii user for nearly 2 years on one computer of mine. For about the same time I used dwm under Solaris on other computer (cos I haven't manage to get wmii compiled there :o| , I considered dwm kind of fallback). Until about 2 months ago, when I've got some, in my opinion, transcendent :o) behaviour in wmii which I haven't found motivation to investigate the cause for. This was the occasion to think about converting to dwm at home too. I realized - I don't use many features of wmii - run-time reconfigurability is a nice to have, but not a real limitation when - the Xsession does not hang on the WM and - the tag rules are reasonable - make && make install && dwm does not take too long - dwm has significantly better response time when the machine is slow - ... So I've done the single logical thing: I now use dwm everywhere I have impact on the WM choice. All I want to say: I am nearly perfectly happy with dwm! Thanks a lot to all contributors! The *only* problem is: A big deal of the things I type is Cyrillic, so I need to use at least 2 keyboard layouts. Usually, the windows in which I type Cyrillic and the ones I type Latin, are different. Xxkb is exactly about this: remembering the keyboard layout for each window. This means for example: - default keyboard layout is DEF (alternative is ALT) - start terminal A - start terminal B - focus window A - layout in window A is DEF - change layout to ALT - layout in window A is ALT - focus window B - layout in window B is DEF - focus window A - layout in window A is ALT (preserved after focus switch) Unfortunately, this does not work in dwm. This problem was reported once, here: http://article.gmane.org/gmane.comp.window-managers.dwm/826 , but I didn't found any follow-ups. I found the same problem reported for xmonad (which I also tried out and verified) here: http://www.haskell.org/pipermail/xmonad/2008-April/005439.html . There, some more background is given on the subject (like xxkb relying on XReparentWindow ...). The issue appears to be closed for xmonad being xxkb issue. My questions: - Is there a way to workaround this? - Is there a quick "fix", better said hack, in dwm to allow xxkb work as expected? A hint where I should look in the code? - Does anybody know alternative tool or setting to do the job in dwm-compliant manner ? Thank you in advance for your suggestions and hints! -- cheers stanio_
Re: [dwm] some proposed changes
On (09/08/08 12:55), yy wrote: > To: dwm mail list > From: yy <[EMAIL PROTECTED]> > Subject: [dwm] some proposed changes > Reply-To: dwm mail list > List-Id: dwm mail list > > Attached there is a patch with some changes to dwm.c. It uses > XLowerWindow and XMoveResizeWindow instead of configure functions in > restack() and resize() respectively. I suposse there is a good reason > to use configure here, but since Anselm is on holidays I ask here if > somebody knows the reason. I'm using it this way and have found no > problems so far but they could appear with tricky programs. It removes > some loc and I think the code is a bit more consistent this way. > The other change is a new click option: ClkTagButton, this way you can > have buttons in the tags to see previous tags or to see all of them. > Anyway, the comment in config.def.h should be corrected to explain the > current behaviour with ClkTagBar. My config.h is attached too, with > some interesting custom functions. > > Greets, > Hi, reason for using XConfigureWindow in restack() is setting border_width of client (and this is the only reason for not using XMoveResizeWindow as you propose). XLowerWindow was used in past, but it makes windows flickering in monocle layout, as windows are pushed to the bottom of the stack. Solution currently in use prevent flickering. -Ph -- Premysl "Anydot" Hruby, http://www.redrum.cz/
[dwm] Feature request: cursor position when resizing
Hi, list: Default way of resizing is Modkey-mouse3, then cursor is put at bottom-right of window. Sometimes I want the cursor is at top-right, sometimes top-left, bottom left... So, if Modkey-mouse3 is for resizing and put the cursor at bottom-right, and I can use Modkey-shift-mouse3 to toggle the cursor position(top-right -> top-left -> bottom-left -> bottom-right), it would be very nice. -- Reguards, anhnmncb. PGP key: 44A31344
Re: [dwm] [patch] minor cleanups
On 8/4/08, Johannes Hofmann <[EMAIL PROTECTED]> wrote:
> attached are two minor cleanups. The first simplifies grabkeys()
> similar to grabbuttons().
i've just realized that there is a problem with the patch: numlockmask
is modified but modifiers isn't
void
grabkeys(void) {
unsigned int i, j;
unsigned int modifiers[] = { 0, LockMask, numlockmask,
numlockmask|LockMask };
KeyCode code;
XModifierKeymap *modmap;
/* init modifier map */
modmap = XGetModifierMapping(dpy);
for(i = 0; i < 8; i++)
for(j = 0; j < modmap->max_keypermod; j++) {
if(modmap->modifiermap[i * modmap->max_keypermod + j] ==
XKeysymToKeycode(dpy, XK_Num_Lock))
numlockmask = (1 << i);
}
XFreeModifiermap(modmap);
XUngrabKey(dpy, AnyKey, AnyModifier, root);
for(i = 0; i < LENGTH(keys); i++) {
code = XKeysymToKeycode(dpy, keys[i].keysym);
for(j = 0; j < LENGTH(modifiers); j++)
XGrabKey(dpy, code, keys[i].mod | modifiers[j], root,
True,
GrabModeAsync, GrabModeAsync);
}
}
Re: [dwm] DWMII layout with a "more better" integration
Donald Chai wrote:
@pancake :
> I dont see any point for having a function called
> "dwmiinoinfiniteloop"
Well this function is necessary, I didn't know how to call it, though
its name is relevant... If you don't like its name feel free to change
it but I won't. The important thing is that it does its job.
I think what "pancake" meant is that code that needs a function called
"dwmiinoinfiniteloop" can usually be rewritten to not require it,
improving maintainability. From what I can tell, it unsets the second
dwmii bit it finds, merging the second column of windows into the first
column. Why?
--snip--
void dwmiinoinfiniteloop(void)
{
Client* firstclients = nexttiled(clients),*t = firstclients;
for( ; t && !t->dwmii ; t = nexttiled(t->next) );
firstclients->dwmii = 1;
if ( t && (t != firstclients) ) { t->dwmii = 0; }
}
The code below contains lots of "if's" that seem to be always true (or
should be). Why check them? You don't call dwmiilayoutcol unless if
(lt[sellt]->arrange == dwmiilayoutcol). Also, the line
if (t->dwmii)
should always be true. Otherwise, you'll get an infinite loop. I think
it'd be better to remove this check (and not explicitly set
firstclients->dwmii=1). This might work better for the case of windows
having multiple tags...
void dwmiilayoutcol(void)
{
Client *firstclients = nexttiled(clients);
if ( !firstclients || (lt[sellt]->arrange != dwmiilayoutcol) ) {
return; }
dwmiinoinfiniteloop();
Client *t = nexttiled(firstclients->next);
int n = 1;
for( ; t ; n += ( t->dwmii ? 1 : 0 ),t = nexttiled(t->next) );
int x = wx,dw = ww / n;
for ( t = firstclients ; t ; )
{
if ( t->dwmii )
{
n = 1;
Client *s = nexttiled(t->next);
for( ; s && !s->dwmii ; n++,s = nexttiled(s->next) );
int dh = wh / n,y = wy + dh;
resize(t,x,wy,dw - 2 * t->bw,dh - 2 * t->bw,resizehints);
for( t = nexttiled(t->next) ; t && !t->dwmii ; t =
nexttiled(t->next) )
{
resize(t,x,y,dw - 2 * t->bw,dh - 2 * t->bw,resizehints);
y += dh;
}
x += dw;
}
}
}
Here's the c file as said.
Kind regards,
QUINTIN Guillaume.
/*
* I used WMII and found it too "heavy". So I switched to dwm but I
* quickly missed the possibilities of having several columns,
* several windows in each column and moving the windows from a
* column into another or change the windows' order within a column.
* As there were no patch (or layout) providing that, I wrote one.
* I also added a layout that does the same thing but arrange the
* windows by rows.
*
* The col dwmii layout :
*
* +--+--+--+
* | | | |
* +--+ | |
* | +--+ |
* +--+ | |
* | | | |
* +--+--+--+
*
* The row dwmii layout :
*
* +--+---+--+
* + | | +
* +--+-+-+--+
* |||
* +++
* | |
* +-+
*
* You can move a window to the next/previous columnn, after the next
* window or before the previous window within a column by simple
* combination of keys (the same as in WMII).
*
* To get the dwmii layouts working you have to :
* - have DWM version 5.1
* - add these lines in the config.h file :
* - just before the layouts array :
*
* #include "dwmii.c"
*
* - in the layouts array :
*
* { "COL", dwmiilayoutcol },
* { "ROW", dwmiilayoutrow },
*
* - in the keys array :
*
* { MODKEY, XK_c, setlayout, {.v = &layouts[1]} },
* { MODKEY, XK_r, setlayout, {.v = &layouts[2]} },
* { MODKEY|ShiftMask, XK_Up, dwmiikeypressed, {.i = XK_Up} },
* { MODKEY|ShiftMask, XK_Left, dwmiikeypressed, {.i = XK_Left} },
* { MODKEY|ShiftMask, XK_Down, dwmiikeypressed, {.i = XK_Down} },
* { MODKEY|ShiftMask, XK_Right, dwmiikeypressed, {.i = XK_Right} },
* { MODKEY|ShiftMask, XK_n, dwmiitoggle, {0} },
*
* - add this line in the Client struct definition in the dwm.c file :
*
* int dwmii;
*
* - compile and it should work !
*
* The dwmiitoggle sets the dwmii variable of a window, when
* the dwmii is non zero then the window marks the start of a
* new column/row depending on the layout used.
*
* As Donald Chai told me the dwmiimarkfirstwindow function is not necessary.
* You can comment the two calls to this function in the dwmiilayoutXXX
* functions or simply suppress these lines and the function as well.
* the differences is in the way the windows are arranged. If you suppress
* the function, then the first window of the first column of a tag will not
* necessarily have its dwmii set to non zero, which means when you will select
* several tags at once, the column you saw in a given tag will not necessarily
* be a column !
*
* Enjoy it and feel free to send me all your comments !
*
* QUINTIN Guillaume
*
*/
static void dwmiitoggle(co
