Re: [dwm] EWMH code would enable some code cuts
* Henrik Holst [EMAIL PROTECTED] [080506 02:30]: I think an implementation of EWMH would make it possible to remove the dwm panel (the one that reads stdin and displays it) from dwm code base. In that way dwm would be smaller (or maybe just break even) and more symmetric with how dmenu is fitted to the equation today. It would also allowe the user to choose whatever kind of panel he or she wants. That is an escape and dpanel (or some other name maybe) would not have to be counted in the ridicules 2 kloc limit. :P Adding _initial_ EWMH support will cost about 200 LOC. You can get rid of all fonts and drawing stuff in turn. The problem is that it feels unnatural to the tags approach. And to achieve dwm's statusbar (including tagbar) functionality one needs to extend Extended Window Manager Hints even more, adding something like a _DWM_SELTAGS atom and others to handle toggleview(), toggletag(), etc. And you need to write a panel supporting this extended-extended non-already-standard. And plus dzen for stdin processing. -- Alexander Polakov
Re: [dwm] snapping bugs with multiple screens
On Mon, May 05, 2008 at 02:12:10PM +0200, Matthias-Christian Ott wrote: Anselm R. Garbe [EMAIL PROTECTED] wrote: I can confirm your observation and it took quite a while that someone reported it. I expected it much earlier ;) The snap-algorithm uses wx, wy, ww, and wh as screen dimension boundaries. There is no support for multiple screens in the snap algorithm, so it is only intended to work correctly in a single screen setup or at least at wx and ww in multi screen setups. As a workaround I propose to disable snapping in multihead setups through setting it to 0. Proper snap-support would make dwm dependend from XrandR or Xinerama and I don't want to do that (or alternatively of yet another complex geometrie setup at compile time). Is there a particular reason for this? I mean it would be the proper Simplicity. I'd rather remove snapping instead of supporting XrandR/Xinerama natively if that helps. naturally/intuitively expected behaviour, so adding a dependency (which is of course bad from a suckless perspective) gives you a lot of benefits (including simpler GEOM setups). Let's do a poll! Well, I kind of agree the reconsideration of DEFGEOM. For my personal needs I need DEFGEOM however. But maybe it should be simplier. It feels to fine-grain. I believe reducing it to bar position and window area should be fine. master and tile areas belong to the Layout, maybe those values should be extracted to the Layout definition. I see some potential to make SNAP a variable however, which could be set in DEFGEOMs for this reason. Seems unreasonable. Why should you throw away information that is provided by extensions which have to be present anyhow (in order to use multiple monitors)? Right, I propose to get rid of snapping at all. Does anyone uses snapping at all? Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] JUCE app patch
On Sun, May 04, 2008 at 02:08:09PM +0200, Tinou wrote: I just noticed dwm crashed every time I start a JUCE app ( www.rawmaterialsoftware.com/*juce*/). Here is a simple patch to make it work. Applied, thanks. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] hg tip minor modification proposals
Applied, thanks.
On Mon, May 05, 2008 at 08:29:58PM +0200, Szabolcs Nagy wrote:
1 unnecessary space after Layout definition
2 some may need lt in their config (eg i use lt-isfloating in my
pushup/down algo)
--- a/dwm.c Mon May 05 20:06:43 2008 +0200
+++ b/dwm.c Mon May 05 20:26:51 2008 +0200
@@ -112,7 +112,7 @@
const char *symbol;
void (*arrange)(void);
Bool isfloating;
-} Layout;
+} Layout;
typedef struct {
const char *class;
@@ -244,10 +244,12 @@
Window root, barwin;
/* configuration, allows nested code to access above variables */
+Layout layouts[];
+Geom geoms[];
+Layout *lt = layouts;
+Geom *geom = geoms;
#include config.h
#define TAGSZ (LENGTH(tags) * sizeof(Bool))
-Layout *lt = layouts;
-Geom *geom = geoms;
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] EWMH code would enable some code cuts
On Tue, May 06, 2008 at 12:14:10AM +0200, Henrik Holst wrote: I think an implementation of EWMH would make it possible to remove the dwm panel (the one that reads stdin and displays it) from dwm code base. In that way dwm would be smaller (or maybe just break even) and more symmetric with how dmenu is fitted to the equation today. It would also allowe the user to choose whatever kind of panel he or she wants. That is an escape and dpanel (or some other name maybe) would not have to be counted in the ridicules 2 kloc limit. :P But seriously, EWMH support with struts and all, should be on the top of the list for dwm. EWMH is too important to be left to forks. Something for 5.0? EWMH is evil. I see reasons for people arguing to get rid of the status text processing code in dwm, but the tagging approach is a too integral part of dwm which heavily depends on the bar. Thus there is no way to get rid of the bar. The overhead introduced by EWMH and a EWMH-driven bar for the tagging concept would make the code base much more complex. Currently I'm at a stage to reconsider features for removal again. Esp. DEFGEOM seems to have a lot of potential for simplification(s). Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] snapping bugs with multiple screens
btw. what naming convention do bx, by, bw,wx,... follow?
Re: [dwm] snapping bugs with multiple screens
On Tue, May 06, 2008 at 11:22:04AM -0400, hiro wrote:
btw. what naming convention do bx, by, bw,wx,... follow?
b{x,y,w} = bar x, y, width
w{x,y,w,h} = window area x, y, width, height
m{x,y,w,h} = master area x ...
t{x,y,w,h} = tile area x ...
mo{x,y,w,h} = monocle area x ...
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
