Re: [dwm] recent changes
multiscreen setups (hopefully) will remain a rather small niche, I'd say: large desktop monitors are already available at affordable prices One of the reasons multiple monitors are more popular than big monitors is that, if you've got a graphics card that supports multiple outputs anyway, the cost of adding a second mass-market size monitor is significantly less than buying a large monitor replacement. Likewise it's easier to scrounge a second unused monitor at work than manage to get a big monitor purchase authorised. So whilst retaining excellent single monitor support is important, I don't think multihead setups should be downplayed. (I'm waiting for the dwm codebase to settle down before looking at porting my patches forward. Ironically it's not the new features that are making me wait but the moving code around and back again seeing what's aesthetically nicer or gives a smaller wc value that has me waiting.) -- cheers, dave tweed__ [EMAIL PROTECTED] Rm 124, School of Systems Engineering, University of Reading. while having code so boring anyone can maintain it, use Python. -- attempted insult seen on slashdot
Re: [dwm] recent changes
Two 1600x1200 monitors will give you 3200x1200 for less than 400 euros. It's not only cheap, but I haven't seen any monitor with that much pixels at all. Of course Laptops are becoming more and more common these days, and a lot of people add bigger monitors to it. I think It's ok if you say dwm is not made for xinerama. But it used to be on the todo list... -- hiro
Re: [dwm] recent changes
On Thu, Mar 06, 2008 at 08:20:00PM +0100, Anselm R. Garbe wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
hoping not to interfere. just a few thoughts from a pure user perspective
(mine...):
-- multiscreen, even Xinerma support is nice to have as long as single screen
operation is not compromised. it seems some beloved things might be left behind?
I, too, think `setmwfact' is quite useful, e.g.. multiscreen setups (hopefully)
will remain a rather small niche, I'd say: large desktop monitors are already
available at affordable prices and the other big use case will be labtops.
so I'd say optimal support of single screen operation is _much_ more important
than multi-screen.
-- coming from ion3 I see some nice advantages of dwm (not the least a main
author not permanently on war with something/someone or other).
-- the multitude of patches/opionions of what is an indispensable layout says
something important: one size fits all does not work so well.
enforcing that every user should go and patch dwm to his/her liking?
well, user's usually can't do that either for reasons of capabilities or time
or both...
so what I would really like to see is a small(!) number of good
layouts to choose from. monocle plus standard stack seem to come
with 4.8, which is good. my question here would be, whether not consensus could
be reached on, say, 4-5 sensible layouts which should be available. e.g. a nice
functionality
in `ion3' is to transpose the current layout, meaning reflection
along the screen diagonal (top right to bottom left). this would, e.g.
bring standard stack to vertical stack, if I understand the intention
of the latter right. so, instead of introducing vertical stack via a patch
or additional standard layout should a 'transpose' option not be preferred? I
personally would be perfectly content with the following layouts,
which should be available by default:
- floating
- standard stack
- monocle
- a tiling layout which always splits the currently largest subwindow
keeping new windows as 'near square' as
possible (i.e. implicit decision whether to split horizontally
or vertically). (up to three this is identical to standard stack, but
with 4 windows one would get 4 equal size windows and after that
further splitting seems usually not to make that much sense).
augmenting this by a 'transpose' (and maybe mirroring left/right and up/down)
option should cover almost any imaginable desire (in this area, I mean :-))
-- the greatest shortcoming of `dwm' in my view is the absense of tabbing
support. I would value something like this much more than sophisticated
multiscreen support. monocle essentially provides this in 'full screen'
mode but it would be great to have it on a per-window basis.
-- another point (patches seem around, but again: this should be done upstream,
I believe): switching between floating and stacking and back does not restore
window sizes. but this would be extremly helpful: without memorizing the window
sizes/positions of the floating layout a switch to stacking destroys any
arrangment of windows of the previous floating layout
(especially on workspaces/tag groups which you are currently _not_ viewing ...)
being able to go back to the floating layout as it was when
last visited would really be nice.
-- a related point: a per-workspace/tag layout approach (having some floating,
some stacking views) would
Re: [dwm] recent changes
On Fri, Mar 07, 2008 at 12:02:31PM +0100, Szabolcs Nagy wrote:
On 3/7/08, pancake [EMAIL PROTECTED] wrote:
* If we change these #defines to integer variables we will be able to write
external
commands to swap master and slave area between two monitors, join both
areas, manage
setmwfact or creating mixed layouts. And everything without touching the
core :)
+togglebar
I agree on having the defines being assigned to specific
variables/I pushed a change accordingly some minutes ago.
However, the defines are useful as they are, because they are
allowed to depend on bh and s{x,y,w,h} which are initialized
before the assignments (otherwise things like int mw = sw; in
config.h won't work, because sw is not initialized in the global
scope already due to DisplayWidth() depending on dpy).
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes
On Tue, 11 Mar 2008 23:05:56 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
On Fri, Mar 07, 2008 at 12:02:31PM +0100, Szabolcs Nagy wrote:
On 3/7/08, pancake [EMAIL PROTECTED] wrote:
* If we change these #defines to integer variables we will be able to
write
external
commands to swap master and slave area between two monitors, join both
areas, manage
setmwfact or creating mixed layouts. And everything without touching the
core :)
+togglebar
I agree on having the defines being assigned to specific
variables/I pushed a change accordingly some minutes ago.
Yeah! nice!
I have reimplemented the togglebar and setmwfact for current 4.8.
My config is attached too, it should work on mostly common configurations.
Obviously the mwfact plugin doesn't works well with multiple screens.
patches are attached.
Im not very proud of these codes, but they work and show how
to change the master/tile/bar variables.
However, the defines are useful as they are, because they are
allowed to depend on bh and s{x,y,w,h} which are initialized
before the assignments (otherwise things like int mw = sw; in
config.h won't work, because sw is not initialized in the global
scope already due to DisplayWidth() depending on dpy).
Yeah this is good :) we can ignore hardcoding the resolution if
we only use one monitor using:
#define SCRT sw*3/5
#define SCRW sw
#define SCRH sh
What do you think about the addition of a third area for static
applications that can be used for a third monitor or a second one
with a default dwm configuration in the first monitor. This would
be a sample configuration.
screen 1 screen 2
+---+ +-+-+
| || | | |
| || |-|-|
| || | | |
+--++ +-+-+
We can define a toggle to switch between the screen 1 and two with a
zoom key to move applications between static area and master one.
This way we can also enhace the layout configuration with a single
monitor with three areas in this way:
+---+
| | | M = Master
| M | T | T = Tiled
+-| | S = Static
| S | |
+-+-+
The simplest way I can imagine for this is by specifying a tag into a frame area
to make it visible in some place of the screen.
Maybe this is too many changes for 4.7 - 4.8 but I maybe good for single
and multiple screens.
--pancake/* See LICENSE file for copyright and license details. */
/* appearance */
#define BORDERPX 6
#define FONT -*-terminus-medium-r-normal-*-14-*-*-*-*-*-*-*
#define NORMBGCOLOR #cc
#define NORMFGCOLOR #00
#define NORMBORDERCOLOR #172
//#cc
#define SELBORDERCOLOR #cc
//#0066ff
#define SELBGCOLOR #172
//#0066ff
#define SELFGCOLOR #ff
#define SCRT sw*3/5
#define SCRW sw
#define SCRH sh
/* bar position */
#define BX 0
#define BY 0
#define BW MW
/* window area, including floating windows */
#define WX 0
#define WY bh
#define WW sw
#define WH sh - bh
/* master area */
#define MX WX
#define MY bh
#define MW SCRT
#define MH SCRH - bh
/* tile area, might be on a different screen */
// TX=MW
#define TX MW
#define TY 0
#define TW SCRW-SCRT
#define TH SCRH
/* monocle area, might be restricted to a specific screen */
#define MOX MX
#define MOY MY
#define MOW SCRW-8
#define MOH MH
/* tagging */
const char tags[][MAXTAGLEN] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
Rule rules[] = {
/* class:instance:title substr tags ref isfloating */
{ Firefox, tags[8], False },
{ Gimp, NULL, True },
{ MPlayer, NULL, True },
{ Acroread, NULL, True },
};
/* layout(s) */
#define RESIZEHINTS False /* False - respect size hints in tiled resizals */
#define SNAP 32 /* snap pixel */
Layout layouts[] = {
/* symbol function isfloating */
{ []=, tilev, False },
{ []|, tileh, False }, /* first entry is default */
{ [M], monocle, True },
};
//{ , floating, True },
#include mwfact.c
#include togglebar.c
/* key definitions */
#define MODKEY Mod1Mask
Key keys[] = {
/* modifier key function argument */
#if ANSELM_OFFICE
{ MODKEY, XK_p, spawn,
exec dmenu_run -fn 'FONT' -nb 'NORMBGCOLOR' -nf 'NORMFGCOLOR' -sb 'SELBGCOLOR' -sf 'SELFGCOLOR' -x 0 -y 0 -w 1280 },
#else
{ MODKEY, XK_p, spawn,
exec dmenu_run -fn 'FONT' -nb 'NORMBGCOLOR' -nf 'NORMFGCOLOR' -sb 'SELBGCOLOR' -sf 'SELFGCOLOR' },
#endif
{ MODKEY|ShiftMask, XK_Return, spawn, exec Eterm },
{ MODKEY, XK_j, focusnext, NULL },
{ MODKEY, XK_k, focusprev, NULL },
{ MODKEY, XK_r, reapply, NULL },
{ MODKEY, XK_Return, zoom, NULL },
{ MODKEY, XK_Tab, viewprevtag, NULL },
{ MODKEY, XK_m, setlayout, [M] },
{ MODKEY, XK_f, setlayout, },
{ MODKEY, XK_t, setlayout, []= },
{ MODKEY, XK_v, setlayout, []| },
{ MODKEY, XK_h, setmwfact, -64 },
{ MODKEY, XK_l, setmwfact, +64 },
{ MODKEY, XK_b, togglebar, NULL },
{ MODKEY|ShiftMask, XK_space, togglefloating, NULL },
{ MODKEY|ShiftMask, XK_c, killclient, NULL },
{ MODKEY, XK_0, view,
Re: [dwm] recent changes
On 3/7/08, pancake [EMAIL PROTECTED] wrote: * If we change these #defines to integer variables we will be able to write external commands to swap master and slave area between two monitors, join both areas, manage setmwfact or creating mixed layouts. And everything without touching the core :) +togglebar
[dwm] recent changes
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes
On 3/6/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: I investigated further today and refactored a lot. First of all nice tileresize() is not in lexicographic order in dwm.c ;)
Re: [dwm] recent changes
On 3/6/08, Anselm R. Garbe [EMAIL PROTECTED] wrote:
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
yes finally i don't need extra layout.c to use bstack
comments:
there is an unnecessary whitespace after 'monocle(void) { '
tileresize(..) should be predeclared since it may be useful for other
layouts as well
imho there are a couple of unnecessary '('')' around M{X,Y,..} T{X,Y,..}
i still don't like the extra borders when only one window is shown so
i use a maximize(Client *c) which temporarily sets the border to 0
tileresize() then sets the border back.
Re: [dwm] recent changes
Szabolcs Nagy dixit (2008-03-06, 23:23):
On 3/6/08, Anselm R. Garbe [EMAIL PROTECTED] wrote:
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
yes finally i don't need extra layout.c to use bstack
However, this poses a problem that bottomstack layout would be the only
standard layout (apart from float and monocle), while it usually makes
sense to have bottomstack and standard tile interchangable.
To have both I'd have to have to hack two versions of tile(), with two
different sets of M{X,Y,W,H} and T{X,Y,W,H} values, right?
So this would still need a patch rather than be usable out of the box
the usual bottomstack way.
Best,
--
[a]
signature.asc
Description: Digital signature
Re: [dwm] recent changes
On 3/6/08, Antoni Grzymala [EMAIL PROTECTED] wrote:
To have both I'd have to have to hack two versions of tile(), with two
different sets of M{X,Y,W,H} and T{X,Y,W,H} values, right?
So this would still need a patch rather than be usable out of the box
the usual bottomstack way.
hm maybe one can use
const int MX =..;
void setbottomstack(void){
MX = ..;
}
void setrightstack(void){
MX = ..;
}
it is shorter than writing a whole layout
Re: [dwm] recent changes
On 3/6/08, Szabolcs Nagy [EMAIL PROTECTED] wrote: const int MX =..; ..that should be plain int, not const int
Re: [dwm] recent changes
My impressions about this commit are:
*) At the beggining I feel a bit confused until fixed the master and slave
resolutions on a single screen (because xinerama seems to crash my kernel
and I can't test it in all its glory atm)
*) Using this concept on a single screen looks a bit more claustrofobic
because of the lack of setmwfact.
- On my 20 screen, the lack of setmwfact doesnt affects to me, but
using a static mwfact with the proper values for the monocle layout
is imho much more clear than having a variable one which distracts.
- Dropping the statusbar from the slave area we can play with a bigger
area (we have some more pixels O:)
* We need a MOBW variable when single window is opened or using monocle layout.
*) I really miss the possibility to link mouse actions on the statusbar :(
it makes the use much more usable when you have a hand on the keyboard
and the another one in the mouse, so you don't have to move the pointer
to zoom, kill or select clients.
I would like to have this patch on mainstream too. I think my current patch
fits quite well for most uses and doesnt needs to be configurable, maybe
a little of feedback can help to adopt this functionality, which IMHO
for larger screen (or multiple ones) much more productive than moving the
mouse around the clients.
*) I also miss the clients per tag patch O:) but I will probably redesign it
for dwm 4.8, so we can probably change the concept of CPT to define the
number of windows to be shown in the master area.. But I understand that
this is not necessary in mainstream because can be replaced with correct
use of the tagging concept.
*) My general impression was a bit frustrating at the beggining, but after
reading some source, playing a bit with the configuration and thinking
in some solutions I come to the conclusion that I'm pretty happy with
this new concept.
Source comments:
* If we change these #defines to integer variables we will be able to write
external
commands to swap master and slave area between two monitors, join both areas,
manage
setmwfact or creating mixed layouts. And everything without touching the core :)
* We will be able to define a master layout, tile layout.
I know that not all layouts will work for all screen configurations, but we
can just
try to handle the most common uses.
* looks like the monocle layout doesnt works as expected so it eats some more
screen
than in should :) and the right/bottom borders are out of screen
* at line 1567 (nice number):
...
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next), i++)
if(i 0) {
if(i 1 i == n) /* remainder */
...
This nested conditional looks ugly to my eyes, I would prefer to setup the
proper value for 'c' before starting the loop instead of checking the
conditional for every client.
Nice work!
--pancake
On Thu, 6 Mar 2008 20:20:00 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes
Sorry when I dislike this solution, but it's far to complex. I wished
a solution which is simpler and without splitting tile.
Let me try to build a different idea.
2008/3/7, pancake [EMAIL PROTECTED]:
My impressions about this commit are:
*) At the beggining I feel a bit confused until fixed the master and slave
resolutions on a single screen (because xinerama seems to crash my kernel
and I can't test it in all its glory atm)
*) Using this concept on a single screen looks a bit more claustrofobic
because of the lack of setmwfact.
- On my 20 screen, the lack of setmwfact doesnt affects to me, but
using a static mwfact with the proper values for the monocle layout
is imho much more clear than having a variable one which distracts.
- Dropping the statusbar from the slave area we can play with a bigger
area (we have some more pixels O:)
* We need a MOBW variable when single window is opened or using monocle
layout.
*) I really miss the possibility to link mouse actions on the statusbar :(
it makes the use much more usable when you have a hand on the keyboard
and the another one in the mouse, so you don't have to move the pointer
to zoom, kill or select clients.
I would like to have this patch on mainstream too. I think my current patch
fits quite well for most uses and doesnt needs to be configurable, maybe
a little of feedback can help to adopt this functionality, which IMHO
for larger screen (or multiple ones) much more productive than moving the
mouse around the clients.
*) I also miss the clients per tag patch O:) but I will probably redesign it
for dwm 4.8, so we can probably change the concept of CPT to define the
number of windows to be shown in the master area.. But I understand that
this is not necessary in mainstream because can be replaced with correct
use of the tagging concept.
*) My general impression was a bit frustrating at the beggining, but after
reading some source, playing a bit with the configuration and thinking
in some solutions I come to the conclusion that I'm pretty happy with
this new concept.
Source comments:
* If we change these #defines to integer variables we will be able to write
external
commands to swap master and slave area between two monitors, join both
areas, manage
setmwfact or creating mixed layouts. And everything without touching the
core :)
* We will be able to define a master layout, tile layout.
I know that not all layouts will work for all screen configurations, but we
can just
try to handle the most common uses.
* looks like the monocle layout doesnt works as expected so it eats some
more screen
than in should :) and the right/bottom borders are out of screen
* at line 1567 (nice number):
...
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next), i++)
if(i 0) {
if(i 1 i == n) /* remainder */
...
This nested conditional looks ugly to my eyes, I would prefer to setup the
proper value for 'c' before starting the loop instead of checking the
conditional for every client.
Nice work!
--pancake
On Thu, 6 Mar 2008 20:20:00 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key:
[dwm] recent changes since 3.6[.1]
Hi there,
dwm-3.7 is on its way, and some more polishing appeared:
- I replaced the Arg-union typedef with a const char *, this
leads to a cleaner config.h in Key definitions, e.g.
[..]
{ MODKEY, XK_d, incnmaster, -1 }, \
{ MODKEY, XK_i, incnmaster, 1 }, \
{ MODKEY, XK_h, incmasterw, -15 }, \
{ MODKEY, XK_l, incmasterw, 15 }, \
[..]
- zoom() now only works in tiling layout, togglemax() is
externalized now and bound to Mod1-m (versatile layout only)
- this made zoom() less cluttered and the Mod1-Return
behavior more predictable
- versatile clients are indicated by an empty square in front of
their title, maximized versatile clients are indicated by a
filled square in front of their title (basically I reuse the
drawsquare() stuff for tags)
- I also renamed resizemaster() into incmasterw(), because it
behaves similiar to incnmaster().
So please check if hg tip is usable (to me it is). Personally I
believe dwm is really polished now.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes since 3.6[.1]
dwm-3.7 is on its way, and some more polishing appeared:
- I replaced the Arg-union typedef with a const char *, this
leads to a cleaner config.h in Key definitions, e.g.
[..]
{ MODKEY, XK_d, incnmaster, -1 }, \
{ MODKEY, XK_i, incnmaster, 1 }, \
{ MODKEY, XK_h, incmasterw, -15 }, \
{ MODKEY, XK_l, incmasterw, 15 }, \
[..]
- zoom() now only works in tiling layout, togglemax() is
externalized now and bound to Mod1-m (versatile layout only)
- this made zoom() less cluttered and the Mod1-Return
behavior more predictable
You forget to inform the focusclient(1) focusclient(-1) change too.
btw i read your patch and I think you can reduce about 7 lines your
code if you ignore the invalid values, that imho they must be ignored, so
this check must be done in configure time, not in execution time.
--
for(c = sel-next; c !isvisible(c); c = c-next);
if (!c) {
if (atoi(arg) 0)
for(c = clients; c !isvisible(c); c = c-next);
else
for(for(c = clients; c c-next; c = c-next);
; c !isvisible(c); c = c-prev);
}
}
--
BTW, about the incmasterw I think the default value for it should be
a multiplier of 8. Because resolutions are 640, 800, 1024, 1280, ...
all of them can be divided by 8 without precision loss.
This way I recommend to use 16, 32 or 64.
I personally use 32 on all my boxes. 16 is too low, and I've use't two or
three times to get the width I want. BTW imho 15 is wrong.
BTW i think this value could be proportional to screen resolution instead
of pixel size.
--pancake
Re: [dwm] recent changes since 3.6[.1]
On Thu, Feb 22, 2007 at 05:24:45PM +0100, pancake wrote:
dwm-3.7 is on its way, and some more polishing appeared:
- I replaced the Arg-union typedef with a const char *, this
leads to a cleaner config.h in Key definitions, e.g.
[..]
{ MODKEY, XK_d, incnmaster, -1 }, \
{ MODKEY, XK_i, incnmaster, 1 }, \
{ MODKEY, XK_h, incmasterw, -15 }, \
{ MODKEY, XK_l, incmasterw, 15 }, \
[..]
- zoom() now only works in tiling layout, togglemax() is
externalized now and bound to Mod1-m (versatile layout only)
- this made zoom() less cluttered and the Mod1-Return
behavior more predictable
You forget to inform the focusclient(1) focusclient(-1) change too.
I mentioned it in a different mail...
btw i read your patch and I think you can reduce about 7 lines your
code if you ignore the invalid values, that imho they must be ignored, so
this check must be done in configure time, not in execution time.
--
for(c = sel-next; c !isvisible(c); c = c-next);
if (!c) {
if (atoi(arg) 0)
for(c = clients; c !isvisible(c); c = c-next);
else
for(for(c = clients; c c-next; c = c-next);
; c !isvisible(c); c = c-prev);
}
}
--
You were right that it could be simplified, but your version
seems incorrect to me, - what if I really want to focus the
previous client? I pushed a different version which removed the
switch()... now interpreting 0 as prev, and = 0 as next...
BTW, about the incmasterw I think the default value for it should be
a multiplier of 8. Because resolutions are 640, 800, 1024, 1280, ...
all of them can be divided by 8 without precision loss.
This way I recommend to use 16, 32 or 64.
I personally use 32 on all my boxes. 16 is too low, and I've use't two or
three times to get the width I want. BTW imho 15 is wrong.
BTW i think this value could be proportional to screen resolution instead
of pixel size.
I set MASTERWIDTH to 640 per thousand and the steps to 32
pixels, I think that's ok...
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
sender: Anselm R. Garbe date: Tue, Feb 20, 2007 at 03:24:12PM +0100 EOQ I have a question: if instead of patching the layout.c file for new layouts, each of us who created a layout patch would create a separate file, such as: layout_grid.c layout_bstack.c Do what you like, but don't forget that those files must be included in Makefile somehow and the function signatures must be local in layout.c as well... so I consider this as don't do it that way ;) Ok then, thanks for the advice :) Cheers, Alex
Re: Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
sender: Anselm R. Garbe date: Wed, Feb 21, 2007 at 10:44:14AM +0100 EOQ On Wed, Feb 21, 2007 at 11:23:53AM +0200, Alexandru E. Ungur wrote: sender: Anselm R. Garbe date: Tue, Feb 20, 2007 at 03:24:12PM +0100 EOQ I have a question: if instead of patching the layout.c file for new layouts, each of us who created a layout patch would create a separate file, such as: layout_grid.c layout_bstack.c Do what you like, but don't forget that those files must be included in Makefile somehow and the function signatures must be local in layout.c as well... so I consider this as don't do it that way ;) Ok then, thanks for the advice :) There is also another reason - the wmii-2 way only supported the arrange-function being integrated that way. But in dwm we have things like incnmaster() or resizemaster() which manipulate the tile()-layout. Hence it would get very messy to handle such add-on functions with such a way like we had in wmii-2 - so it is much easier and simplier for patch contributors to put everything into 1 single superfeature.patch file. Ah, I see what you mean. Sorry I didn't explain too well what I meant. The suggestion was actually for the patch creators to change the way they create patchs (they have to change it anyway at this point :D) so that it is easier for the endusers to integrate multiple patches. I did not suggest modifying dwm in any way. What I did for my patch (well, before I asked) was create that extra layout_grid.c and then patching Makefile (adding one 'word') and dwm.h (adding one line). All these are done from the patch, no need for any changes on dwm side. Now, because the changes to dwm were so small, I can easily integrate other patches now ;-) and I figured if other contributors would do the same (where applicable of course) then it would be easier for all of us to integrate multiple patches. I'll release the patch right away, and then it will be clear what I'm talking about :-) Cheers, Alex
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
|The motivation is reducing the code, grouping the functions into |more intuitive sets and reducing the amount of exported |functions (only because several functions have been called from |a different object in one place - that was really annoying). |So all in all this also reduces the call graph and makes the |executable slightly smaller than before. Beside the fact of the |new Layout struct being ready for more layout-specific |additions. Could I just see if it's possible for mainline to just not mark drawtext as not static? (I'm looking to see if there's a simpler way of re-instituting per-window titles than Ross Mohn's patch - which is very impressive but looks to me like a huge pain to maintain - which inherently involves both writing strings and traversing the client list so having both sets of functions static means more patching. I'd image Ross's titles patch would also be slightly shorter without having to un-static this.) Does the slight change in executable size from making them static actually remotely matter? I work with images/databases and the resident code size is almost always a vanishing fraction of the data-structure memory usage. For example, on my x86-64 machine sizeof(Client) is 408 bytes, of which 256 is the title array. Given that the majority of applications don't change title remotely frequently I've wondered about the tradeoff in making that a malloced array. Of course client list traversals in dwm is going to be nowhere near as cache hot as application code - and the cache ought to map only those fields actually used at during the traversals in layout algorithm - but if you want to optimise something I'd suggest data structure size is more practically relevant than executable size. cheers, dave tweed ___ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
if any day dwm gets into the no-more-releases state would be nice to provide the patches inside the same tarball/repo and include them in config.h or config.mk. For me DWM is perfect except for the lack of the append-window patch. But this will be really easy to re-implement thanks to the new redesign of dwm. --pancake On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: On Mon, Feb 19, 2007 at 11:56:18AM I wrote: Scanning the bundles showing up on [hackers] it is clear that those of us who have any significant investment in dwm patches are in for rough sledding trying to track this refactoring. To which Anselm replied with a detailed list of his changes explaining that none should be a significant impediment to propagating patches. Well I have to describe the last step: I split screen.c into layout.c and tag.c again. layout.c contains all arrangement-related stuff (*also new algorithms like dogrid should go into this file for patches*). tag.c contains the tag-related stuff like rules, and the view- and tag-specific functions. This seems more natural to me than putting everything into a single file. In that same posting I further wrote: Will there be appreciable new functionality or is this just gilding the lily? At what point will st get any real attention? So what is the motivation for this refactoring? Personally The motivation is reducing the code, grouping the functions into more intuitive sets and reducing the amount of exported functions (only because several functions have been called from a different object in one place - that was really annoying). So all in all this also reduces the call graph and makes the executable slightly smaller than before. Beside the fact of the new Layout struct being ready for more layout-specific additions. All in all I think that after this refactoring dwm is in a state that we don't need more releases. I have no request for additional functionality - it basically fits perfectly my needs. So see the motivation as final polishing/review. I have much more interest in st reaching a minimal level of utility than in a refactoring of dwm that really presents us nothing new. Hehe, I'm with you, but lack of time at the moment. I delayed st for several reasons. But its development will go on soon. But an st that we can all help evolve will make much more of a difference to the suckless community than an endlessly polished dwm. Hehe yes. But note that dwm was not written from scratch and suffered to some extend to design decisions made in wmii, this has been fixed now. The aspect ratio algorithm is going to be slightly changed, after this I think it will be time for 3.6. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Tue, Feb 20, 2007 at 11:08:28AM +, David Tweed wrote: |The motivation is reducing the code, grouping the functions into |more intuitive sets and reducing the amount of exported |functions (only because several functions have been called from |a different object in one place - that was really annoying). |So all in all this also reduces the call graph and makes the |executable slightly smaller than before. Beside the fact of the |new Layout struct being ready for more layout-specific |additions. Could I just see if it's possible for mainline to just not mark drawtext as not static? (I'm looking to see if there's a simpler way of re-instituting per-window titles than Ross Mohn's patch - which is very impressive but looks to me like a huge pain to maintain - which inherently involves both writing strings and traversing the client list so having both sets of functions static means more patching. I'd image Ross's titles patch would also be slightly shorter without having to un-static this.) Hmm, actually I doubt marking drawtext as non-static will help. Simply because such a patch should come packed with a drawtitle(Client *c) function which should be located in main.c to easily access drawtext instead. This is because the drawtitle function needs to map the drawed client title anyways to the client title window (you will also need resizetitle() anyways). Does the slight change in executable size from making them static actually remotely matter? I work with images/databases and the resident code Actually it does not matter much. But I prefer keeping functions static which don't really need to be exported. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
|Hmm, actually I doubt marking drawtext as non-static will help. |Simply because such a patch should come packed with a |drawtitle(Client *c) function which should be located in main.c |to easily access drawtext instead. This is because the |drawtitle function needs to map the drawed client title anyways |to the client title window (you will also need resizetitle() |anyways). Note: I'm doing this for my own purposes because I really need a list of all visible clients' titles to work effectively; I'm not imagining it for mainstream. I'm experimenting with a different approach of collecting all the titles into one window in the corner, which is why I need to use both nexttiled() and drawtext() in same function. This seems to need only 2 call-sites. This approach is less useful than real on-window titles, but I'm just checking how useful before stripping Ross's solution from his patchset. But I hadn't noticed you've made nexttiled exported, which means my function can probably live in main.c. cheers, dave tweed ___ Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Tue, Feb 20, 2007 at 01:25:19PM +0100, Anselm R. Garbe wrote: On Tue, Feb 20, 2007 at 11:08:28AM +, David Tweed wrote: |The motivation is reducing the code, grouping the functions into |more intuitive sets and reducing the amount of exported |functions (only because several functions have been called from |a different object in one place - that was really annoying). |So all in all this also reduces the call graph and makes the |executable slightly smaller than before. Beside the fact of the |new Layout struct being ready for more layout-specific |additions. Could I just see if it's possible for mainline to just not mark drawtext as not static? (I'm looking to see if there's a simpler way of re-instituting per-window titles than Ross Mohn's patch - which is very impressive but looks to me like a huge pain to maintain - which inherently involves both writing strings and traversing the client list so having both sets of functions static means more patching. I'd image Ross's titles patch would also be slightly shorter without having to un-static this.) Hmm, actually I doubt marking drawtext as non-static will help. Simply because such a patch should come packed with a drawtitle(Client *c) function which should be located in main.c to easily access drawtext instead. This is because the drawtitle function needs to map the drawed client title anyways to the client title window (you will also need resizetitle() anyways). Well ok, I made drawtext extern (with putting the square drawing algorithm into a different function) - I also will move the draw stuff from main.c to draw.c again - I think it was a bad idea to merge it into main.c - except setfont and getcolor. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
sender: Anselm R. Garbe date: Tue, Feb 20, 2007 at 11:35:17AM +0100 EOQ Hello, On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: On Mon, Feb 19, 2007 at 11:56:18AM I wrote: Scanning the bundles showing up on [hackers] it is clear that those of us who have any significant investment in dwm patches are in for rough sledding trying to track this refactoring. To which Anselm replied with a detailed list of his changes explaining that none should be a significant impediment to propagating patches. Well I have to describe the last step: I split screen.c into layout.c and tag.c again. layout.c contains all arrangement-related stuff (*also new algorithms like dogrid should go into this file for patches*). I have a question: if instead of patching the layout.c file for new layouts, each of us who created a layout patch would create a separate file, such as: layout_grid.c layout_bstack.c etc. wouldn't that be easier for people wanting to try several layout patches? This way at least the layout patching part would be a simple file copy, free of any merging conflicts. Cheers, Alex
Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)
On Tue, Feb 20, 2007 at 02:53:45PM +0200, Alexandru E. Ungur wrote: sender: Anselm R. Garbe date: Tue, Feb 20, 2007 at 11:35:17AM +0100 EOQ On Mon, Feb 19, 2007 at 09:22:41PM -0500, John S. Yates, Jr. wrote: On Mon, Feb 19, 2007 at 11:56:18AM I wrote: Scanning the bundles showing up on [hackers] it is clear that those of us who have any significant investment in dwm patches are in for rough sledding trying to track this refactoring. To which Anselm replied with a detailed list of his changes explaining that none should be a significant impediment to propagating patches. Well I have to describe the last step: I split screen.c into layout.c and tag.c again. layout.c contains all arrangement-related stuff (*also new algorithms like dogrid should go into this file for patches*). I have a question: if instead of patching the layout.c file for new layouts, each of us who created a layout patch would create a separate file, such as: layout_grid.c layout_bstack.c Do what you like, but don't forget that those files must be included in Makefile somehow and the function signatures must be local in layout.c as well... so I consider this as don't do it that way ;) wouldn't that be easier for people wanting to try several layout patches? This way at least the layout patching part would be a simple file copy, free of any merging conflicts. See above, it's not so simple. And I don't want to hack the Makefile with such quirks we had once in wmii-2. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
[dwm] recent changes to dwm (since dwm-3.5)
On Mon, Feb 19, 2007 at 11:56:18AM -0500, John S. Yates, Jr. wrote:
Scanning the bundles showing up on [hackers] it is clear that
those of us who have any significant investment in dwm patches
are in for rough sledding trying to track this refactoring.
Will there be appreciable new functionality or is this just
gilding the lily? At what point will st get any real
attention?
I don't think that you will need to do nasty things with the
next dwm release when porting your patches. I did following
changes basically:
view.c and tag.c have been merged into screen.c
draw.c has been merged into main.c
Some convenience functions appeared in client.c (detach[stack](),
attach[stack]()), some functions of client.c have been moved to
screen.c and vice versa.
Float[ing] has been renamed into versatile (also in the man
page). isfloat has been renamed to isversatile.
DEFMODE, TILESYMBOL and FLOATSYMBOL have been removed in favor
of the new Layout struct which is initialized in config.h as
follows:
#define LAYOUTS \
static Layout layout[] = { \
/* symbol function */ \
{ []=,tile }, /* first entry is default */ \
{ ,versatile }, \
};
So adding a new layout like grid is easy:
#define LAYOUTS \
static Layout layout[] = { \
/* symbol function */ \
{ []=,tile }, /* first entry is default */ \
{ +++,grid }, \
{ ,versatile }, \
};
dotile() has been renamed into tile and is static in screen.o,
dofloat() has been renamed into versatile, but is kept extern
because there are several checks in the wm checking if the
versatile algorithm is in use (except some tile-related checks
in resizemaster() and incnmaster() - which are only performed
in screen.c).
extern Layout *lt; points to the current layout in use,
so all occurences of arrange(); have been replaced with
lt-arrange();, lt-symbol points to the symbol of the layout.
Consequently I renamed all occurences of mode into layout now
(bmw has been renamed to blw for instance).
Besides the resize()-related changes (esp. to configurerequest
and other parts) nothing else has changed.
For those of you, who'd prefer a direct mode switcher I consider
adding following setlayout to mainstream dwm:
void
setlayout(Arg *arg) {
if(arg-i 0 || arg-i = nlayout)
return;
lt = layout[arg-i];
lt-arrange();
}
This would allow following wmii-2-ish style of working:
[..]
{ MODKEYXK_t, setlayout, { .i = 0 } }, \
{ MODKEYXK_g, setlayout, { .i = 1 } }, \
{ MODKEYXK_f, setlayout, { .i = 2 } }, \
[..]
(as a rough example).
Hope this mail helps anyone to don't loss the track toward 3.6.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes to dwm (since dwm-3.5)
No rotation cycle between layout modes?
maybe a final {0} would be nice for this. I like to minimize the number
of keys to use.
--pancake
On Mon, Feb 19, 2007 at 11:56:18AM -0500, John S. Yates, Jr. wrote:
Scanning the bundles showing up on [hackers] it is clear that
those of us who have any significant investment in dwm patches
are in for rough sledding trying to track this refactoring.
Will there be appreciable new functionality or is this just
gilding the lily? At what point will st get any real
attention?
I don't think that you will need to do nasty things with the
next dwm release when porting your patches. I did following
changes basically:
view.c and tag.c have been merged into screen.c
draw.c has been merged into main.c
Some convenience functions appeared in client.c (detach[stack](),
attach[stack]()), some functions of client.c have been moved to
screen.c and vice versa.
Float[ing] has been renamed into versatile (also in the man
page). isfloat has been renamed to isversatile.
DEFMODE, TILESYMBOL and FLOATSYMBOL have been removed in favor
of the new Layout struct which is initialized in config.h as
follows:
#define LAYOUTS \
static Layout layout[] = { \
/* symbol function */ \
{ []=,tile }, /* first entry is default */ \
{ ,versatile }, \
};
So adding a new layout like grid is easy:
#define LAYOUTS \
static Layout layout[] = { \
/* symbol function */ \
{ []=,tile }, /* first entry is default */ \
{ +++,grid }, \
{ ,versatile }, \
};
dotile() has been renamed into tile and is static in screen.o,
dofloat() has been renamed into versatile, but is kept extern
because there are several checks in the wm checking if the
versatile algorithm is in use (except some tile-related checks
in resizemaster() and incnmaster() - which are only performed
in screen.c).
extern Layout *lt; points to the current layout in use,
so all occurences of arrange(); have been replaced with
lt-arrange();, lt-symbol points to the symbol of the layout.
Consequently I renamed all occurences of mode into layout now
(bmw has been renamed to blw for instance).
Besides the resize()-related changes (esp. to configurerequest
and other parts) nothing else has changed.
For those of you, who'd prefer a direct mode switcher I consider
adding following setlayout to mainstream dwm:
void
setlayout(Arg *arg) {
if(arg-i 0 || arg-i = nlayout)
return;
lt = layout[arg-i];
lt-arrange();
}
This would allow following wmii-2-ish style of working:
[..]
{ MODKEYXK_t, setlayout, { .i = 0 } }, \
{ MODKEYXK_g, setlayout, { .i = 1 } }, \
{ MODKEYXK_f, setlayout, { .i = 2 } }, \
[..]
(as a rough example).
Hope this mail helps anyone to don't loss the track toward 3.6.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes to dwm (since dwm-3.5)
On Mon, Feb 19, 2007 at 06:19:21PM +0100, pancake wrote:
No rotation cycle between layout modes?
maybe a final {0} would be nice for this. I like to minimize the number
of keys to use.
You are right, I replaced togglelayout with setlayout(-1); now,
however setlayout can also be used as direct layout selector by
request in config.h.
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes to dwm (since dwm-3.5)
sender: Anselm R. Garbe date: Mon, Feb 19, 2007 at 05:38:24PM +0100 EOQ On Mon, Feb 19, 2007 at 11:56:18AM -0500, John S. Yates, Jr. wrote: Scanning the bundles showing up on [hackers] it is clear that those of us who have any significant investment in dwm patches are in for rough sledding trying to track this refactoring. Will there be appreciable new functionality or is this just gilding the lily? At what point will st get any real attention? I don't think that you will need to do nasty things with the next dwm release when porting your patches. I did following changes basically: No nasty things needed to port the grid patch. I had a really easy time porting it, and the whole thing looks much cleaner now, there are less places I needed to touch to get my patch done. Thanks! :-) Cheers, Alex
Re: [dwm] recent changes to dwm (since dwm-3.5)
On Mon, Feb 19, 2007 at 08:39:14PM +0100, markus schnalke wrote: extern Layout *lt; points to the current layout in use, so all occurences of arrange(); have been replaced with lt-arrange();, lt-symbol points to the symbol of the layout. Consequently I renamed all occurences of mode into layout now (bmw has been renamed to blw for instance). if you could explain, cause I don't know why you choose identifiers like `lt' which IMHO don't really speak for themself, instead of just taking `layout' which are only 4 letters more? I think using `layout' provides so much more information for so less more costs. Why shouldn't we invest that penny? I'll think about it. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes to dwm (since dwm-3.5)
On Mon, Feb 19, 2007 at 11:56:18AM I wrote: Scanning the bundles showing up on [hackers] it is clear that those of us who have any significant investment in dwm patches are in for rough sledding trying to track this refactoring. To which Anselm replied with a detailed list of his changes explaining that none should be a significant impediment to propagating patches. In that same posting I further wrote: Will there be appreciable new functionality or is this just gilding the lily? At what point will st get any real attention? So what is the motivation for this refactoring? Personally I have much more interest in st reaching a minimal level of utility than in a refactoring of dwm that really presents us nothing new. Don't get me wrong, I love dwm. And I program for a living -- begriming 35 years ago with systems written entirely in assembler -- so I believe I can appreciate finely crafted code. But an st that we can all help evolve will make much more of a difference to the suckless community than an endlessly polished dwm. /john
