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

On 3/5/08, Ritesh Kumar <ritesh_AT_cs.unc.edu> wrote:
> 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
> >
> >
>
>

Maybe it's time to make dwm a little more modular.
Received on Wed Mar 05 2008 - 23:52:31 UTC