Re: [dwm] recent changes

Hi there,

well, despite the fact that I will think about pancakes mail
regarding a different tile-approach in a multihead setup, I
changed the hardcoded defines in most recent hg tip as follows:

There is a setgeoms() function pointer in dwm.c now, which is
used to init all geometry related variables (sx, ..., mow). By
default there is the single-screen build-in called
setdefaultgeoms, which behaves like the config.def.h values.

But as an example of how I handle attaching/detaching the second
monitor in my setup, I added my config.anselm.h which contains a
function setanselmgeoms() and two shortcut-functions:

void
anselmgeoms(const char *arg) {
        setgeoms = setanselmgeoms;
        arrange();
}

void
defgeoms(const char *arg) {
        setgeoms = setdefaultgeoms;
        arrange();
}

which I bound to Mod1-a and Mod1-d resp.

I think this approach is the most flexible one and allows for
user-fine tuning.

Similiarly one can add resizemaster() in config.h, if one wants
to change the master geometry.

Kind regards,
     Anselm

On Wed, Mar 12, 2008 at 07:25:50PM -0400, voltaic wrote:
> I agree with Joerg's argument that single-monitor usability should not be
> sacrificed for multihead support. I tested out 4.8 two days ago (so I guess
> I'm already out of date) and one glaring issue that bothered me was the hard
> coded tile/stack area sizes. It worked very well with Xinemara, but how
> about laptop users who connect and disconnect external monitors frequently?
> If I want to be able to use DWM 4.8 in its current state I would have to
> compile multiple executables, each configured specifically for a particular
> monitor resolution. This would also involve restarting DWM frequently and
> losing tag information. I think for those people who use a large external
> monitor for everyday use and a projector for work the hard coding of various
> dimensions would be pretty inconvenient.
>
> The obvious solution is to make available the resolution of each attached
> screen and in that manner set the BX, BY, BW, WX, etc. values as
> proportions. As I've said before, I don't know a whole lot about
> programming, and I know nothing about X programming, so I don't know if what
> I asked for is possible at all. But consider that this is from a daily DWM
> user.
>
> I also should point out that with the high resolution external monitors
> these days, I find very little use for a dual head setup. I especially find
> the current setup distracting, because having the stack area in the
> secondary screen forces me to go back and forth between the two screens all
> the time. I think this is less efficient than having all the relevant
> information right in front of you at all times. I envision the secondary
> head to be used as a scratch area, or a static place for notes and the like
> to be kept. I know pancake mentioned this before, and I agree with him. I
> also think that with widescreen monitors it really becomes logical to split
> the screen vertically into a master and stack area. Itt really makes little
> sense to relegate the primary screen (a high resolution widescreen monitor)
> as the master area because a single window rarely need to occupy the whole
> screen. I think the option should be there for people who have lower
> resolution screens (perhaps a different tile layout) but for me no single
> window requires 1680 pixels of horizontal space.
>
> Another comment with regard to what Joerg said: I am also a former ION3
> user, but I have not been bothered by the lack of tabs in DWM. Tabs would
> add another dimension of variables that the user needs to sort through to
> get to the window he/she wants. In DWM the only construct that toggles the
> visibility of a window is the visibility state of a tag. If we add tabs to
> this mixture the windows have the chance of being doubly hidden (by the
> visibility of a tag as well as of a tab), and become twice removed from
> being readily accessible with a single keystroke. Tabs also add an extra
> status bar to each window, crowding the screen, and wasting screen space.
> That is just my opinion, though.
>
> -voltaic
>
> On 3/12/08, Joerg van den Hoff <j.van_den_hoff_AT_fzd.de> wrote:
> >
> > 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 be really good. the importance of this
> > increases if there
> > are more than 2-3 layouts in the future.
> >
> > I know the above is biased somewhat by my experience with `ion3'. and it's
> > only my personal wishlist. and of course `dwm' is already really good
> > right now.
> > I think it's understood that I'm not expecting/demanding something.
> >
> >
> > joerg
> >
> >
> >
> >
> >

-- 
 Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361