Re: [dwm] Fwd: [hackers] separated layout-specific stuff...
Imho, this should be included into 4.4
2007/8/11, Jeremy O'Brien [EMAIL PROTECTED]:
On Sat, Aug 11, 2007 at 06:20:02PM +0200, Anselm R. Garbe wrote:
On Sat, Aug 11, 2007 at 03:11:11PM +0200, markus schnalke wrote:
Jeroen Schot [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 07:52:46AM -0500, Kurt H Maier wrote:
Two #include lines make a file ugly? How so?
It's not about the number of lines, it's about the concept. When I add a
layout (say 'gridmode') it will look:
#include tile.h
#include float.h
#include gridmode.h
#define LAYOUTS \
static Layout layout[] = { \
/* symbol function */ \
{ []=, tile }, /* first entry is default */ \
{ , floating }, \
{ [#], gridmode }, \
};
Looks pretty redundant/useless to me, which I find ugly :)
I think that looks clear ... but there is redundance, yes.
Yes there is redundance, but I think it is not worse than
before. Besides this, I can't think of a sane way how to build
up the layout list otherwise... So I think let's live with it.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Personally, I find the redundancy a small price to pay for the newfound
ease of adding new layouts.
--
Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB
http://pohl.ececs.uc.edu/~jeremy/jeremy.asc Linux ambelina 2.6.22.1 ppc
7447A, altivec supported PowerBook5,8 GNU/Linux
--
http://www.gnuffy.org - Real Community Distro
http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)
Re: [dwm] Update: bottomstack patch for latest 4.4 tip
On Sat, Aug 11, 2007 at 08:09:54PM -0400, James Turner wrote: Well the zoom function seems to work, but increasing the master area does not. I changed part of the incmaster function within tile.c to if(lt-arrange == floating) return; but I still can't increase the master in the bottom stack layout mode. Any ideas? The problem here is, that master is declared static in tile.o, so whenever you call incmaster it is only used in tile(). In bstack() you use the locally declared master in bstack.c instead ,) This all is due the fact that bstack is more a patch to tile than a separate layout. One solution I see would be to declare master globally in tile.h, - but this would make your patch dependend from tile... hmm. Let me think about this issue somewhat more. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Update: bottomstack patch for latest 4.4 tip
On Sat, Aug 11, 2007 at 08:09:54PM -0400, James Turner wrote:
Well the zoom function seems to work, but increasing the master area
does not. I changed part of the incmaster function within tile.c to
if(lt-arrange == floating) return; but I still can't increase the
master in the bottom stack layout mode. Any ideas?
Well I decided against making master global. I pushed a
changeset recently with following decisions:
MASTER is renamed to MWFACT (master width factor) - which is
more precise.
master in tile.c is renamed to mwfact, incmaster is renamed to
addtomwfact - which is also more precise.
So this change also points out, that your bstack patch should
contain something like MHFACT (master height factor) as counter
part. Except of zoom(), which you can re-use from tile, I
propose you clone the addtomwfact() behavior as follows for
bstack:
/* static */
static double mhfact = MHFACT;
/* extern */
void
addtomhfact(const char *arg) {
double delta;
if(lt-arrange != bstack)
return;
/* arg handling, manipulate mhfact */
if(arg (1 == sscanf(arg, %lf, delta))) {
if(delta + mhfact 0.1 delta + mhfact 0.9)
mhfact += delta;
}
lt-arrange();
}
And in config.h you add something like this (besides cloning
MHFACT similiar to MWFACT):
{ MODKEY, XK_h, addtomwfact,-0.05 }, \
{ MODKEY, XK_l, addtomhfact,0.05 } , \
{ MODKEY, XK_h, addtomwfact,-0.05 }, \
{ MODKEY, XK_l, addtomhfact,0.05 } , \
This is somewhat cumbersome for bstack, but the only other
option would be to design bstack as patch to tile.c.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
[dwm] floating
Well I think the separation of layouts to make them less coupled is the correct decision in general. However, I also believe, that the floating layout should be integral part of dwm and not be part of the way how other layouts are included. This allows that checks like lt-arrange == floating are valid. Checks to other layouts in core parts of dwm will not be done and they are also not recommended in other layouts. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] floating
I think it's also possible to remove floating layout from dwm and use it as a fallback if arrange == NULL. In my eyes floating does nothing which belongs to a arrange function. The arrange function should only arrange the windows. In my opinion it shouldn't handle things like the visibility of a window. With this in mind the floating function is empty. 2007/8/12, Anselm R. Garbe [EMAIL PROTECTED]: Well I think the separation of layouts to make them less coupled is the correct decision in general. However, I also believe, that the floating layout should be integral part of dwm and not be part of the way how other layouts are included. This allows that checks like lt-arrange == floating are valid. Checks to other layouts in core parts of dwm will not be done and they are also not recommended in other layouts. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 -- http://www.gnuffy.org - Real Community Distro http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)
Re: [dwm] Update: bottomstack patch for latest 4.4 tip
On Sun, Aug 12, 2007 at 12:53:46PM +0200, Anselm R. Garbe wrote:
On Sat, Aug 11, 2007 at 08:09:54PM -0400, James Turner wrote:
Well the zoom function seems to work, but increasing the master area
does not. I changed part of the incmaster function within tile.c to
if(lt-arrange == floating) return; but I still can't increase the
master in the bottom stack layout mode. Any ideas?
Well I decided against making master global. I pushed a
changeset recently with following decisions:
MASTER is renamed to MWFACT (master width factor) - which is
more precise.
master in tile.c is renamed to mwfact, incmaster is renamed to
addtomwfact - which is also more precise.
So this change also points out, that your bstack patch should
contain something like MHFACT (master height factor) as counter
part. Except of zoom(), which you can re-use from tile, I
propose you clone the addtomwfact() behavior as follows for
bstack:
/* static */
static double mhfact = MHFACT;
/* extern */
void
addtomhfact(const char *arg) {
double delta;
if(lt-arrange != bstack)
return;
/* arg handling, manipulate mhfact */
if(arg (1 == sscanf(arg, %lf, delta))) {
if(delta + mhfact 0.1 delta + mhfact 0.9)
mhfact += delta;
}
lt-arrange();
}
And in config.h you add something like this (besides cloning
MHFACT similiar to MWFACT):
{ MODKEY, XK_h, addtomwfact,-0.05 }, \
{ MODKEY, XK_l, addtomhfact,0.05 } , \
{ MODKEY, XK_h, addtomwfact,-0.05 }, \
{ MODKEY, XK_l, addtomhfact,0.05 } , \
This is somewhat cumbersome for bstack, but the only other
option would be to design bstack as patch to tile.c.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Because of the nature of bstack, would it make more sense to just patch
tile.c rather than make it it's own layout and clone the addtowfact
function? Since changes are still happening I would like to take this
time to make sure the patch is done the so called correct way.
Thanks.
--
James Turner
BSD Group Consulting
http://www.bsdgroup.org
Re: [dwm] floating
On Sun, Aug 12, 2007 at 01:19:12PM +0200, Enno Gottox Boland wrote: I think it's also possible to remove floating layout from dwm and use it as a fallback if arrange == NULL. In my eyes floating does nothing which belongs to a arrange function. The arrange function should only arrange the windows. In my opinion it shouldn't handle things like the visibility of a window. With this in mind the floating function is empty. I agree on the fact that ban/unban stuff does not belong to arrange(), I plan to change this. However, floating is used to resize all visible windows respecting increment hints, so if you toggle to floating when in some tiled layout, you will notice that all windows will get a size they asked for. This is the only reason why floating exists explicitly besides ban/unban stuff. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Update: bottomstack patch for latest 4.4 tip
On Sun, Aug 12, 2007 at 07:57:15PM +0200, Anselm R. Garbe wrote: On Sun, Aug 12, 2007 at 10:12:14AM -0400, James Turner wrote: I went ahead and created a new patch that patches tile.c rather then creating an all new bstack layout. You can find it here: http://calminferno.net/files/dwm-4.4-bstack-tile.diff or attached. Well I accept you decision, but I think it might be worth to consider to design a bigtile layout as a tile.c replacement, which contains your bstack feature, the NMASTER revival, and maybe other things. I think that should be the direction, it would even make maintenance of patches much more simplier. So consider to design the bstack patch as a tile replacement rather than as a tile-addon/extension... Sorry, my English is a nightmare today ;) -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] floating
On Sun, Aug 12, 2007 at 08:47:45PM +0200, Enno Gottox Boland wrote: Ok I agree. What about resizing windows to c-rx, c-ry, ... ? If we set c-rx = c-x = wa-x, ... in manage(). This can be used to resize a window to its startsize when you put it in the floating layout. In an early stage of dwm development I did it that way, but it was more a pain, esp. if I only want to resize one or two clients freely, but keeping all other windows at their position... The current way is a feature, at least for me ;) Btw. besides some polishing that arrange functions shouldn't do ban/unban stuff, I also plan to support that tags are remembered through X window properties during stopping and starting a new instance of dwm... If those todos are achieved, 4.4 is ready. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
