[dev] [dwm] problem with configurenotify()
Hi!
I noticed a problem with the dwm bar when the geometry of a monitor
changes twice in a row. The problem is in configurenotify() and
updategeom(). When two configure notify events come in a row, the
first for a smaller geometry than the next, updategeom uses the
Xinerama info to get the current screen geometry, not the one
reported by the event. In configurenotify the dc.drawable will be
created with the width of the notify event, while the monitors
already know about the actual bigger size of the screen. When the
second configure notify event is seen by dwm, the dc.drawable will
not be recreated in the needed size, because updategeom() doesn't
see any changes.
There could also be a kind of window leaking. updatebars() will
always create new barwins for monitors that might have changed. I
didn't see any code that destroys the barwin besides the one in
cleanupmon(), so I assume there will be additional barwins after a
geometry change.
This is a patch that addresses both problems:
diff -r 2bcd25cce4ab dwm.c
--- a/dwm.c Sun Sep 27 20:20:14 2009 +0100
+++ b/dwm.c Thu Oct 01 11:33:49 2009 +0200
@@ -540,19 +540,18 @@
void
configurenotify(XEvent *e) {
- Monitor *m;
XConfigureEvent *ev = e-xconfigure;
if(ev-window == root) {
- sw = ev-width;
- sh = ev-height;
- if(updategeom()) {
+ if (sw != ev-width) {
+ sw = ev-width;
if(dc.drawable != 0)
XFreePixmap(dpy, dc.drawable);
dc.drawable = XCreatePixmap(dpy, root, sw, bh,
DefaultDepth(dpy, screen));
+ }
+ sh = ev-height;
+ if(updategeom()) {
updatebars();
- for(m = mons; m; m = m-next)
- XMoveResizeWindow(dpy, m-barwin, m-wx, m-by,
m-ww, bh);
arrange(NULL);
}
}
@@ -613,6 +612,7 @@
m-mfact = mfact;
m-showbar = showbar;
m-topbar = topbar;
+ m-barwin = None;
m-lt[0] = layouts[0];
m-lt[1] = layouts[1 % LENGTH(layouts)];
strncpy(m-ltsymbol, layouts[0].symbol, sizeof m-ltsymbol);
@@ -1711,11 +1711,14 @@
wa.background_pixmap = ParentRelative;
wa.event_mask = ButtonPressMask|ExposureMask;
for(m = mons; m; m = m-next) {
- m-barwin = XCreateWindow(dpy, root, m-wx, m-by, m-ww, bh,
0, DefaultDepth(dpy, screen),
- CopyFromParent, DefaultVisual(dpy,
screen),
-
CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
- XDefineCursor(dpy, m-barwin, cursor[CurNormal]);
- XMapRaised(dpy, m-barwin);
+ if (m-barwin == None) {
+ m-barwin = XCreateWindow(dpy, root, m-wx, m-by,
m-ww, bh, 0, DefaultDepth(dpy, screen),
+ CopyFromParent,
DefaultVisual(dpy, screen),
+
CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
+ XDefineCursor(dpy, m-barwin, cursor[CurNormal]);
+ XMapRaised(dpy, m-barwin);
+ } else
+ XMoveResizeWindow(dpy, m-barwin, m-wx, m-by, m-ww,
bh);
}
}
--
Eckehard Berns
Re: [dev] dwm and -geometry
But I would be more happy if I could decide which windows would remain floating when I turn to the tabbed mode. Although I don't think this is a good way to use dwm, the following patch to tip should make dwm put windows with user specified geometry into floating mode. diff -r 2bcd25cce4ab dwm.c --- a/dwm.c Sun Sep 27 20:20:14 2009 +0100 +++ b/dwm.c Sun Oct 04 00:51:27 2009 +0200 @@ -86,7 +86,7 @@ int basew, baseh, incw, inch, maxw, maxh, minw, minh; int bw, oldbw; unsigned int tags; - Bool isfixed, isfloating, isurgent; + Bool isfixed, isfloating, isurgent, hasusergeom; Client *next; Client *snext; Monitor *mon; @@ -1138,7 +1138,7 @@ XSelectInput(dpy, w, EnterWindowMask|FocusChangeMask|PropertyChangeMask|StructureNotifyMask); grabbuttons(c, False); if(!c-isfloating) - c-isfloating = trans != None || c-isfixed; + c-isfloating = trans != None || c-isfixed || c-hasusergeom; if(c-isfloating) XRaiseWindow(dpy, c-win); attach(c); @@ -1878,6 +1878,7 @@ c-maxa = c-mina = 0.0; c-isfixed = (c-maxw c-minw c-maxh c-minh c-maxw == c-minw c-maxh == c-minh); + c-hasusergeom = (size.flags USPosition) || (size.flags USSize); } void -- Eckehard Berns
Re: [dev] dwm taskbar icons via pcf font
Thanks Bryan, your icons work, but only in my terminal not xterm when I choose Tamsyn2 font and echo -e \xC1, however when I edited your font with my gbdfed, saved, reconverted, and put it into /usr/share/fonts/local/, ran my terminal and echo -e \xA1(my added icon) didn't show up, but produced empty string, however , when I replaced your icon under C1 index and tried the same it did show up with my icon. So newly added icons do not work, when modifying your icons work, ahh, this is so jinxed. This is the only way I got it all working, do you have any ideas why)? You could try to call xset fp rehash after you installed the new font. X caches font information, so a rehash might show up new font glyphs. -- Eckehard Berns
Re: [dev] suckless wget/curl
[...] but it's entirely possible to read chunked transfer with shell. I wrote a stupid proof of concept AUR agent in bash which handles keep-alives and chunked/gzip encoded data -- the only other dependencies are dd and gzip, and optionally yajl (for formatting jsons). Cool, forgot about dd for this. -- Eckehard Berns
Re: [dev] ideas on suckless file manager
The Tamsyn guy says it's an aliased font. What does it mean? He means it's not anti-aliased. See also http://en.wikipedia.org/wiki/Aliasing -- Eckehard Berns
Re: [dev] [wmii] Flash in fullscreen regularly freezes screen
putting the flash player on a website into fullscreen regularly (very -.-) freezes my screen. I think it's a Linux kernel problem. I also have encountered freezes with fullscreen flash video playback (I haven't tested something other than youtube). I noticed that I didn't encounter those freezes when using compositing. Thus I simply added a xcompmgr to my .xinitrc. I don't know if it helps with other setups. I thought this problem was kinda unique to my setup. -- Eckehard Berns
Re: [dev] [dwm] OpenOffice popups go to the wrong tag
On Tue, Aug 09, 2011 at 04:32:52PM +0100, Nick wrote:
* I have oocalc in tag 1
* I have tag 2 active
* I open a new oocalc, with a password-protected file
PROBLEM: the enter password floating window is opened in
tag 1 (as it's associated with the original oocalc, I
suppose.)
Now, it goes without saying that this is likely to be
OpenOffice's fault rather than dwm.
Hmm, hard to say. I _think_ the password dialog could make itself a
transient window for itself. But then again, that sounds wrong, too.
I'm wondering if it's known behaviour, or if there's something dwm
should handle differently (or could through config.h)?
Dwm does this by intention. In manage() in dwm.c the code explicitly
checks, whether the new window is a transient for an already managed
client. If so, the tags and monitor settings are copied from the main
window (in your case the ooclac window already open).
I haven't tested this, but something like
diff -r 131d4f6a8a1e dwm.c
--- a/dwm.c Fri Jul 29 20:01:22 2011 +0200
+++ b/dwm.c Tue Aug 09 17:49:07 2011 +0200
@@ -1109,8 +1109,9 @@
c-win = w;
updatetitle(c);
if(XGetTransientForHint(dpy, w, trans) (t = wintoclient(trans))) {
- c-mon = t-mon;
- c-tags = t-tags;
+ /* c-mon = t-mon;
+ c-tags = t-tags; */
+ c-mon = selmon;
}
else {
c-mon = selmon;
could help you with oocalc (and might break other applications'
behaviours).
--
Eckehard Berns
***SPAM*** Re: [dev] [dwm] xev's window refuses to float
On Fri, Aug 12, 2011 at 09:39:00PM +0200, Bastien Dejean wrote:
I have included the following line in the rules array of my config.h :
{ NULL, NULL,Event Tester, 0,True,
-1 },
But I don't get the expected result (xev's window stays tiled).
Dwm doesn't seem to apply rules to clients without a class hint.
A fix could be something like this:
8---8---
diff -r 131d4f6a8a1e dwm.c
--- a/dwm.c Fri Jul 29 20:01:22 2011 +0200
+++ b/dwm.c Sat Aug 13 10:31:14 2011 +0200
@@ -296,24 +296,25 @@
if(XGetClassHint(dpy, c-win, ch)) {
class = ch.res_class ? ch.res_class : broken;
instance = ch.res_name ? ch.res_name : broken;
- for(i = 0; i LENGTH(rules); i++) {
- r = rules[i];
- if((!r-title || strstr(c-name, r-title))
-(!r-class || strstr(class, r-class))
-(!r-instance || strstr(instance, r-instance)))
- {
- c-isfloating = r-isfloating;
- c-tags |= r-tags;
- for(m = mons; m m-num != r-monitor; m =
m-next);
- if(m)
- c-mon = m;
- }
+ } else
+ class = instance = broken;
+ for(i = 0; i LENGTH(rules); i++) {
+ r = rules[i];
+ if((!r-title || strstr(c-name, r-title))
+(!r-class || strstr(class, r-class))
+(!r-instance || strstr(instance, r-instance)))
+ {
+ c-isfloating = r-isfloating;
+ c-tags |= r-tags;
+ for(m = mons; m m-num != r-monitor; m = m-next);
+ if(m)
+ c-mon = m;
}
- if(ch.res_class)
- XFree(ch.res_class);
- if(ch.res_name)
- XFree(ch.res_name);
}
+ if(ch.res_class)
+ XFree(ch.res_class);
+ if(ch.res_name)
+ XFree(ch.res_name);
c-tags = c-tags TAGMASK ? c-tags TAGMASK :
c-mon-tagset[c-mon-seltags];
}
8---8---
--
Eckehard Berns
Re: [dev] [dwm] xev's window refuses to float
This should definitely be fixed in mainline. I've attached an alternative patch which is basically the same as yours, but imo slightly neater. I do like your patch, something paranoid in me just wanted to point out that your patch relies on the implementation of XGetClassHint not tempering with ch when returning failure. I don't believe this really matters though. -- Eckehard Berns
Re: [dev] [dwm] xev's window refuses to float
On Sat, Aug 13, 2011 at 10:08:08PM +0100, Connor Lane Smith wrote: On 13 August 2011 21:41, Eckehard Berns ecki-suckl...@ecki.to wrote: I do like your patch, something paranoid in me just wanted to point out that your patch relies on the implementation of XGetClassHint not tempering with ch when returning failure. So does yours: it calls XFree on the two ch strings whether or not XGetClassHint succeeded. Good point :) -- Eckehard Berns
Re: [dev] Some questions about st and a patch
Can anyone please try it with his favourite modifed-arrow-key-using software with TERM=st and TERM=xterm? It looks like in joe st behaves exactly like xterm (which is: starting a selction as expected with ctrl, and inserting A, B, C and Ds with shift and alt). In Vim nothing really works regardless of the TERM settings (Vim inserts parts of the control sequences etc.). Haven't tried anything else. I don't use arrow keys if I can avoid them and thus am not very familiar which software supports modifier keys with arrows. -- Eckehard Berns
Re: [dev] st features that'd be nice
..., which would be a good starting point to trace the problem (unless someone already knows what the problem is). I would assume the problem is the excessive redrawing of the whole terminal window. Each time you move the curser only one cell the whole screen will be redrawn into a backup pixmap and then the whole pixmap will be copied to the window. Also, when the screen is redrawn by the application (maybe due to a page up/down) st's draw() will be called multiple times due to the kernel buffer size of pipes, which will result in redrawing the entire window multiple times. I have experimented with remembering the min and max row of changes since the last call to draw() (and only drawing that portion of the screen) a while ago. It adds a few lines to the code but on my system it did lower the CPU usage of X. I stopped looking into this because I have other issues with st besides performance at the moment (mainly xterm compatibility - I ssh into a few machines and installing a new terminfo everywhere is no option for me). -- Eckehard Berns
Re: [dev] ssh-agent stanza in POSIX shell
I've found the following clever ssh-agent stanza in Richard Crowley's
`.profile`[https://raw.github.com/rcrowley/home/master/.profile]:
which ssh-agent /dev/null {
: ${SSH_AUTH_SOCK:=$(echo /tmp/ssh-*/agent.* | cut -d -f1)}
[ -S $SSH_AUTH_SOCK ] {
export SSH_AUTH_SOCK
} || {
eval $(ssh-agent)
ssh-add
}
}
Wondering why it doesn't work properly in OpenBSD ksh as I am not so
good with POSIX sh.
Can't really tell which part doesn't work in OpenBSD ksh (I got used to
mksh and it got a lot of bashism lately). Anyway, I personally would
rather write it like this (not tested, I personally use
~/.ssh-agent-info to store ssh-agent's socket and PID):
if which ssh-agent /dev/null
then
test -z $SSH_AUTH_SOCK \
SSH_AUTH_SOCK=`echo /tmp/ssh-*/agent.* | cut -d\ -f1`
if test -S $SSH_AUTH_SOCK
then
export SSH_AUTH_SOCK
else
eval `ssh-agent`
ssh-add
fi
fi
Hmm, just glanced over OpenBSD's manual for ksh and it seems all
constructs used are supported by OpenBSD's ksh - so the original code
should work there too... strange... or is TMPDIR set to something other
then /tmp? Does ssh-agent place its socket into /tmp/ssh-*/agent.*? (The
manual only states the socket lives in $TMPDIR/ssh-*/agent._ppid_.)
--
Eckehard Berns
Re: [dev] dwm: bug in fullscreen mode (SDL?)
It seems like sensible behavior to go into mainline SDL; any reason not to send this patch their way? I just tried the patch at home and it doesn't work. I also reviewed dwm's source code and my memory of the bar being risen was a bit faulty. I still think the stacking order is the problem here, but it seems my solution isn't the best. At work I'm on a 32-bit system, here I'm on 64-bit. I don't know if this makes any difference or if there is another problem. It might be a race condition between the XRaiseWindow in SDL and the receiving of the screen resize event in dwm. -- Eckehard Berns
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Wed, Jan 11, 2012 at 10:20:43PM +0100, Anselm R Garbe wrote:
On 11 January 2012 18:30, Eckehard Berns ecki-suckl...@ecki.to wrote:
Thinking about this, another way to fix this problem would be to
change all XRaiseWindow calls in dwm to restacking them just below the
bar and never raising the bar. That way dwm would play nicely with other
override redirect windows as well. I don't know if that would be worth
it.
I need to try this, as this sounds like a sensible way to fix this
issue. If it does, then I have no objection putting this into mainline
dwm.
I thought a bit more about this and I don't think the solution is so
easy. I'd assume that you don't want every override redirect window to
be always on top. Also, floating windows are above the bar at the
moment, which is what you would expect IMHO. That means that there is no
suitable window to align the stacking of floating windows to.
And as it seems, the floating WMwindow of SDL is the main problem here.
On a related note, while investigating the SDL-problem further I found a
leak in dwm: updatebars() always creates new barwins. I attached a patch
to skip the creation of a new barwin if the monitor already has one.
This is why I thought the barwin would be raised, but instead a new one
is created (which has the same effect).
What remains is the floating WMwindow which will be raised in restack().
Does anyone remember why the code in lines 1423 and 1424 is neccessary?
Without it the SDL problem doesn't occure on my system any more (without
the need to patch SDL itself). I attached the second patch for anyone
who wants to try this.
--
Eckehard Berns
diff -r 6f54bd1ef439 dwm.c
--- a/dwm.c Wed Jan 04 13:30:12 2012 +0100
+++ b/dwm.c Wed Jan 11 22:29:57 2012 +0100
@@ -1827,6 +1827,8 @@
.event_mask = ButtonPressMask|ExposureMask
};
for(m = mons; m; m = m-next) {
+ if (m-barwin)
+ continue;
m-barwin = XCreateWindow(dpy, root, m-wx, m-by, m-ww, bh,
0, DefaultDepth(dpy, screen),
CopyFromParent, DefaultVisual(dpy,
screen),
CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
diff -r 6f54bd1ef439 dwm.c
--- a/dwm.c Wed Jan 04 13:30:12 2012 +0100
+++ b/dwm.c Wed Jan 11 22:35:27 2012 +0100
@@ -1420,8 +1420,6 @@
drawbar(m);
if(!m-sel)
return;
- if(m-sel-isfloating || !m-lt[m-sellt]-arrange)
- XRaiseWindow(dpy, m-sel-win);
if(m-lt[m-sellt]-arrange) {
wc.stack_mode = Below;
wc.sibling = m-barwin;
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Thu, Jan 12, 2012 at 07:39:53AM +0100, Anselm R Garbe wrote:
I applied your two patches to tip, this needs to be tested for side effects
now.
Ok, I ran into trouble pretty fast. Since the floating windows are never
raised in restack() they won't get raised during normal interaction
either.
I attached a somewhat ugly patch to correct the behavior, but there
might be consequences, too. Instead of simply adding XRaiseWindow() I
replaced calls to restack() in focusstack(), movemouse(), and
resizemouse(). I assume restacking isn't needed there and the calls to
restack() simple where a glorified XRaiseWindow() anyway, but I'm not
too familiar with the dwm code, so I might be wrong.
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 22:07:34 2012 +0100
@@ -907,7 +907,8 @@
}
if(c) {
focus(c);
- restack(selmon);
+ if (selmon-sel-isfloating)
+ XRaiseWindow(dpy, selmon-sel-win);
}
}
@@ -1227,7 +1228,7 @@
if(!(c = selmon-sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1371,7 +1372,7 @@
if(!(c = selmon-sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1738,9 +1739,11 @@
if(!selmon-sel)
return;
selmon-sel-isfloating = !selmon-sel-isfloating ||
selmon-sel-isfixed;
- if(selmon-sel-isfloating)
+ if(selmon-sel-isfloating) {
resize(selmon-sel, selmon-sel-x, selmon-sel-y,
selmon-sel-w, selmon-sel-h, False);
+ XRaiseWindow(dpy, selmon-sel-win);
+ }
arrange(selmon);
}
Re: [dev] dwm: bug in fullscreen mode (SDL?)
On Thu, Jan 12, 2012 at 10:23:14PM +0100, Eckehard Berns wrote:
I attached a somewhat ugly patch to correct the behavior, ...
Oops, we need raising in focusstack() not only for floating windows, but
also if we're in a floating layout. Corrected patch is attached.
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 22:27:51 2012 +0100
@@ -907,7 +907,8 @@
}
if(c) {
focus(c);
- restack(selmon);
+ if (selmon-sel-isfloating ||
!selmon-lt[selmon-sellt]-arrange)
+ XRaiseWindow(dpy, selmon-sel-win);
}
}
@@ -1227,7 +1228,7 @@
if(!(c = selmon-sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1371,7 +1372,7 @@
if(!(c = selmon-sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1738,9 +1739,11 @@
if(!selmon-sel)
return;
selmon-sel-isfloating = !selmon-sel-isfloating ||
selmon-sel-isfixed;
- if(selmon-sel-isfloating)
+ if(selmon-sel-isfloating) {
resize(selmon-sel, selmon-sel-x, selmon-sel-y,
selmon-sel-w, selmon-sel-h, False);
+ XRaiseWindow(dpy, selmon-sel-win);
+ }
arrange(selmon);
}
Re: [dev] dwm: bug in fullscreen mode (SDL?)
Sorry for spamming the list, but I didn't catch monocle mode with the
last patch. Here is a corrected patch...
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Thu Jan 12 23:56:15 2012 +0100
@@ -907,6 +907,8 @@
}
if(c) {
focus(c);
+ if (selmon-sel-isfloating ||
!selmon-lt[selmon-sellt]-arrange)
+ XRaiseWindow(dpy, selmon-sel-win);
restack(selmon);
}
}
@@ -1227,7 +1229,7 @@
if(!(c = selmon-sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1371,7 +1373,7 @@
if(!(c = selmon-sel))
return;
- restack(selmon);
+ XRaiseWindow(dpy, selmon-sel-win);
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
@@ -1738,9 +1740,11 @@
if(!selmon-sel)
return;
selmon-sel-isfloating = !selmon-sel-isfloating ||
selmon-sel-isfixed;
- if(selmon-sel-isfloating)
+ if(selmon-sel-isfloating) {
resize(selmon-sel, selmon-sel-x, selmon-sel-y,
selmon-sel-w, selmon-sel-h, False);
+ XRaiseWindow(dpy, selmon-sel-win);
+ }
arrange(selmon);
}
Re: [dev] dwm: bug in fullscreen mode (SDL?)
I attached a somewhat ugly patch to correct the behavior, [...]
Since I didn't like how this patch turned out I looked into this a bit
further. Attached is a less intrusive patch, once to tip and once to
6.0. I ran this patch for a day or so and didn't have any issues.
If no problems show up I think this is a better way of dealing with the
SDL problem.
--
Eckehard Berns
diff -r 070112b7435f dwm.c
--- a/dwm.c Thu Jan 12 07:36:05 2012 +0100
+++ b/dwm.c Sat Jan 14 12:34:59 2012 +0100
@@ -397,9 +397,10 @@
showhide(m-stack);
else for(m = mons; m; m = m-next)
showhide(m-stack);
- if(m)
+ if(m) {
arrangemon(m);
- else for(m = mons; m; m = m-next)
+ restack(m);
+ } else for(m = mons; m; m = m-next)
arrangemon(m);
}
@@ -408,7 +409,6 @@
strncpy(m-ltsymbol, m-lt[m-sellt]-symbol, sizeof m-ltsymbol);
if(m-lt[m-sellt]-arrange)
m-lt[m-sellt]-arrange(m);
- restack(m);
}
void
@@ -1420,6 +1420,8 @@
drawbar(m);
if(!m-sel)
return;
+ if(m-sel-isfloating || !m-lt[m-sellt]-arrange)
+ XRaiseWindow(dpy, m-sel-win);
if(m-lt[m-sellt]-arrange) {
wc.stack_mode = Below;
wc.sibling = m-barwin;
diff -r ec4baab78314 dwm.c
--- a/dwm.c Mon Dec 19 15:38:30 2011 +0100
+++ b/dwm.c Sat Jan 14 12:35:50 2012 +0100
@@ -397,9 +397,10 @@
showhide(m-stack);
else for(m = mons; m; m = m-next)
showhide(m-stack);
- if(m)
+ if(m) {
arrangemon(m);
- else for(m = mons; m; m = m-next)
+ restack(m);
+ } else for(m = mons; m; m = m-next)
arrangemon(m);
}
@@ -408,7 +409,6 @@
strncpy(m-ltsymbol, m-lt[m-sellt]-symbol, sizeof m-ltsymbol);
if(m-lt[m-sellt]-arrange)
m-lt[m-sellt]-arrange(m);
- restack(m);
}
void
@@ -1827,6 +1827,8 @@
.event_mask = ButtonPressMask|ExposureMask
};
for(m = mons; m; m = m-next) {
+ if (m-barwin)
+ continue;
m-barwin = XCreateWindow(dpy, root, m-wx, m-by, m-ww, bh,
0, DefaultDepth(dpy, screen),
CopyFromParent, DefaultVisual(dpy,
screen),
CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
Re: [dev] dwm: bug in fullscreen mode (SDL?)
This seems to have broken my floating windows - if I have a floating XTerm and open a new XTerm (tiled), the floating XTerm ends up behind the tiled one and I can no longer raise the floating one above. Another thing which seems to have been lost is the feature of clicking a floating window raises it to the top; I use this a lot as I unfortunately find myself using The GIMP regularly at work. The confnotify-tip.patch from my previous mail[1] should fix this hopefully. [1] http://lists.suckless.org/dev/1201/10607.html -- Eckehard Berns
Re: [dev] st: Font problem
On Mon, Jan 16, 2012 at 07:15:16PM +0100, François Chaix wrote: I would like to report and ask for help about a problem I have executing st. I get this message : [...] I can't say why the default FONT configuration of st wouldn't work in Fedora, but it could be that the exact font sizes requested are not there. I tested to configure st with #define FONT -*-terminus-medium-r-*-*-8-*-*-*-*-*-*-* witch is the font I use in dwm (and it works, dwm find the font). Same output error. As far as I know terminus starts with 12 pixel height, which would explain why you won't get a font there. You might want to replace the 8 with a 12 there and try again. You could also use xfontsel (if installed) to get a font pattern that results in the font you want to use. Dwm actually uses a fallback font in case it can't find the font you specify. This might be why you don't experience problems there. -- Eckehard Berns
Re: [dev] dwm: bug in fullscreen mode (SDL?)
I just want to mention this breaks raising my floating windows also. Reverting the lines from the patch: - if(m-sel-isfloating || !m-lt[m-sellt]-arrange) - XRaiseWindow(dpy, m-sel-win); seems to fix it again. That's why I attacked the SDL problem from another angle. The patch from my privious mail[1] should fix this and the SDL problem. [1] http://lists.suckless.org/dev/1201/10607.html -- Eckehard Berns
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
On Sun, Jan 22, 2012 at 07:14:03PM +0100, Anselm R Garbe wrote: 2012/1/22 Hadrian Węgrzynowski hadr...@hawski.com: I will repeat my self. Read this first: http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html I did, however there should be a way to prevent similar issues from happening anyways. Next year someone sez press Ctrl-Alt-something this will crash the running X client ;) I don't think it's a good idea to add complexity to a suckless program for a _bug_ in X (that is kinda fixed already). Even xscreensaver doesn't want to fight X insecurities[1]. [1] http://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bs -- Eckehard Berns
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
On Sun, Jan 22, 2012 at 09:15:53PM +0100, pancake wrote: On Jan 22, 2012, at 21:08, hiro 23h...@googlemail.com wrote: People used to take their steering wheels with them so that nobody drives their car away. So I think your approach should work. Perhaps you could take away the whole keyboard. It's very easy on my thinkpad. Only 7 screws away from perfect security. usb keyboard will bypass your security protections against this. That's a bug in your machine. You can fix with duct tape or so I heard. -- Eckehard Berns
Re: [dev] [slock] kill slock with Ctrl+Alt+Multiply
On Sun, Jan 22, 2012 at 10:10:23PM +0100, hiro wrote: Well, I already did break one of my usb ports. That's the spirit! Should be easy to break the other two. But then also beware of the pcmcia ports. You can use a cheap FPGA to hack the whole PC using DMA over pci or so I heard. Seems we need to think bigger. Anyone know some mercenaries to get a preemptive strike on those damn hardware manufacturers? Hmm, preferably cheap? -- Eckehard Berns
Re: [dev] [st] font help
On Mon, Jan 23, 2012 at 04:21:20AM -0500, Christopher Lunsford wrote: I've also installed the terminfo for st, but the screen is still garbled. The default font in config.def.h works great however I cannot use anyother font. From your screenshot I would guess that the font pattern you specified isn't strict enough. St uses the maximum width of all characters in all fonts in the font set to calculate how wide the characters are. That's why you have these gaps between the different batches of chars. I usually specify at least the first four sections, the pxlsize and maybe the avgWidth, e.g. --misc-fixed-medium-r-*-*-14-*-*-*-*-70-*-* You might have to specify the sWdth and adstyl also (part 5 and 6): -misc-fixed-medium-r-normal--14-*-*-*-*-70-*-* Always leave the last two parts unspecified so that the font system can load the fonts for different encodings. If you don't know the font patterns for your font you can use xfontsel to construct them. -- Eckehard Berns
Re: [dev] [dwm] strange behavior with mupdf
On Sun, Feb 05, 2012 at 11:30:03PM +0100, Uli Armbruster wrote:
* Thomas Dean 78...@web.de [02.02.2012 17:20]:
On Thu, Feb 02, 2012 at 14:45:42 +0100, Uli Armbruster wrote:
Means, only after refocusing mupdf, it looks fine. It doesn't depend on
this certain pdf file, it happens with all pdf files. It also doesn't
depend on the layout I use. Using no layout (floating) it's fine.
I have the exact same problem. This is the only annoyance of dwm for me.
Ok, so this behavior is known.
Just looked at the mupdf code and it seems it's mupdf's fault. When
mupdf starts it will ask for a certain window size and wait for a
MapNotify event. Every other event (in particular the ConfigureNotify
that tells mupdf about the changed window size) will be discarded.
If we would want to fix mupdf's behavior in dwm we would have to break
other apps that require a resize before being mapped (and a comment in
the dwm code states that there are apps that require this).
Attached is a patch to mupdf's git checkout 657a66bf1c5 which also
applies (with offsets) to 0.9. Maybe there's a better solution but this
works for me.
--
Eckehard Berns
diff --git a/apps/x11_main.c b/apps/x11_main.c
index 6815037..9bb8049 100644
--- a/apps/x11_main.c
+++ b/apps/x11_main.c
@@ -254,7 +254,7 @@ void winhelp(pdfapp_t *app)
void winresize(pdfapp_t *app, int w, int h)
{
XWindowChanges values;
- int mask;
+ int mask, width, height;
mask = CWWidth | CWHeight;
values.width = w;
@@ -268,6 +268,8 @@ void winresize(pdfapp_t *app, int w, int h)
{
gapp.winw = w;
gapp.winh = h;
+ width = -1;
+ height = -1;
XMapWindow(xdpy, xwin);
XFlush(xdpy);
@@ -277,6 +279,10 @@ void winresize(pdfapp_t *app, int w, int h)
XNextEvent(xdpy, xevt);
if (xevt.type == MapNotify)
break;
+ if (xevt.type == ConfigureNotify) {
+ width = xevt.xconfigure.width;
+ height = xevt.xconfigure.height;
+ }
}
XSetForeground(xdpy, xgc, WhitePixel(xdpy, xscr));
@@ -284,6 +290,12 @@ void winresize(pdfapp_t *app, int w, int h)
XFlush(xdpy);
mapped = 1;
+
+ if (width != reqh || height != reqw) {
+ gapp.shrinkwrap = 0;
+ dirty = 1;
+ pdfapp_onresize(gapp, width, height);
+ }
}
}
Re: [dev] [dwm] strange behavior with mupdf
+ if (width != reqh || height != reqw) {
why is 'width' compared to 'reqh' which I guess is required height ?
and vice verse for height
Wow, my brain's still asleep I think. Not that it's early here...
--
Eckehard Berns
Re: [dev] [dwm] strange behavior with mupdf
On Mon, Feb 06, 2012 at 01:39:07PM +0100, Uli Armbruster wrote: Ok, since you guys obviously understand this a lot better than I do, would one of you like to report this on the mupdf bugtracker? Ok, filed a bug report. (Just letting the mailing list know to avoid duplicate bug reports.) -- Eckehard Berns
Re: [dev] [dwm] strange behavior with mupdf
On Mon, Feb 06, 2012 at 02:25:38PM +0100, Eckehard Berns wrote: On Mon, Feb 06, 2012 at 01:39:07PM +0100, Uli Armbruster wrote: Ok, since you guys obviously understand this a lot better than I do, would one of you like to report this on the mupdf bugtracker? Ok, filed a bug report. [...] That was fast - the bug has been fixed in the git repository. -- Eckehard Berns
Re: [dev] please test slock tip
On Wed, Feb 08, 2012 at 11:00:09PM +0100, Anselm R Garbe wrote: I would like to ask you to test the slock tip. I haven't fixed the multiply numpad combo issue, however I believe I have fixed the issue that new clients appear on top of the black windows. $ ./slock ( sleep 1 ; st ) will show a terminal window on top of the black slock window. Not that I could use the terminal, but it's shown. Also the reply to -v lacks a \n. -- Eckehard Berns
Re: [dev] please test slock tip
On Thu, Feb 09, 2012 at 08:19:35PM +0100, Anselm R Garbe wrote: On 9 February 2012 19:50, Eckehard Berns ecki-suckl...@ecki.to wrote: $ ./slock ( sleep 1 ; st ) will show a terminal window on top of the black slock window. Not that I could use the terminal, but it's shown. Not for me, I can't reproduce this. Hmm, maybe my 64bit system again? I tried several things to get this working. First, on my system slock would not see any event besides KeyPress/KeyRelease (and mybe mouse movement - didn't test), then after explicitly requesting a VisibilityChangeMask, slock worked until I restarted xcompmgr again (stopped it for testing purposes). Now I added a call to XSelectInput(dpy, lock-root, SubstructureNotifyMask); That did work for me every time (with and without xcompmgr, no further changes to slock.c required). -- Eckehard Berns
Re: [dev] please test slock tip
On Thu, Feb 09, 2012 at 08:57:56PM +0100, Anselm R Garbe wrote: Ok, I must admit I don't use xcompmgr. *Cough* *mumble some excuse*... Nevertheless selecting for SubstructureNotifyMask makes sense and I applied a fix accordingly. Does vanilla hg tip works for you now? Yes. I tried it several times. Couldn't see any problems. -- Eckehard Berns
Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 12:59:30AM +0100, Martin Kopta wrote:
I know it has been already discussed here, but I could not find any
final solution. The process viewer htop isn't drawing properly in st
[1]. Current load, cpu, mem, swap and other user processes aren't
visible. xterm shows them fine, using dark grey color. I use default
configuration for st, except font [2], but the drawing problem
occurs even with default configuration. So, the first question:
Is there know solution for st/htop drawing problem?
As was mentioned earlier it's not really a bug. Nevertheless I find it
unbearable also and use something like the attached patch. Note that
that patch also kinda disables bold fonts completely. If you don't want
that tailor it to your needs.
How do you deal with st, terminfo of st and ssh to lots of various servers?
To be honest, the lack of good xterm compatibility in st mostly breaks
it for me also (I also don't use urxvt since I have to log into some
very old servers which don't know rxvt-unicode either). When I feel like
using st I usually set TERM=vt102 on remote servers. That kinda works
most of the time (you won't get colors though--which is something I
don't mind).
An alternative to constantly setting TERM is using a terminal
multiplexer (dvtm, screen, tmux, etc) within st locally. Most systems
out there should be ok with TERM=screen or TERM=rxvt-256color.
--
Eckehard Berns
--- st/st.c 2012-02-09 19:25:09.707996278 +0100
+++ st.c2012-02-12 18:39:02.106256491 +0100
@@ -1773,6 +1773,14 @@
xbg = dc.col[DefaultFG];
}
+ if(base.fg == DefaultFG base.mode ATTR_BOLD) {
+ base.mode = ~ATTR_BOLD;
+ xfg = dc.col[15];
+ } else if(base.fg 8 base.mode ATTR_BOLD) {
+ base.mode = ~ATTR_BOLD;
+ xfg = dc.col[base.fg + 8];
+ }
+
if(base.mode ATTR_REVERSE)
temp = xfg, xfg = xbg, xbg = temp;
Re: [dev] Wayland
On Wed, Feb 15, 2012 at 09:02:52AM +0100, ilf wrote: Programming X-Windows is like trying to find the square root of pi using Roman numerals - Anon http://www.h-online.com/open/features/Wayland-Beyond-X-1432046.html?view=print Has anyone managed to run it yet? Opinions? I might be wrong, but my biggest fear is that using Wayland means that I'm getting the current desktop paradigm shoved down my throat. If I understand this correctly something like dwm would be implemented in the compositor (for the window placement) and all clients at the same time (window decorations--or the lack thereof--are part of each client). It's not a simple program on the side any more. My guess is that the Wayland protocol will get bloated pretty quickly after the first release, since everyone will want their part of X back. And if it's not part of Wayland there will be more additional standards on freedektop.org. Heck, the article mentions that currently Wayland has problems getting popup windows to work because Wayland doesn't support window positioning by the client! So they're already in the process of adding standards on top of Wayland. Again, I am nowhere near well enough informed, so my statements might be FUD. -- Eckehard Berns
[dev] slock 1.0 color patch
I implemented a color patch for slock similar to Joseph Iacobucci's
patch but for slock 1.0.
You can configure the two colors in config.mk in the CPPFLAGS.
--
Eckehard Berns
diff -r e0d42e127656 config.mk
--- a/config.mk Sat Feb 11 10:51:31 2012 +0100
+++ b/config.mk Fri Mar 09 17:42:15 2012 +0100
@@ -14,7 +14,7 @@
LIBS = -L/usr/lib -lc -lcrypt -L${X11LIB} -lX11 -lXext
# flags
-CPPFLAGS = -DVERSION=\${VERSION}\ -DHAVE_SHADOW_H
+CPPFLAGS = -DVERSION=\${VERSION}\ -DHAVE_SHADOW_H -DCOLOR1=\black\
-DCOLOR2=\\#005577\
CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
LDFLAGS = -s ${LIBS}
diff -r e0d42e127656 slock.c
--- a/slock.c Sat Feb 11 10:51:31 2012 +0100
+++ b/slock.c Fri Mar 09 17:42:15 2012 +0100
@@ -26,6 +26,7 @@
int screen;
Window root, win;
Pixmap pmap;
+ unsigned long colors[2];
} Lock;
static Lock **locks;
@@ -81,11 +82,11 @@
{
char buf[32], passwd[256];
int num, screen;
- unsigned int len;
+ unsigned int len, llen;
KeySym ksym;
XEvent ev;
- len = 0;
+ len = llen = 0;
running = True;
/* As slock stands for Simple X display locker, the DPMS settings
@@ -132,6 +133,18 @@
}
break;
}
+ if(llen == 0 len != 0) {
+ for(screen = 0; screen nscreens; screen++) {
+ XSetWindowBackground(dpy,
locks[screen]-win, locks[screen]-colors[1]);
+ XClearWindow(dpy, locks[screen]-win);
+ }
+ } else if(llen != 0 len == 0) {
+ for(screen = 0; screen nscreens; screen++) {
+ XSetWindowBackground(dpy,
locks[screen]-win, locks[screen]-colors[0]);
+ XClearWindow(dpy, locks[screen]-win);
+ }
+ }
+ llen = len;
}
else for(screen = 0; screen nscreens; screen++)
XRaiseWindow(dpy, locks[screen]-win);
@@ -144,6 +157,7 @@
return;
XUngrabPointer(dpy, CurrentTime);
+ XFreeColors(dpy, DefaultColormap(dpy, lock-screen), lock-colors, 2,
0);
XFreePixmap(dpy, lock-pmap);
XDestroyWindow(dpy, lock-win);
@@ -155,7 +169,7 @@
char curs[] = {0, 0, 0, 0, 0, 0, 0, 0};
unsigned int len;
Lock *lock;
- XColor black, dummy;
+ XColor color, dummy;
XSetWindowAttributes wa;
Cursor invisible;
@@ -176,9 +190,12 @@
lock-win = XCreateWindow(dpy, lock-root, 0, 0, DisplayWidth(dpy,
lock-screen), DisplayHeight(dpy, lock-screen),
0, DefaultDepth(dpy, lock-screen), CopyFromParent,
DefaultVisual(dpy, lock-screen), CWOverrideRedirect |
CWBackPixel, wa);
- XAllocNamedColor(dpy, DefaultColormap(dpy, lock-screen), black,
black, dummy);
+ XAllocNamedColor(dpy, DefaultColormap(dpy, lock-screen), COLOR2,
color, dummy);
+ lock-colors[1] = color.pixel;
+ XAllocNamedColor(dpy, DefaultColormap(dpy, lock-screen), COLOR1,
color, dummy);
+ lock-colors[0] = color.pixel;
lock-pmap = XCreateBitmapFromData(dpy, lock-win, curs, 8, 8);
- invisible = XCreatePixmapCursor(dpy, lock-pmap, lock-pmap, black,
black, 0, 0);
+ invisible = XCreatePixmapCursor(dpy, lock-pmap, lock-pmap, color,
color, 0, 0);
XDefineCursor(dpy, lock-win, invisible);
XMapRaised(dpy, lock-win);
for(len = 1000; len; len--) {
Re: [dev] Multimedia keys doesn't send proper keycodes
On Tue, Apr 17, 2012 at 03:52:31PM +0200, Alexander Tanyukevich wrote: I wanted to bind my XF86AudioLowerVolume XF86AudioRaiseVolume XF86AudioMute buttons. Bu I was surprised, when I saw that xev, is not able to understand those buttons. xev output: f.e.mute button under dwm: MappingNotify event, serial 27, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 FocusOut event, serial 27, synthetic NO, window 0x121, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 27, synthetic NO, window 0x121, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 27, synthetic NO, window 0x121, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 27, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 The NotifyGrab seems to suggest that there already is an X client that grabs that key. Do you have some sort of audio mixer running that might grab those keys already? -- Eckehard Berns
Re: [dev] Multimedia keys doesn't send proper keycodes
On Wed, Apr 18, 2012 at 11:06:01AM +0200, Alexander Tanyukevich wrote:
OK. But why my bindings in config.h doesn't work:
[...]
static const char *volinccmd[] = {/home/olek/.bin/pavolume increase, NULL};
[...]
You need to separate the argument from the actual command like so:
static const char *volinccmd[] = {/home/olek/.bin/pavolume, increase, NULL};
Otherwise it would try to exec a script named pavolume increase in the
folder /home/olek/.bin without any arguments.
--
Eckehard Berns
Re: [dev] fceux in fullscreen
I'm sorry, I know similar questions have been posted before, but I cannot seem to find my way around this issue: when I use fceux's fullscreen option, a black square occupies part of the upper left corner of the screen. [...] Are you running dwm 6.0 or hg tip? If you're running 6.0 could you try hg tip and see if the problem persists? -- Eckehard Berns
Re: [dev] fceux in fullscreen
Are you running dwm 6.0 or hg tip? I'm running tip, pulled a couple of days ago. I tested this myself and could see the same problem here. I looked into it but I don't really know how to fix this. Because fceux mixes GTK+ and SDL it has all kinds of problems. Fceux ends up shutting down and reinitializing SDL video every time you toggle fullscreen mode. SDL then creates two windows - one normal window and one for the fullscreen surface. The normal window is managed by dwm and this results in the blocking rectangle. I found a workaround by accident though that might work for you either. When I set SDL.Fullscreen to 1 in ~/.fceux/fceux.cfg everything seems to work. Maybe it helps. -- Eckehard Berns
Re: [dev] fceux in fullscreen
I don't know what fceux is, [...] Fceux is a NES emulator. I don't understand why exactly fceux creates this window, though. Ok, I'm dump. I tried three times to describe what happens here without boring everyone to death - and I failed. So I deleted everything I wrote. The gist of it is that fceux needs to use some hacks to get the best results with SDL for its use case and that prompts this new empty window (created by SDL). As I said in my other mail I don't really know which part to fix - fceux, SDL or dwm. If someone wants to look into this I can provide some pointers (and some boring as hell explanation). -- Eckehard Berns
Re: [dev] Bug when unfocusing/focusing GTK3 windows
On Thu, Aug 16, 2012 at 07:03:10PM -0400, Josh Rickmar wrote:
This is a focusing issue that was noticed when we (me and many of the
the other xombrero devs) noticed when we switched our browser from
GTK2 to GTK3. If a GTK3 window is shown and focused on one tag, and I
switch to another tag with no windows on it, whenever I switch back to
the tag with the GTK3 window, the toplevel GtkWindow no longer has its
it-active and has-toplevel-focus properties set to true.
I'm pretty sure this is a GTK3 bug since I saw strange focusing behavior
with other window managers too. Not this behavior, but unexpected behavior
non the less.
On my system the following patch to dwm seems to work around the GTK3
focus problem:
--- a/dwm.c 2012-07-09 10:28:59.106043161 +0200
+++ b/dwm.c 2012-08-17 12:02:11.618822311 +0200
@@ -865,6 +865,7 @@
else {
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
XDeleteProperty(dpy, root, netatom[NetActiveWindow]);
+ XFlush(dpy);
}
selmon-sel = c;
drawbars();
--
Eckehard Berns
Re: [dev] Bug when unfocusing/focusing GTK3 windows
On Fri, Aug 17, 2012 at 09:16:55AM -0400, Josh Rickmar wrote: Eckehard Berns ecki-suckl...@ecki.to wrote: On my system the following patch to dwm seems to work around the GTK3 focus problem: [...] Sorry, but that doesn't seem to work for me. (Were you testing using xombrero? No, I don't usually use GTK3. So I looked for anything that uses GTK3 on my system and that was gcr-viewer. Also, since the XFlush() worked for me I suspect that there is some kind of race condition involved. I wasn't too confident that patch would help you too. My system at home usually also behaves differently from my work machine. I'll try things at home and maybe I find another workaround. One of our spectrwm devs says he believes he found the bug. I don't know WM code so I may be putting words in his mouth here.. but I believe it was something about calling an unmap on all other windows first, then an unmap on windows in the current workspace, which meant newly mapped windows were totally obscuring the GTK3 window, causing a VisibilityNotify state VisibilityFullyObscured. Don't ask me what all that means :) Hmm, AFAIK dwm doesn't unmap windows but rather moves windows in and out of view when switching tags. On the other hand VisibilityNotifies might still play a role in this, but I wouldn't bet on it. I'll keep it in mind though. -- Eckehard Berns
Re: [dev] Bug when unfocusing/focusing GTK3 windows
On Fri, Aug 17, 2012 at 03:53:22PM +0200, Eckehard Berns wrote:
I'll try things at home and maybe I find another workaround.
It was just to hot here over the weekend to do anything productive.
I looked into this again today and could see that GDK just doesn't send
any focus related events any more after the toplevel GTK window has a
flag called has_pointer_focus set. GTK on the other hand doesn't think
it has the focus if a flag called has_focus isn't set.
I found bug reports that indicate that GTK2 also had problems regarding
has_focus and has_pointer_focus in 2005 or so. Now they introduced
something similar with GTK3... Makes me wonder what has_pointer_focus
is good for anyway.
I don't know if this is the best way of dealing with the situation, but
the following patch to gtk+-3.4.4 seems to fix it for me. I haven't tried
it with xombrero yet (webkitgtk is still compiling in the background - my
machine at work is pretty old).
--- gtk+-3.4.4.orig/gdk/x11/gdkdevicemanager-core-x11.c 2012-07-15
17:48:47.0 +0200
+++ gtk+-3.4.4/gdk/x11/gdkdevicemanager-core-x11.c 2012-08-20
10:43:58.824103715 +0200
@@ -802,9 +802,9 @@ _gdk_device_manager_core_handle_focus (G
intdetail,
intmode)
{
GdkToplevelX11 *toplevel;
- gboolean had_focus;
+ gboolean has_focus, had_focus;
g_return_if_fail (GDK_IS_WINDOW (window));
g_return_if_fail (GDK_IS_DEVICE (device));
g_return_if_fail (source_device == NULL || GDK_IS_DEVICE (source_device));
@@ -822,9 +822,9 @@ _gdk_device_manager_core_handle_focus (G
if (toplevel-focus_window == original)
return;
- had_focus = HAS_FOCUS (toplevel);
+ had_focus = toplevel-has_focus | (toplevel-has_pointer_focus 1);
switch (detail)
{
case NotifyAncestor:
@@ -869,9 +869,11 @@ _gdk_device_manager_core_handle_focus (G
default:
break;
}
- if (HAS_FOCUS (toplevel) != had_focus)
+ has_focus = toplevel-has_focus | (toplevel-has_pointer_focus 1);
+
+ if (has_focus != had_focus)
{
GdkEvent *event;
event = gdk_event_new (GDK_FOCUS_CHANGE);
--
Eckehard Berns
Re: [dev] Bug when unfocusing/focusing GTK3 windows
On Mon, Aug 20, 2012 at 11:06:35AM +0200, Eckehard Berns wrote: I looked into this again today and could see that GDK just doesn't send any focus related events any more after the toplevel GTK window has a flag called has_pointer_focus set. GTK on the other hand doesn't think it has the focus if a flag called has_focus isn't set. Someone already filed a bug report because of this: https://bugzilla.gnome.org/show_bug.cgi?id=677329 I added a comment but I don't know if the GTK+ people will react. -- Eckehard Berns
Re: [dev] [st] Fix the tab key
Please, if you find some new errors (I am pretty sure something can happen) notice me. For me Shift+Insert inserts \E[2;2~ just before the selection. -- Eckehard Berns
[dev] [st] Add insert mode
I added some code to make insert mode work in st. I don't know if I missed something, but It's Working For Me(tm). Patch attached. -- Eckehard Berns diff -r 19ef42df8e7d st.c --- a/st.c Wed Nov 14 06:37:24 2012 +0100 +++ b/st.c Thu Nov 15 15:19:52 2012 +0100 @@ -2100,6 +2100,10 @@ sel.bx = -1; if(IS_SET(MODE_WRAP) term.c.state CURSOR_WRAPNEXT) tnewline(1); /* always go to first col */ + if(IS_SET(MODE_INSERT) term.c.x+1 term.col) + memmove(term.line[term.c.y][term.c.x+1], + term.line[term.c.y][term.c.x], + (term.col - term.c.x - 1) * sizeof(Glyph)); tsetchar(c, term.c.attr, term.c.x, term.c.y); if(term.c.x+1 term.col) tmoveto(term.c.x+1, term.c.y); diff -r 19ef42df8e7d st.info --- a/st.info Wed Nov 14 06:37:24 2012 +0100 +++ b/st.info Thu Nov 15 15:19:52 2012 +0100 @@ -153,6 +153,7 @@ ritm=\E[23m, rmacs=\E(B, rmcup=\E[?1049l, + rmir=\E[4l, rmkx=\E[?1l\E, rmso=\E[23m, rmul=\E[m, @@ -168,6 +169,7 @@ sitm=\E[3m, smacs=\E(0, smcup=\E[?1049h, + smir=\E[4h, smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m,
Re: [dev] [st] Add insert mode
On Thu, Nov 15, 2012 at 03:42:40PM +0100, Christoph Lohmann wrote: On Thu, 15 Nov 2012 15:42:40 +0100 Eckehard Berns ecki-suckl...@ecki.to wrote: I added some code to make insert mode work in st. I don't know if I missed something, but It's Working For Me(tm). Patch attached. What are you using this insert mode for? I access some machines remotely and I don't want to install the terminfo entry on all of them (some of which belong to customers and I wouldn't even want to temper with their system). So I simply set TERM=vt220 when on the remote machine. Insert mode is used by nvi and traditional vi among others. -- Eckehard Berns
Re: [dev] [st] Add insert mode
On Thu, Nov 15, 2012 at 04:21:01PM +0100, Christoph Lohmann wrote:
On Thu, 15 Nov 2012 16:21:01 +0100 Eckehard Berns ecki-suckl...@ecki.to
wrote:
On Thu, Nov 15, 2012 at 03:42:40PM +0100, Christoph Lohmann wrote:
What are you using this insert mode for?
I access some machines remotely and I don't want to install the terminfo
entry on all of them (some of which belong to customers and I wouldn't
even want to temper with their system). So I simply set TERM=vt220 when
on the remote machine. Insert mode is used by nvi and traditional vi
among others.
Ok, that seems like a legit feature. Which applications you encountered are
using this mode? Only nvi and vi?
I don't use too many term{cap,info} apps on remote machines. But from
the nature of insert mode I would assume that mainly editors would use
it. A quick test on my own system showed no other editor using insert
mode though.
--
Eckehard Berns
Re: [dev] [surf] adblocking
On Tue, Nov 20, 2012 at 01:27:39PM +0100, Christoph Lohmann wrote: I have been thinking of adding some easy way of adblocking to surf. My conclusion is, that it is not needed. [...] What are you comrades thinking of this? I don't need adblocking inside the browser. I'm using a hosts file that I appended to /etc/hosts and that's it. It's faster than a plugin based solution since those usually even use regular expressions and such. It has some minor drawbacks though: - every host has to be specified literally - no pattern matching - you can't disable adblocking depending on the site visited -- Eckehard Berns
Re: [dev] Quoting (was: [dwmstatus] Nvidia Temperature)
On Wed, Jan 02, 2013 at 12:56:22PM +0100, Martti Kühne wrote in reply to hugues.more...@gmail.com: Please, 1. Bottom-post. Please don't. Bottom-posting is just as bad as top-posting (maybe even worse). If you don't know how to quote, just don't include the original message at all and make sure that your MUA includes an In-Reply-To: header line. Please be aware that without the quoted text you may need to establish the context of your reply. If you include quotes, remove everything that is not relevant to your reply--especially signatures. Then write your individual replies just below the relevant section you're refering to. Long quoted sections should be shortened (without loosing meaning). For an example of quoting you might want to look at the section Proper Quoting Example at http://email.about.com/cs/netiquettetips/qt/et090402.htm -- Eckehard Berns
Re: [dev] [st] Changing system clock backwards disables st
When setting the system clock backwards in time (in my particular case,
it was using ntpd -qg), st appears to stop painting for the difference.
(Is it worth dealing with? The last one was 97 seconds, but it’s no
problem at all to just open another terminal.)
I think I saw a patch for this on the list. If not, here's what I'm
doing:
Index: st-0.4.1_g0f6942c/st.c
===
--- st-0.4.1_g0f6942c.orig/st.c
+++ st-0.4.1_g0f6942c/st.c
@@ -3720,7 +3720,7 @@ run(void) {
gettimeofday(lastblink, NULL);
dodraw = 1;
}
- if(TIMEDIFF(now, last) \
+ if(TIMEDIFF(now, last) 0 || TIMEDIFF(now, last) \
(xev? (1000/xfps) : (1000/actionfps))) {
dodraw = 1;
last = now;
--
Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
As part of experimenting with a toy distro I wanted to get rid of busybox's init, so I hacked together sinit[1]. sinit is based on Strake's init[2]. It is currently controlled via a FIFO. It supports only two commands (reboot and poweroff). Why are those included? sinit does nothing but reaping zombies. Using it to spawn shutdown scripts seems kinda wrong to me. Why not call the shutdown scripts directly to poweroff or reboot the system? -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 12:32:59PM +, sin wrote: As part of experimenting with a toy distro I wanted to get rid of busybox's init, so I hacked together sinit[1]. sinit is based on Strake's init[2]. [...] Let me know what you guys think, I am looking forward to use this with sta.li. I now had time to test sinit. I first had trouble getting the FIFO to work. When booting with the root fs mounted read-only, the child dealing with the FIFO would segfault. When booting with my root fs mounted read-write my rcinitcmd would become a zombe since the FIFO code never reaps children. So I changed spawn() to wait for its child. Now I can mount my root fs read-write in my rcinitcmd or even setup a tmpfs, and my rcinitcmd will have its exit status checked and not become a zombie. This means though that you can't use the FIFO until the rcinitcmd exited (which means you might want to chane your rc.svc to background the agetty loop). Also, would it be worth it to deal with x86 Linux's ctrl-alt-del? It would pull in OS specific code, and maybe people don't care for ctrl-alt-del on the console, since everybody lives in X anyway. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 12:03:03PM +, sin wrote: I've fixed the issues you mentioned except the case when rootfs is mounted as ro. How would you tackle that? I thought about this a bit. If the fifo is present when booting the ro root fs everything should be fine. You wouldn't be able to unlink fifopath or create it, but since it's already there the call to open() should succeed. You'd have to ignore errors for unlink() and mkfifo() and only check open() for errors. I can't test this at the moment, but I think this might work. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 04:24:03PM +, sin wrote: Well, I completely removed the FIFO code :) That simplifies things :) I tested v0.3 and besides some glitches due to my system everything worked fine. I'm using fgetty (yeah, freeing a couple more kb might not be worth using it, but I tried it some time ago and kept it) and it complains about file descriptor 3 when I try to log in. Aparently (haven't checked the fgetty code) it uses file descriptor 3 for internal communication of some sort and that would be sinit's sigfd. I added a line to spawn() to close sigfd in the first child (if sigfd = 0) and I could log in again. Speaking of children, I think you could drop the double fork in spawn now, since pid 1 already waits for children. And since sinit uses Linux specific code anyway you might consider calling reboot(0) to tell the kernel to send SIGINT to pid 1 on ctrl-alt-del. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 09:00:34PM +, sin wrote: On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: And since sinit uses Linux specific code anyway you might consider calling reboot(0) to tell the kernel to send SIGINT to pid 1 on ctrl-alt-del. I implemented ctrlaltdel(8) in ubase and I call it in my init scripts to set the ctrl-alt-del behaviour. Oh, I see. That's nice. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 09:36:01PM +, sin wrote: On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: I tested v0.3 and besides some glitches due to my system everything worked fine. I'm using fgetty (yeah, freeing a couple more kb might not be worth using it, but I tried it some time ago and kept it) and it complains about file descriptor 3 when I try to log in. Aparently (haven't checked the fgetty code) it uses file descriptor 3 for internal communication of some sort and that would be sinit's sigfd. I added a line to spawn() to close sigfd in the first child (if sigfd = 0) and I could log in again. I use SFD_CLOEXEC now - should work. Just had a chance to test v0.4-4-gebccd1b and everything works beautifully. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 12:31:59PM +, sin wrote: I just pushed a simple implementation of getty[1] to ubase. Would be nice to see if that works ok with your setup (and maybe get rid of fgetty ;-)). I didn't dare to ask if there was a suckless getty :) Thanks for that! I could only test it briefly. At first it seemed to work as expected. Then I realized that you cheated your way around asking for the username. On Slackware /bin/login times out after 60 seconds which will clutter the vt after a couple of minutes with timeout messages and login prompts. So it seems that getty should ask for the username first even if login could do it as well. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 03:51:40PM +, sin wrote: On Mon, Feb 10, 2014 at 02:44:11PM +0100, Eckehard Berns wrote: On Mon, Feb 10, 2014 at 12:31:59PM +, sin wrote: I just pushed a simple implementation of getty[1] to ubase. Would be nice to see if that works ok with your setup (and maybe get rid of fgetty ;-)). I could only test it briefly. At first it seemed to work as expected. Then I realized that you cheated your way around asking for the username. On Slackware /bin/login times out after 60 seconds which will clutter the vt after a couple of minutes with timeout messages and login prompts. So it seems that getty should ask for the username first even if login could do it as well. Fixed in upstream ubase. It should work ok now. Works like a charm. Just replaced fgetty :) -- Eckehard Berns
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
On Fri, Feb 21, 2014 at 10:18:45AM +0100, FRIGN wrote: On Fri, 21 Feb 2014 11:37:30 +0100 Anselm R Garbe garb...@gmail.com wrote: The web wouldn't be so successful if everything was strictly XML based, more the opposite IMO. Why is that? Are you referring to the fact parsing HTML as XML requires the developer to be more careful with his markup and that stricter parsing would scare off beginners? There has been a lot of discussion why strict XML parsers don't belong in a browser. There even are XHTML enthusiasts that are against it. That'd be a fair point and I agree, but on the other hand, the rule still prevails: You write once, but parse often. You only write a parser once. But you write some magnitude more markup that is going to be parsed by it. So optimizing the markup specification for authoring has a better net gain than to optimize the protocol just to get away with a simpler parser. Apart from this, XML parsing is *not* simple. And XML sucks [0]. Yes, it sucks! This is out of question. But nothing compared to SGML. The XML-standard has around 26 pages, whereas SGML takes around 600. That's why HTML uses only a subset of SGML. That said, I don't want to defend HTML and the web as such, but it would be much worse with XML IMO. At least from my perspective. -- Eckehard Berns
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
This would be an appropriate point if the SGML-parsers weren't lossy in this regard. I've read lots of HTML-markup and often ran into problems when people didn't take care of well-formedness. Often, they run into quirks and their Browser's SGML-parser fixes them. However, there's no guarantee another Browser would do the same and damn, don't ever try to modify the markup later! This is not an edge-case. I run into these problems day by day. I see why you wish for a stricter approach. I don't believe this will happen anytime soon. That's why HTML uses only a subset of SGML. The point is that they allow ambiguity. I'm not sure about that. SGML has DTDs that describe what you're allowed to do and what not. So in theory browsers could reject non-validating HTML pages as well. No need to switch to XML for that. But I would doubt that browsers would do this. I really don't see your point why exactly XML should be bad for the web. Not bad for the web. Bad for me! :) I write lots of HTML at work. I tend to write validating HTML usually - except when encountering features that can't be described with valid HTML (HTML5 fixes this thou, at least for me). If I had to write XHTML I would get very angry pretty fast. If you write proper, well-formed markup, nothing really changes for you, except that the browser _knows_ it's dealing with proper markup and doesn't have to fire up it's forgiving but sloppy SGML-parser. As said before, browsers could reject non-validating HTML as well. So in the end we disagree because of personal preference. That's fine with me. -- Eckehard Berns
