Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?

On Wed, Mar 5, 2008 at 12:38 PM, Anselm R. Garbe <arg_AT_suckless.org> wrote:

> First of all I want to get rid of setmwfact, MWFACT and mwfact,
> because I'd like to supply a saner way to setup the bar more
> freely. Actually I consider the following values in config.h
> (instead of BarPos):
>
> ----------------------------------------------------------
> /* bar position */
> #define BX sx
> #define BY sy
> #define BW sw
> #define BH bh
>
> /* master area */
> #define MX sx
> #define MY sy + bh
> #define MW ((int)(((float)sw) * 0.6))
> #define MH sh - bh
>
> /* tile area, might be on a different screen */
> #define TX sx + MW
> #define TY MY
> #define TW sw - MW
> #define BH MH
>
> /* monocle area, might be restricted to a specific screen */
> #define MOX sx
> #define MOY MY
> #define MOW sw
> #define MOH MH
> ----------------------------------------------------------
>

The flexibility is definitely good, however, it clutters the config.h with a
lot of dwm internals, may be unnecessarily. Worse of all, it may still not
be flexible enough for another person to modify it for a Xinerama layout of
his own.

I still think it will be a good decision to not give Xinerama first class
status in dwm. IMHO dwm should enable just enough abstraction (I suggest
tile()/drawbar() delegates in layout[]) so that Xinerama layouts can be
developed additionally along with regular old-fashioned layouts. This might
mean that there is no code overlap between Xinerama tile() and plain old
tile()... but IMO that's a better way to go with than putting Xinerama at
the core of dwm.

Dual screen or a multiscreen setups are more related to the layout than
dwm's core of tagging and focus control.

Plus, I think it is a good idea to go to a direction where many people can
take the dwm codebase and hack a new Xinerama layout onto it. The way you
are proceeding with Xinerama seems to focus a lot more on the tile stack /
monocle layout way doing things than just giving a mechanism for newer
Xinerama layouts. I will suggest that you contain as many Xinerama changes
as possible into drawbar() and tile() and push it as an alternative layout
along with other dwm layouts.

Ultimately, it depends on how fundamental you think the stack/monocle layout
is to dwm. I really think that multihead setups offer many more feasible
design choices than the highly popular stack/monocle layout for single
monitor setups.

_r

>
> I know that are some LOCs in the config.h, but they will allow
> to set dwm being used with Xinerama and without linking against
> -lXinerama, and also without reimplementing tile() or monocle()
> right NOW!
>
> I also plan to get rid of togglebar(), if you see not much use
> in the bar, put it on top of the T-area or M-area -- or move it
> offscreen.
>
> But this way, also the dzen-integration will be much easier and
> in a Xinerama setup you can make sure to let the bar appear only
> on a specific screen (or to let the T-area appear on a specific
> screen only).
>
> Actually the concept does only work up to 2 screens, but usually
> most people don't have more than 2 screens, and if someone has
> 3 or more screens, he might want to write his own version of
> tile() anyways.
>
> So I ask, do you think this decision is right? It will make dwm
> much simplier, Xinerama-capable and quite flexible in my eyes.
>
> Getting rid of mwfact, togglebar for the prize of Xinerama and
> monocle should be worth the effort, right?
>
> Kind regards,
> --
> Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
>
>
Received on Wed Mar 05 2008 - 23:42:29 UTC