On 3/5/08, Ritesh Kumar <[EMAIL PROTECTED]> wrote: > On Wed, Mar 5, 2008 at 12:38 PM, Anselm R. Garbe <[EMAIL PROTECTED]> 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.
