RE: [dwm] Re: keyboard input focus
What are you talking about? what is client switching for you? Which keys are you using? If youre talking about the default zoom and alt,tab keys. In dwm theres no random functionailty,but you can make a patch if you want :P. Check your conf and feed us with more concise information. But i think youre missing something - original message - Subject:[dwm] Re: keyboard input focus From: bill lam [EMAIL PROTECTED] Date: 2008/09/09 05:26 On Tue, 09 Sep 2008, bill lam wrote: I found that mouse click can switch current client (as shown in the top statusbar), but the keyboard input focus does not get switched. Is this bug? To be concise, the behaviour is random, sometimes it works. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: [dwm] malloc'ed client in manage()
On (09/09/08 09:13), Szabolcs Nagy wrote:
To: dwm mail list dwm@suckless.org
From: Szabolcs Nagy [EMAIL PROTECTED]
Subject: Re: [dwm] malloc'ed client in manage()
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
On 9/8/08, Anselm R Garbe [EMAIL PROTECTED] wrote:
but if we really care about obscure 30 year old cpus (other than x86
:)) then i'd go with my solution: c = malloc(); and *c = (Client){};
Well, I agree on this proposal and go for it. It is fairly simple and
nice looking imho.
sorry i misread the standard
eventhough it sais
If there are fewer initializers in a brace-enclosed list than there
are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration.
the initializer list must contain at least one element so the empty {}
is not enough. (easy to overlook since it is not stated explicitly,
just the result of the given initializer grammar)
Client can be initialized with {} (first member is .name) or {.x =
0} or whatever, but general zero-init is impossible this way :(
tl;dr: use the original patch
This can be easilly done with patch:
diff -r e4bcaca8e6ef dwm.c
--- a/dwm.c Mon Sep 08 22:24:05 2008 +0100
+++ b/dwm.c Tue Sep 09 10:12:01 2008 +0200
@@ -846,22 +846,21 @@
void
manage(Window w, XWindowAttributes *wa) {
- static Client cz;
Client *c, *t = NULL;
Window trans = None;
XWindowChanges wc;
if(!(c = malloc(sizeof(Client
die(fatal: could not malloc() %u bytes\n, sizeof(Client));
- *c = cz;
- c-win = w;
+ *c = (const Client){
+ .win = w,
+ .x = wa-x,
+ .y = wa-y,
+ .w = wa-width,
+ .h = wa-height,
+ .oldbw = wa-border_width,
+ };
- /* geometry */
- c-x = wa-x;
- c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
- c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
c-y = sy;
But, I dislike this whole !calloc solution. BTW: there are plenty of places
which expects that NULL == 0 - false ...
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] malloc'ed client in manage()
2008/9/9 Premysl Hruby [EMAIL PROTECTED]:
On (09/09/08 09:13), Szabolcs Nagy wrote:
To: dwm mail list dwm@suckless.org
From: Szabolcs Nagy [EMAIL PROTECTED]
Subject: Re: [dwm] malloc'ed client in manage()
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
On 9/8/08, Anselm R Garbe [EMAIL PROTECTED] wrote:
but if we really care about obscure 30 year old cpus (other than x86
:)) then i'd go with my solution: c = malloc(); and *c = (Client){};
Well, I agree on this proposal and go for it. It is fairly simple and
nice looking imho.
sorry i misread the standard
eventhough it sais
If there are fewer initializers in a brace-enclosed list than there
are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration.
the initializer list must contain at least one element so the empty {}
is not enough. (easy to overlook since it is not stated explicitly,
just the result of the given initializer grammar)
Client can be initialized with {} (first member is .name) or {.x =
0} or whatever, but general zero-init is impossible this way :(
tl;dr: use the original patch
This can be easilly done with patch:
diff -r e4bcaca8e6ef dwm.c
--- a/dwm.c Mon Sep 08 22:24:05 2008 +0100
+++ b/dwm.c Tue Sep 09 10:12:01 2008 +0200
@@ -846,22 +846,21 @@
void
manage(Window w, XWindowAttributes *wa) {
- static Client cz;
Client *c, *t = NULL;
Window trans = None;
XWindowChanges wc;
if(!(c = malloc(sizeof(Client
die(fatal: could not malloc() %u bytes\n, sizeof(Client));
- *c = cz;
- c-win = w;
+ *c = (const Client){
+ .win = w,
+ .x = wa-x,
+ .y = wa-y,
+ .w = wa-width,
+ .h = wa-height,
+ .oldbw = wa-border_width,
+ };
- /* geometry */
- c-x = wa-x;
- c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
- c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
c-y = sy;
But, I dislike this whole !calloc solution. BTW: there are plenty of places
which expects that NULL == 0 - false ...
Well, the original patch is kind of common, whereas this approach
looks somehow odd to me, I go with the static initializer for now.
Kind regards,
--Anselm
Re: [dwm] Re: keyboard input focus
2008/9/9 bill lam [EMAIL PROTECTED]: Mouse click on a window should bring the window to the front (z-order) and the keyboard focus (the caret) should also transfer to a child of that window. But this is not always happens, to make it worse the problem does not show up when I try to reproduce it. Which terminal are you using? I remember that I noticed such behavior back in the times when I used urxvt, however I switched to uxterm long ago which seems to work properly. And since st will be the official terminal for dwm in the future, I hope that it won't show such behavior as well... Kind regards, --Anselm
Re: [dwm] Re: keyboard input focus
On Tue, 09 Sep 2008, Anselm R Garbe wrote: Which terminal are you using? I remember that I noticed such behavior back in the times when I used urxvt, however I switched to uxterm long ago which seems to work properly. And since st will be the official terminal for dwm in the future, I hope that it won't show such behavior as well... I use xterm on ubuntu, which is already unicode enabled. It is annoying but I can live with it. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
[dwm] dwm + xft
Hello there. It's my first mail on this ML. I wonder if there is any possibility to use xft fonts in dwm. Becouse this patch http://koluthcka.ru/fwm/dwm-4.7-xft.diff doesn't work for me.
Re: [dwm] dwm + xft
2008/9/9 [EMAIL PROTECTED]: Hello there. It's my first mail on this ML. I wonder if there is any possibility to use xft fonts in dwm. Becouse this patch http://koluthcka.ru/fwm/dwm-4.7-xft.diff doesn't work for me. I guess this patch just needs to be upgraded to apply with vanilla dwm-5.2. Otherwise I think it should work fine. Kind regards, --Anselm
[dwm] slowness in moving windows OR vlc/mplayer crash
Hi all, I have an ATI FireGL and I use the fglrx binary driver, in ubuntu 8.04. That said: With these two arguments in the Section Device of xorg.conf: Option Textured2D On Option TexturedXrender On ... dwm drags windows around very slowly. But if those parameters are not there, then VLC and mplayer crash when opening any movie. Did anyone run onto the issues above? Albert -- Albert Cardona http://www.mcdb.ucla.edu/Research/Hartenstein/acardona
Re: [dwm] slowness in moving windows OR vlc/mplayer crash
a friend of me had similar crashes with ubuntu 8 and fglrx when the screensaver was popping up. btw he is using gstreamer and have no problems for playing media. On Tue, 2008-09-09 at 14:55 +0200, Albert Cardona wrote: Hi all, I have an ATI FireGL and I use the fglrx binary driver, in ubuntu 8.04. That said: With these two arguments in the Section Device of xorg.conf: Option Textured2D On Option TexturedXrender On ... dwm drags windows around very slowly. But if those parameters are not there, then VLC and mplayer crash when opening any movie. Did anyone run onto the issues above? Albert
Re: [dwm] slowness in moving windows OR vlc/mplayer crash
2008/9/9 Albert Cardona [EMAIL PROTECTED]: I have an ATI FireGL and I use the fglrx binary driver, in ubuntu 8.04. That said: With these two arguments in the Section Device of xorg.conf: Option Textured2D On Option TexturedXrender On ... dwm drags windows around very slowly. But if those parameters are not there, then VLC and mplayer crash when opening any movie. Did anyone run onto the issues above? The window moving/resizing code might be changed after dwm-5.2 which I plan to release tonight. My favorite is just keeping a server grab during the resize/move to prevent clients from redrawing since they won't receive any events during that time. The current code however has been implemented as is on purpose, because I kind of liked the idea to see terminal refreshing themselves during resizals. But I might never actually used this, since I'm normally in tiled mode only... Kind regards, --Anselm
[dwm] newbie question: floating vs tiled layout
What is the significance of tiled vs floating as that shown in the icon on the statusbar for []= ? I'm puzzled because 1. each tag can have different layout yet the icon is common to all tags. 2. take firefox as an example, the window can be dragged or resized (turned in floating) but the layout icon does not change -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: [dwm] newbie question: floating vs tiled layout
2008/9/9 bill lam [EMAIL PROTECTED]: What is the significance of tiled vs floating as that shown in the icon on the statusbar for []= ? I'm puzzled because 1. each tag can have different layout yet the icon is common to all tags. The data model of dwm looks like this: [1...] screens : 1 main screen 1 main screen : 1 view (1 status bar) 1 view : [1...] tags overall, [1...] selected tags 1 view : [1...] layouts 1 view : [1...] clients 1 client : [1...] tags So there is only 1 view in vanilla dwm, which means the current layout algorithm in use is global, regardless what or how many tags are selected. Some patches allow layout per tag however, but this is not vanilla dwm. 2. take firefox as an example, the window can be dragged or resized (turned in floating) but the layout icon does not change The layout symbol is global and it wether applies to all clients or to non-floating/tiled clients. The floating layout applies to all clients for instance, whereas the tiled layout applies to non-floating clients only. If you move/resize any tiled window like firefox or a terminal, it will be made floating implicitely (it can be returned using Mod1-Shift-space to tiled state for example). But this is only toggling the client state between not floating and floating, and might have no real effect if the layout in use doesn't distinguishes between floating and not floating clients like the floating layout. The distinction between floating and non-floating has been introduced because there are plenty clients which aren't usable in a tiled way. That's also why dwm restacks floating clients on top of non-floating clients in layout algorithms which support this distinction (like the default tiled layout). So the layout symbol is only about the layout algorithm currently in use in the view, which is global by default. The client state is symbolized by an existing or missing small square in front of the clients title, clients in floating state have a small squere in front their title, clients in tiled state doesn't. HTH, --Anselm
Re: [dwm] slowness in moving windows OR vlc/mplayer crash
2008/9/9 Anselm R Garbe [EMAIL PROTECTED]: The window moving/resizing code might be changed after dwm-5.2 which I plan to release tonight. My favorite is just keeping a server grab during the resize/move to prevent clients from redrawing since they won't receive any events during that time. The current code however has been implemented as is on purpose, because I kind of liked the idea to see terminal refreshing themselves during resizals. But I might never actually used this, since I'm normally in tiled mode only... Kind regards, --Anselm I really need the redraw to manage gimp windows, sometimes I just have to see what they are doing to know the size I want, I have the same problem with image viewers, openoffice, etc, but if the server grab solution is simpler I won't matter maintaining a patch for that, maybe a patch where you can define in rules if you want incremental resizes for a given window class or something... BTW, I think 5.2 will be a great release (and I haven't had any problems with mplayer so far). Greets, -- - yiyus || JGL .
Re: [dwm] slowness in moving windows OR vlc/mplayer crash
Greetings, I really need the redraw to manage gimp windows, sometimes I just have to see what they are doing to know the size I want, I have the same problem with image viewers, openoffice, etc, but if the server grab solution is simpler I won't matter maintaining a patch for that, maybe a patch where you can define in rules if you want incremental resizes for a given window class or something... BTW, I think 5.2 will be a great release (and I haven't had any problems with mplayer so far). Greets, I know it's bloat, but maybe there could be a toggle setting between the present mechanism and xor-rectangles. Regards, Mate
Re: [dwm] dwm-5.2 / dmenu-3.9
On Tue, Sep 09, 2008 at 08:58:47PM +0100, Anselm R Garbe wrote: I'm glad to announce dwm-5.2 and dmenu-3.9. You can download the new releases from: Always wondered if there anything like changelog for releases? Thanks anyway, great work!
Re: [dwm] dwm-5.2 / dmenu-3.9
2008/9/9 Michael [EMAIL PROTECTED]: On Tue, Sep 09, 2008 at 08:58:47PM +0100, Anselm R Garbe wrote: I'm glad to announce dwm-5.2 and dmenu-3.9. You can download the new releases from: Always wondered if there anything like changelog for releases? Thanks anyway, great work! Changelog is hg log, also available using the web interface: http://code.suckless.org/hg/dwm This is for simplicity reasons. Kind regards, --Anselm
Re: [dwm] dwm-5.2 / dmenu-3.9
On Wed, Sep 10, 2008 at 12:01:09AM +0400, Michael wrote: On Tue, Sep 09, 2008 at 08:58:47PM +0100, Anselm R Garbe wrote: I'm glad to announce dwm-5.2 and dmenu-3.9. You can download the new releases from: Always wondered if there anything like changelog for releases? Thanks anyway, great work! Take a look at http://code.suckless.org/hg/dwm/log/e4bcaca8e6ef -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] patch: fix screen flicker with monocle
On Sep 8, 2008, at 2:09 AM, Anselm R Garbe wrote: 2008/9/8 Donald Chai [EMAIL PROTECTED]: Actually, this is a totally unrelated problem. The problem is that XGrabKeyboard generates focus events (XGrabKeyboard is called by the X server after establishing the passive grab with XGrabKey). So, all keyboard shortcuts cause the window under the mouse to briefly get focus. I've used Metacity (the GNOME WM) with focus-follows-mouse, and it doesn't have this behavior when I Alt-Tab. I can't see why grabbing keys is an issue here. focus() only triggers a button grab on the old and new client which might causing this issue here. In Gnome WM you don't see this, because button grab's aren't necessary on a focus() basis, since it reparents the client windows and hence can keep the passive button grab for the whole lifetime of a client window on the frame window. So I fear, you/we have to live with this side effect. I find it strange that the extra focus events only happen for me; or maybe I'm just the only one who's bothered by it. (I see the same thing in wmii and awesome too.) From looking at the ion2 code, I figured out that XGrabKey with grab_window=root is the cause of the problem. If I instead call XGrabKey on all of root's children, no spurious focus events are generated. The following patch seems to fix things. I add my own background layer to capture keypresses, so xsetroot - bg will no longer work. :( grabkeyfix.patch Description: Binary data
Re: [dwm] dwm-5.2 / dmenu-3.9
Hi there! I want to announce that dwm-gtx-5.2 is released too. It can be downloaded as tarball as well as patchset to vanilla dwm. It extends dwm with better Xinerama support, automaticle pointer movement (wmii-2.5 style) and an additional Layout called deck to work better with small screens (= 1024x768) Tarball: http://s01.de/~gottox/files/dwm/dwm-gtx-5.2.tar.gz Diff: http://s01.de/~gottox/files/dwm/dwm-gtx-5.2.diff Mercurial: hg clone https://s01.de/~gottox/hg/dwm Projectpage: http://s01.de/~gottox/index.cgi/proj_dwm I try to keep my branch synchronous to vanilla dwm and merge changes from mercurial back to my repository asap. regards Gottox 2008/9/9, Anselm R Garbe [EMAIL PROTECTED]: Hi there, I'm glad to announce dwm-5.2 and dmenu-3.9. You can download the new releases from: http://code.suckless.org/dl/dwm/dwm-5.2.tar.gz http://code.suckless.org/dl/tools/dmenu-3.9.tar.gz Both releases contain various bug fixes and code polishings. Many thanks go to all geeks who have been involved in the development during the last weeks. Kind regards, --Anselm -- http://www.gnuffy.org - Real Community Distro http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)
