Re: [dwm] and now for something completely different...

[Ritesh Kumar]

On Thu, Mar 6, 2008 at 11:34 AM, y i y u s <[EMAIL PROTECTED]> wrote:

> Well, I have been thinking about the last dwm changes and I don't like
> the new monocle thing. I have decided that I don't use different
> layouts at all, so I have highly patched current hg tip to suit my
> needs.
> The patch is a bit dirty (there are things which can be improved, and
> I have included my personal configuration). I know official dwm won't
> behave this way, but maybe you can get some ideas from this patch.
> Basically it removes the layouts concept, for me togglefloating is
> enough. I also don't need monocle, a single function suffices (now it
> is called togglemax, it should be maximize, but ok). I have also
> included some mouse functions in the bar. Probably you can have
> problems in xinerama, but I cannot test it.
> I'd like to hear your opinion, because once 4.8 is released I plan to
> split it up in several patches if people have interest...
>
> slds,
>
> --
>
>
I would like to know how diverse are the people on the list in terms of the
actual layouts and dwm features they use... that will be good feedback for
all of us to know about the way dwm is patched and used by the community. I
see value in allowing more people to be able to _easily_ patch dwm for their
needs and be able to learn from it and incorporate essential features in
dwm.

I personally patch dwm so that I can easily restrict the *number* of windows
that are shown in the stack layout. Its based on pancake's older
clientspertag patches and shows in the status bar how many windows are
hidden from view. Now, restricting the number of windows to 1 easily makes
it full screen... and at the cost of a bit of elegance in the code I was
able to hack in a monocle behavior for this particular case of limiting the
number of displayed windows to 1.

Now, the monocle behavior touched focusnext() and focusprev() and I also
touched drawbar() to show the number of hidden windows... I couldn't get all
this done cleanly separated in tile(). The point I am trying to make is that
if a lot of people patch dwm.c for whatever functionality they need then we
didn't do a good job in dwm.c to help abstract and modularize things. Also,
the one thing that is modularized and abstracted out in dwm, through the
variable layout[], is the function tile() which I haven't  modified heavily.

I am not suggesting delaying 4.8 but I guess a good strategy going forward
will be to get a feel of what kind of things the audience on this list like
to modify about dwm and what's dwm's core. We should do something to cleanly
separate *those* things in dwm. IMHO tile is definitely not a good choice...
I would even argue that fitting Xinerama layouts in core dwm is also a step
in the wrong direction.

_r

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

[Ritesh Kumar]

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
>
>

Re: [dwm] Xinerama: back to the roots

[Ritesh Kumar]

On Tue, Mar 4, 2008 at 3:18 AM, Tuncer Ayaz <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 4, 2008 at 3:17 AM, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Mar 3, 2008 at 6:27 PM, y i y u s <[EMAIL PROTECTED]> wrote:
> >
> >
> > >
> > > >  well, I agree that the current Xinerama support is also not the
> > > >  way to go. First of all it is far to complex in the code for
> > > >  the benefit it implements. And around 90% of all dwm users have
> > > >  no Xinerama or Multihead support in my eyes.
> > > >
> > > >  So I believe a real invention will be a tile() with Xinerama
> > > >  support instead and a status bar which can be positioned more
> > > >  flexible (just using a certain screen only to save screen real
> > > >  estate).
> > > >
> > >
> > > As one of the users with just one monitor, I'm very happy with this
> > > decision. Anyway, I will keep thinking about a good xinerama
> > > implementation.
> > > But what I would really like is a pre-release of st, what's the new
> > > estimated time? I think we can forget about mid February... and a new
> > > dwm would be great too, with or without xinerama. Any idea about when
> > > all this will be available? (take your time, I'm just asking, you
> > > know)
> > >
> >
> > I too like the idea of abstracting the Xinerama code away from the main
> dwm
> > codebase. Given the debate on design choices, I am sure people will like
> to
> > keep different Xinerama layouts. It will be a good idea to give all the
> > ideas time to evolve and incorporate the essential features into dwm
> core.
> >
> > The bar is tricky...
> > I don't use dual monitors but I know that I will not like looking at the
> > "main" monitor for status information while I am working on the second
> (or
> > nth) monitor. If I were to take a shot, I would replicate the status bar
> on
> > each monitor with subtle differences in the content (say, for partition
> > sets, I would highlight all the tags for that monitor). If I wanted
> > real-estate I would use shortcuts to turn off bar display all together
> from
> > all screens. However, this is just my choice... the point I am trying to
> > make is that there should be an easy way to hack similar features in
> > Xinerama setups with dwm.
> >  So, I would recommend abstracting drawbar in layouts[].
> >
> > Also, I too am very interested in st. I tried fetching it from
> > http://www.suckless.org/cgi-bin/hg.rc/st but I got a 404-Not found :(
>
> what about:
> $ hg clone http://www.suckless.org/hg.rc/st
>

Yup... that works. Thanks!

_r

Re: [dwm] Xinerama: back to the roots

[Ritesh Kumar]

On Mon, Mar 3, 2008 at 6:27 PM, y i y u s <[EMAIL PROTECTED]> wrote:

> >  well, I agree that the current Xinerama support is also not the
> >  way to go. First of all it is far to complex in the code for
> >  the benefit it implements. And around 90% of all dwm users have
> >  no Xinerama or Multihead support in my eyes.
> >
> >  So I believe a real invention will be a tile() with Xinerama
> >  support instead and a status bar which can be positioned more
> >  flexible (just using a certain screen only to save screen real
> >  estate).
> >
>
> As one of the users with just one monitor, I'm very happy with this
> decision. Anyway, I will keep thinking about a good xinerama
> implementation.
> But what I would really like is a pre-release of st, what's the new
> estimated time? I think we can forget about mid February... and a new
> dwm would be great too, with or without xinerama. Any idea about when
> all this will be available? (take your time, I'm just asking, you
> know)
>

I too like the idea of abstracting the Xinerama code away from the main dwm
codebase. Given the debate on design choices, I am sure people will like to
keep different Xinerama layouts. It will be a good idea to give all the
ideas time to evolve and incorporate the essential features into dwm core.

The bar is tricky...
I don't use dual monitors but I know that I will not like looking at the
"main" monitor for status information while I am working on the second (or
nth) monitor. If I were to take a shot, I would replicate the status bar on
each monitor with subtle differences in the content (say, for partition
sets, I would highlight all the tags for that monitor). If I wanted
real-estate I would use shortcuts to turn off bar display all together from
all screens. However, this is just my choice... the point I am trying to
make is that there should be an easy way to hack similar features in
Xinerama setups with dwm.
So, I would recommend abstracting drawbar in layouts[].

Also, I too am very interested in st. I tried fetching it from
http://www.suckless.org/cgi-bin/hg.rc/st but I got a 404-Not found :(

_r

Re: [dwm] [dvtm-patch] Top stack layout

[Ritesh Kumar]

Hi,
Marc, do you think it will be a good idea to put some of these patches
for download on your website? May be you can also put links to all the
publicly shared git repositories?

Regards,
_r

On Tue, Feb 26, 2008 at 3:05 PM, Claudio M. Alessi <[EMAIL PROTECTED]> wrote:

> Hi all.
>
> For a personal choose i usually put all the secondary things at the top
> of the screen mantaining the current working area at the bottom. For
> this reason i thought would be nice to do the same thing with dvtm and i
> hacked the ``bottom stack'' layout in order to make it works exactly as
> the contrary; from here the ``top stack'' layout. I found it very useful
> expecially when i have only three maximized clients (often). The code
> works but i will not surprise to find bugs.
>
> I hope someone will found it helpful.
>
> --
> Claudio M. Alessi
>
> -BEGIN GEEK CODE BLOCK-
> Version: 3.1
> GCS/MU d-@ s: a--> C++(+++) UB++>$ P+> !L E--- W++(+++)
> N+@ o--> K? w+@> O-@> M- V? PS+@ PE+@ Y+ PGP> t(-)@ 5?
> X+ R? tv-- b+> DI-- D? G e+@> h--@> r y*
> --END GEEK CODE BLOCK--
>
>

[dwm] [dvtm] mouse selection just inside a window?

[Ritesh Kumar]

Hi dvtm users,

I was wondering, is it possible to restrict mouse selection to a window in
dvtm? Currently, multiline mouse selections in dvtm (with mouse handling
disabled in dvtm) goes across window borders. There is no mouse selection
with mouse handling enabled in dvtm.

One way to do this is to handle mouse events in dvtm and use xclip to handle
the X clipboard.

Any thoughts?

_r

Re: [dwm] [dvtm-patch] Status bar optional

[Ritesh Kumar]

On Feb 19, 2008 12:57 PM, Marc Andre Tanner <[EMAIL PROTECTED]> wrote:

> On Tue, Feb 19, 2008 at 01:50:40PM +0100, Claudio M. Alessi wrote:
> > Hi,
> >i'm continuing to study the dvtm code in order to be able to make
> some
> > "real" improvement. I'm a (not so) beginner C programmer so all my
> > experiments and your points of view about are useful to improve myself
> (not
> > only dvtm). It's free software, after all.
> >
> > As for the mouse support, i don't use the status bar at all (at least
> not
> > in box other than my laptop) so there is no reason to build such
> feature.
> > Even i think that such "modularization" help to make the code cleaner (
> e.g.
> > i had to move the terminal size variables from the updatebaros()
> function
> > to the resize_screen() one, which seems to be a better place for them).
> >
> > This will give a bit of work to Leonardo Taccari which is working on the
> > pkgsrc dvtm packages; a new option is needed, i guess.
> >
> > Hope this helps but, if not, feel free to insult me ;-)
>
> I don't want to clutter the code with all the #ifdefs plus some day we
> might introduce tags/workspaces and then a statusbar will become more
> important.
>

I can support not using #ifdefs unless absolutely necessary. I have large
chunks of my own code (thankfully not for long term use) where I used a lot
of #ifdefs... so I know the hard way :(. I guess the argument is that code
should be modular for programmer's ease (may be secondarily for conserving
memory or hard-drive space). I think it will be a welcome effort if somebody
can separate the mouse handling and status bar routines cleanly from dvtm
code and allow simple config.h lines to enable/disable them.

The other thing is that compilers are *supposed* to "dead code eliminate"
anything inside normal conditional statements if they know for sure... which
makes a case for using const variables and normal if statements for doing
#ifdef like stuff. Using const also helps with type checking and better
error messages. Bad news is the *supposed* in the first statement ;).

For workspaces, here's a crazy idea... why not just use dvtm inside screen
(may be that's still not good enough for tags :/ )? If bloat is a factor, I
have always been curious: besides terminal emulation, regions and fullscreen
windows... what more is there in screen?

_r

Re: [dwm] [ANNOUNCE] dvtm-0.4

[Ritesh Kumar]

On Feb 6, 2008 11:38 AM, Marc Andre Tanner <[EMAIL PROTECTED]> wrote:

> Hi,
>
> dvtm-0.4 is out, changes are:
>
>  * Only draw borders where necessary (titlebar + vertical separator)
>   http://www.brain-dump.org/projects/dvtm/#screenshots
>
>  * Respect cursor visibility of apps running within dvtm
>
>  * Autoquit feature, dvtm quits when the last shell is closed
>
>  * Support for window title escape sequence (xtermset -T title)
>
>  * Links against ncurses by default
>
>  * Compilation fix for NetBSD (hopefully)
>
>  * Some bugfixes and code cleanups
>
> Remember to do a make unicode if you have an UTF-8 locale.
>
>  http://www.brain-dump.org/projects/dvtm/dvtm-0.4.tar.gz
>
> Below is a list of TODO items for future versions:
>
>  * implement tagging, there is already a tagging branch which contains
>   my current code in the git repository but i still need to figure
>   out some sane keybindings.
>
>  * terminal emulation fixes: make arrow keys work within vim (without
>   the TERM=linux workaround). Fix a problem with the keypad when dvtm
>   is launched via putty
>
>  * implement a command mode (i am not yet sure about this one)
>
>  * scrollback history support (this is a low priority item for me)
>
> Apart from that i consider dvtm feature complete.
>
>
Really nice work Marc. I welcome all the changes in dvtm 0.4.
Also, I now think that the ctrl g +  shortcut is much more convenient
than the command mode idea I had proposed... so may be you can strike that
item off the TODO list all together :)

_r

Re: [dwm] cycling through tags?

[Ritesh Kumar]

I have seen this issue of configuration management and program complexity
come again and again. However, I have seen different people solve it
different ways... none being necessarily technically superior to anything
else. The way I see it, its more subjective and depends on the community
which shapes the product.

However, I do see an inherent cleanliness in using a programming language
for configuration itself. Most configuration languages are a combination of
assignments, comments and in rare cases some control flow. The question is,
why do the duplicated work of parsing and converting between one set of data
structures to another when you already have a well tested compiler/runtime
with you.

The compilation step does make the whole thing a little more complicated.
Had it been a scripting language (say lua) we could have made the
configuration file in lua itself which would be really convenient if the
window manager logic was written in lua too... we would just need in include
the file and be done with it... no compilation step required. In dwm's case,
I think C is more of a matter of subjective choice.

On the other hand for a source based distribution like gentoo, the
compilation step really doesn't matter because every upgrade of dwm would
require a recompilation and the configuration file in C is handled properly.

_r

On Feb 1, 2008 9:19 AM, Doug Bell <[EMAIL PROTECTED]> wrote:

> markus schnalke wrote:
> > Joerg van den Hoff <[EMAIL PROTECTED]> wrote:
> > >
> > > definitely don't believe in configuring a window manager by
> > > editing the source code. at the very least, this seems to imply
> > > that one starts over and over again with  each new release (or
> > > one has to verify that the config header default layout has not
> > > changed.
> >
> > I upgrade dwm every half year or so. Normally there is no need for
> > users to follow the latest development.
> >
> > > I would stil be in favour of some simple(-minded)
> > > configuration file of the keyword/value variety (or even activating
> > > this by a compile flag only, leaving the defaults defined in config.h
> ).
> >
> > What is the big difference between config.h and a .dwmrc?
> > If .dwmrc would be simple, then editing config.h is needed anyway.
> > (Applying patches is needed anyway.)
> > If .dwmrc would be complete, then it would be the same as config.h.
> >
> > You sayed, that compling is not a problem.
> > And how often do you change your window manager configuration?
> >
> > > that's no good if I'm actually "only" a user of a nice window manager
> > > who needs to get other things done.
> >
> > So just take what vanilla-dwm offers you.
> > ... or if you want more, then apply some patches.
> >
> > > if I look at the home page there a quite a few nice extensions to
> `dwm'
> > > which are tied to specific releases and are simply left behind while
> > > dwm is developed further. I think this is a pity.
> >
> > dwm is community development. It's from developers for developers.
> > The available patches are just published personal extensions.
>
> I guess I agree with Joerg.  I've been using dwm for more than a year
> (and various versions of wmi[i] for years before that), but I recently
> switched to awesome ().  awesome is a fork
> of dwm with a different philosophy.
>
> I don't mean to troll here - I don't plan any more posts.  I just wanted
> to share some advantages I see in awesome:
>
>  - Conventional config file:  Recompiling isn't much of a pain, but it
>is another step.
>
>  - Distribution package:  The use of a config file allows me to use the
>Debian package as-is, like I do for almost everything else.
>
>  - Potential popularity:  I'd like tiling window managers to gain in
>popularity to increase the incentive to fix broken applications that
>don't play nice.  The above factors should contribute to long-term
>popularity.
>
>  - More built-in features:  Several features that would require dealing
>with patches (and keeping them current and playing nice together)
>are built into awesome.  And some features I don't use are easy to
>ignore.
>
>  - Interesting new development:  awesome is still fairly early in
>development, so it's still experimenting with new ideas.  dwm is
>more mature but less exciting.
>
> Yes, the awesome executable is three times the size of dwm's, but, for
> me, that is outweighed by the advantages above.  At least awesome's
> executable is still less than 1% of the size of Firefox's  :)
>
> Doug.
>
>

Re: [dwm] Nice "suckless" password manager

[Ritesh Kumar]

I (too) don't use any password management... I have seen people talk about
the efficacy of a simple function of a 'global password' and the  'website
name'. I adopted that as I thought that was a good technique.
I guess if one is really paranoid, they can use the above system and
generate an md5 for the password and use it instead. However, I like the
convenience of being able to type my password
   - directly in the application (mostly a site in a browser)
   - and be able to do it from any machine I want.

_r

On Jan 25, 2008 10:24 AM, Amit Uttamchandani <[EMAIL PROTECTED]> wrote:

> Hey guys,
>
> I posted a thread on the debian-user mailing list titled "Nice GUI/CLI
> Password Manager for Linux."
>
> I got some interesting answers. Mainly:
>
>  1. vim + encfs
>  2. Revelation - GTK app
>  3. pwsafe - CLI solution but looks like it hasn't been updated in a while
>  4. KWallet
>
> After DWM, I've been in a "suckless" mindset. So from the above list...it
> looks like vim + encfs is a good solution.
>
> What do DWM users use?
>
> Thanks,
> Amit
>
>

Re: [dwm] Status of DWM 4.8?

[Ritesh Kumar]

On Jan 24, 2008 9:24 PM, John S. Yates, Jr. <[EMAIL PROTECTED]> wrote:

> On Thu, 24 Jan 2008 15:38:25 +0100, Anselm wrote:
>
> >sorry but I relocated to the UK during Dec/Jan to start a new
> >job and so things slowed down somewhat. I will be back working
> >soon on dwm, so a release is likely to happen in the next two
> >weeks (including all planned features).
>
> Best o' luck in a new job!
>
> Any word on st?
>

me is also eagerly waits for st... :)

lolz,

_r

Re: [dwm] [ANNOUNCE] dvtm-0.3

[Ritesh Kumar]

On Jan 12, 2008 12:44 PM, Marc Andre Tanner <[EMAIL PROTECTED]> wrote:

> Hi,
>
> dvtm-0.3 is out, changes are:
>
>  * Possibility to specify applications which should be launched after
>   dvtm startup in config.h and on the command line.
>
>  * New commands redraw, escapekey and killclient.
>
>  * Allow commands to take multiple arguments. This changed how
>   key bindings are defined in config.h. Currently only create uses
>   this, the second argument is the window title.
>
>  * Mouse support configurable via config.h.
>
>  * Allow key bindings with no modifier prefix if modifier is set to zero.
>
>  * Make it possible to send the modifier to the underlying application
>   by doubling it (when you press ^g ^g the underlying app will receive
>   ^g).
>
>  * Configurable status bar position.
>
>  * Better UTF-8 locale detection.
>
>  * Various code cleanups.
>
>  * Some kind of manual page.
>
> Remember to do a make unicode if you have an UTF-8 locale.
>
>  http://www.brain-dump.org/projects/dvtm/dvtm-0.3.tar.gz
>
> Regards,
> Marc
>


Hi Marc,
I just tried out dvtm... its a really nice application of dwm concepts
to the console. Really awesome!

I wanted to bounce off a few ideas from the audience about dvtm...

 -  We know that dwm uses Mod+ for most of its commonly used actions.
In this case, moving to a given client is basically about pressing Mod and
tapping 'j' a given number of times. However, in dvtm's case, its about
interchangeably tapping ^g and j a number of times... which is not as
smooth. I know we are trying to minimize interference of shortcuts... and
hence I was thinking, how would it be if we followed a 'command' and
'insert' mode thing (like vim) for dvtm. I mean, to move to a particular
client and zoom on it we do a ^g ... \n. The \n and ^g keys also
terminate the 'command' mode. A simple notification scheme could be used to
tell the user when he/she is in the command mode.

- What do you think about moving the status bar to the bottom left/right
corner superimposed on the border? I guess using a distinct color (inverse
video with a dark background color) should eliminate any confusion with the
application running in the master window. This will free up the statusbar
line and use the border line without interfering with its function.

 - Do you think it will be a good idea to terminate dvtm when the last
client is done? I fear accidental shutdowns so much that I generally map the
quit key in dwm to Ctrl+Alt+Shift+q. Quitting after the last client closes
seems to be a cleaner way to shutdown a terminal multiplexer IMHO.

What do you think?

_r

Re: [dwm] dzen replacing dwm status bar

[Ritesh Kumar]

On Dec 22, 2007 9:52 AM, Robert Manea <[EMAIL PROTECTED]> wrote:

> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>
> Hello.
>
> [...]
> > I think the slave window should simply have a fixed width, specified by
> the
> > user.
>
> Ok, SVN dzen (svn checkout http://dzen.googlecode.com/svn/trunk/ dzen)
> has the ability to grow/shrink the title dynamically now.
>
> You can toggle this feature with the '-expand ' option.
> Where 'l' means grow to the left, 'r' grow to the right and '-c'
> grow on both ends. ('-c' is not implemented yet)
>
> Please give it a try and report your experiences back.
>
>
> > Lobzang
>
> Bye, Rob.
>
>
Can we use the "embed window in another process' window" trick to embed all
kinds of plugins in the status bar (given the status program supports the
desired switches)? This will keep dwm clean of support code for specific
plugins. Plus, embedding a window will let dwm know its size dynamically.

_r

Re: [dwm] Urgency hook?

[Ritesh Kumar]

On Dec 19, 2007 2:45 PM, Jeremy O'Brien <[EMAIL PROTECTED]> wrote:

> On Tue, Dec 18, 2007 at 10:35:58PM -0800, Amit Uttamchandani wrote:
> > On Wed, 19 Dec 2007 00:59:56 -0500
> > "Jeremy O'Brien" <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Dec 18, 2007 at 09:32:11PM -0800, Ryan Zheng wrote:
> > > > Hi all,
> > > >
> > > > I've created a patch that handles the urgent hint for dwm 4.5. It
> > > > changes the color of the square. It's probably buggy, but it seems
> to
> > > > work.
> > > >
> > > > Ryan
> > > >
> > >
> > > Wow. A few minor tweaks and it works with 4.7. And it seems to work
> > > perfectly from here :) Thank you for this...
> > >
> >
> > Do you mind posting the modified patch for 4.7? ;)
> >
> > Thanks!
> >
>
> Hehe. My first patch ever! I emulated the author's style of modifying
> the config.h file over the config.def.h. The changes are easily spotted
> however. Here goes!
>

Wow, nice job for a first patch!
However, I really think you should use config.def.h for config changes. You
don't want a patch application to fail because somebody has a different
colorscheme in his config :)

I am using the patch right now... Since this is an integral wm feature and
not a wm-ui enhancement, I really think this is a good candidate for
inclusion in mainline dwm.

Ritesh


> --
> Jeremy O'Brien aka neutral_insomniac
> GPG key: 0xB1140FDB 
> http://pohl.ececs.uc.edu/~jeremy/jeremy.asc
> Linux ambelina 2.6.22.9 #1 Zilog(R) Z80
> processor 4MHz GNU/Linux
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHaXTuJUoJkLEUD9sRAphzAKCh8RdcLazWvm7CrpG2CL1+XTFtGACfWW/F
> xnfEV0MMfrMhRjQeOMPe6EY=
> =lMzj
> -END PGP SIGNATURE-
>
>

Re: [dwm] new feature proposal: cycle through specific windows

[Ritesh Kumar]

On Dec 19, 2007 2:29 AM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:

> On Wed, Dec 19, 2007 at 12:15:19AM +0100, Engin Tola wrote:
> >
> > I was thinking of a new feature to dwm where one can cycle through a
> > specific kind of window; like within open terminals only or like within
> > open emacs windows..
> >
> > I generally want to switch between xterms or open emacs windows without
> > cycling through all the different open windows.
> >
> > does anybody else think this as a useful feature ?
>
> See how tagging is intended to be used. To me it sounds exactly
> like what you propose as a feature.
>
> Regards,
>

I think Engin is asking about cycling between windows tagged with the same
tag when viewing a number of tags together... i.e. without changing which
tags are currently being viewed.

Ritesh

Re: [dwm] How to restart after re-compiling dwm without destroying of existing clients?

[Ritesh Kumar]

On Dec 13, 2007 3:17 PM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 13, 2007 at 09:39:24PM +0300, Taras Ivashchenko wrote:
> > Hello everybody, sorry if this question already was asked.
> >
> > Is there way or may be patch to restart after re-compiling dwm without
> destroying of existing clients?
> > Something like  restart feature in xmonad?
>
> while true
> do
>dwm
> done
>
> dwm restarts correctly on Mod-Shift-q within a while loop.
>

while true; do
date;
(anything else for the statusbar goes here too)
done | while true; do dwm; done

I generally use the above in a launcher script.

Ritesh

Re: [dwm] dwm new message notification

[Ritesh Kumar]

I think gmail supports RSS for getting unread mail. I clicked on the little
feed icon in my firefox urlbar and I got an RSS page. I guess a little grep
over that should do the trick. Do tell us if that works!

Ritesh

On Dec 11, 2007 1:05 PM, Jeremy O'Brien <[EMAIL PROTECTED]> wrote:

> On Tue, Dec 11, 2007 at 06:47:00PM +0100, Antoni Grzymala wrote:
> > Jeremy O'Brien dixit (2007-12-11, 12:37):
> >
> > > Haha. You gave me this script before, and it was the one that I was
> > > previously using. Worked like a charm! Unfortunately, IMAP works
> > > differently and doesn't populate my ~/.maildir directory anymore :(
> > > Thank you though! :)
> >
> > LOL, excuse my Alzheimer. Do you need to access Gmail via IMAP? I
> > fetchmail my mail the usual way with POP3. Obviously it does not
> > presever the mailbox layout in Gmail. Not really sure, what your needs
> > are.
> >
> > Best,
> >
> > --
> > [a]
>
> Heh, no problem. :) I am accessing Gmail just fine using mutt and IMAP.
> The problem I have now is finding a way to show the number of new
> emails in my status bar like your script did so wonderfully before.
> The solution that Martin Sander gave seemed adequate, but the script
> failed. I'm assuming it was a typo somewhere :( I would like to start
> using offlineimap too, as this seems to be the best of both worlds
> (offline mail reading + supercool synchronization), but my net
> connection at my house right now is crap, and downloading 500MB+ of
> email is out of the question. So for now I think I'll just rely on
> peeking at mutt every so often to see if I have no email. I can cope. :)
>
> --
> Jeremy O'Brien aka neutral_insomniac
> GPG key: 0xB1140FDB 
> http://pohl.ececs.uc.edu/~jeremy/jeremy.asc
> Linux ambelina 2.6.22.9 #1 Zilog(R) Z80
> processor 4MHz GNU/Linux
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHXtFtJUoJkLEUD9sRAhGJAJ9/wLHYinNV7dJsVc81PpyE2zj7xgCgh4sp
> xafLvQhi71rSCx1FbEzM/i0=
> =55kj
> -END PGP SIGNATURE-
>
>

Re: [dwm] maximize problem

[Ritesh Kumar]

On Dec 10, 2007 10:50 AM, pancake <[EMAIL PROTECTED]> wrote:

> > climit / clientspertag also has this problem. In case of climit, a
> climit of
> > 1 starts the monocle mode so things are better. However, for 1 < climit
> <
> > number of visible tiled clients, changing the focus can go to a client
> not
> > being shown (which is still useful to zoom on that client... but you
> need to
> > know that climit is activated).
>
> Are you from the past?
>
> Err sorry :)
>
> This was fixed a month ago in the latest nmaster-4.7 patch which includes
> the clientspertag feature without hiding the not visible clients stacking
> them in the bottom of the window.
>

Sorry... my bad. I remember your discussion with rfigura on this. Very neat
idea.

Ritesh

Re: [dwm] Xinerama support

[Ritesh Kumar]

On Dec 10, 2007 4:11 AM, Chris 'Ducky' Chapin <[EMAIL PROTECTED]> wrote:

>
> This is sort of what I've done. I run dwm at work with a 2 head xinerama
> setup, so added a side attribute to the client struct and added a
> function to toggle it. Then I just copied and adjusted the tile function
> to display 2 mains and 2 stacks mirrored. This what a coworker has
> dubbed the dumbbell layout: "[]==[]". =)
>
> -Ducky
>

I don't have a multi-head setup but I have used some at work. I think most
of the time I had a notion of a primary screen and a secondary screen. Given
that, I think it will be useful to designate one screen as the master screen
displaying only master windows (with adjustable number of columns, I think a
default of two is good) and the other screen as a stack screen with a
multiple columns (I think three will be a good default). The rest remains
the same except probably, restricting windows not to extend to the other
screen automatically.

Ritesh


> Maarten Maathuis wrote:
> > A shared tagging setup, but a flag to indicate primary or secondary
> head.
> > Sort of like adding an extra dimension to dwm.
> >
> > Maarten.
> >
> > On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
> >
> >> Hi there,
> >>
> >> could you imagine that there is a way that dwm could be used in
> >> a Xinerama environment and how that might look like?
> >> Regardless if that is necessary or not for mainstream dwm,
> >> I see the following possibilities:
> >>
> >> - aim multihead setup (distinct bars, tag sets and layouts for
> >> each screen)
> >>
> >> - extend tile() into tile2() and tile3(), where tile2 assumes
> >> one screen as master area (with the bar), and one screen as
> >> stacking area (note, setmwfact won't have any effect here), and
> >> tile3() would do similiar, but the third screen would be
> >> stacking area as well.
> >>
> >> Are there other ideas?
> >>
> >> Regards,
> >> --
> >>  Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
> >>
> >>
> >>
>
>

Re: [dwm] Window management ideas

[Ritesh Kumar]

On Dec 9, 2007 6:09 PM, Jonas Pfenniger <[EMAIL PROTECTED]> wrote:

> I like that DWM is minimalist. Actually I don't care about the LOC,
> but as a user, it's simple to use and doesn't get in my feets. Well,
> almost. Actually I have two griefs : terminal resizes and I often
> loose a window and must go trough the different "tags" until I find
> it.
>

I guess using mod 0 should get you back your window.  To know which tag the
window is in look out for a filled square above the numbers. Its kinda
obscure but the information is definitely out there. :)


> It's sad to say, but I think terminal will never be 100% flicker-free
> when resizing. There is no such thing as loosing line endings because
> you used Mod-0 instead of Mod-9. In the fact, I'd much prefer them to
> stay at 80char (or a multiple). It sounds weird to craft a special
> rule for xterm and it's brothers but text application are in another
> world than GUI apps.
>

I feel the same problem too. xterm is actually a bit better... it at least
preserves the bottommost lines. rxvt preserves lines on the top of the
window on resizing which leaves me clueless the moment I zoom back on the
window. Of course, both xterm and rxvt lose characters from right hand side
columns on a width shrink. Is there a reason why they don't lay out the text
again?


>
> Tagging windows is quite boring. From the WMII highly-customizable,
> now DWM has simplified to 1-9+www. Is there a reason ? I think giving
> names is hard and this part of the brain is also used while coding. I
> know that DWM must stay simple, but visual elements may be another
> good approach.
>
> This may sound a great departure from DWM but I think that using
> OpenGL composition would allow to resize the terminals easily while
> keeping the 80chars with. I could also provide good visual feedback
> for window ordering. Think of all the ways you could browse trough the
> windows. This has nothing to do with fancy 3D but all with providing
> powerful mechanisms.
>

OpenGL based shrinking of the window can very easily make fonts ugly or even
illegible. The answer lies in reflowing the text through the window. I have
no idea why xterm doesn't do it already (or may be it does with an option?).
Plus, given the tiling, there isn't a window order really to convey to the
user... Of course using compositing can enable some nice "quick view" modes
for all the windows. However, I am pretty sure that seasoned dwm users
prefer to memorize and use a work -> tag mapping instead of relying on
quickview for ease/speed of use reasons.

Plus, opengl based window managers (or any simultaneously running opengl
app) tends to hinder the performance of opengl games (big issue for me, BTW
any ut2004 players here?). This whole opengl based compositing thing remains
afloat precisely for supporting animations in window management. If you just
wanted a "quick view" without animations... opengl is actually *not* needed.
Mac OS X's quartz display architecture is way cleaner than OpenGL + X11.
That's the reason why they can effectively mix OpenGL apps with their window
management tricks. Window management is way too critical to put on something
like OpenGL + X11.

Ritesh

Re: [dwm] maximize problem

[Ritesh Kumar]

On Dec 9, 2007 5:13 AM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:

> On Sun, Dec 09, 2007 at 11:04:24AM +0100, pancake wrote:
> > I find quite anoying the maximize command. Because allows you to
> > hide windows to the user. I don't know if the right solution for this
> > would be to make maximize act as monocle, or avoid changing the
> > focus of the maximized client for the current tag, or making the
> > maximized flag be inheritable for the following created/switched
> > clients.
> >
> > You can achieve this problem by:
> >  - open two windows
> >  - maximize()
> >  - nextclient()
> >(focused client is hidden for the user)
>
> I noticed the same, but this only happens because floating
> clients are kept always on top, which is good -- and all other
> clients are tiled somehow.
>
> This would happen with any manually maximized floating as well,
> so I see no real good solution for this. What do others think?
>

I find this confusing too... so much that I actually disable this shortcut
in my config. I like the monocle suggestion... switching to the next client
returns the currently maximized client to its previous state (tiled or
floating+prev dimensions) and maximizes the next client. There is no harm
done this way as UI wise the process is completely reversible.

climit / clientspertag also has this problem. In case of climit, a climit of
1 starts the monocle mode so things are better. However, for 1 < climit <
number of visible tiled clients, changing the focus can go to a client not
being shown (which is still useful to zoom on that client... but you need to
know that climit is activated).

A lot of problems with coexisting floating + tiled windows can be easily
solved using a simple shortcut to just tile all the visible windows.

Ritesh

Re: [dwm] dwm wish, a tidy-up function

[Ritesh Kumar]

On Dec 6, 2007 10:07 AM, Ritesh Kumar <[EMAIL PROTECTED]> wrote:

> n Dec 6, 2007 5:23 AM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Dec 06, 2007 at 11:18:49AM +0100, Sander van Dijk wrote:
> > > On Dec 6, 2007 10:06 AM, Marc Andre Tanner <[EMAIL PROTECTED]> wrote:
> >
> > > > No. At least not in my opinion, please keep it simple & stupid.
> > > > Thanks for the excellent work.
> > >
> > > I agree. If anything, I think I'd prefer a .dwmrc.
> >
> > Ok, but the DWMTAGS idea is ok for everyone?
> >
>
> I am wondering how will that work if we have two windows from the same
> process. While keeping TAGS (and possibly floating state) in the environment
> can eliminate the need for regex based client matching, I still would like
> to segregate windows from the same process with different tags.
> I was wondering if X11 supports some kind of window metadata atom which
> the window manager could use to store some custom data? Dwm could just
> publish the tags for a window there and use it on a restart.
>
> Ritesh
>

http://tronche.com/gui/x/xlib/window-information/properties-and-atoms.html

A little search on google brought me to this site...

Ritesh

Re: [dwm] dwm wish, a tidy-up function

[Ritesh Kumar]

n Dec 6, 2007 5:23 AM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 06, 2007 at 11:18:49AM +0100, Sander van Dijk wrote:
> > On Dec 6, 2007 10:06 AM, Marc Andre Tanner <[EMAIL PROTECTED]> wrote:
> > > No. At least not in my opinion, please keep it simple & stupid.
> > > Thanks for the excellent work.
> >
> > I agree. If anything, I think I'd prefer a .dwmrc.
>
> Ok, but the DWMTAGS idea is ok for everyone?
>

I am wondering how will that work if we have two windows from the same
process. While keeping TAGS (and possibly floating state) in the environment
can eliminate the need for regex based client matching, I still would like
to segregate windows from the same process with different tags.
I was wondering if X11 supports some kind of window metadata atom which the
window manager could use to store some custom data? Dwm could just publish
the tags for a window there and use it on a restart.

Ritesh


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

Re: [dwm] dwm wish, a tidy-up function

[Ritesh Kumar]

On Dec 4, 2007 6:44 PM, Antoni Grzymala <[EMAIL PROTECTED]> wrote:

> Hi,
>
> just came across another idea. How about implementing a function in dwm
> that would reapply all the predefined rules (float/non-float, tagging)
> to all clients in a dwm session.
>
> This could either be a function bindable to a keystroke, or dwm reacting
> to a signal (say, HUP), or what not.
>
> This way, when I do a total mess with tagging and floating my clients
> (sometimes it happens and I get lost) I could get my everyday dwm state
> with one keystroke or command.
>
> What do you think?
>
> I presume this could also be achieved by restarting dwm, but this
> doesn't seem too clean to me, and also would not integrate well with a
> login manager (from what it seems).
>
> If something like that is already there, excuse my infinite dumbness for
> not noticing.
>
> Best,
>

I too get lost when I have floating and tiled windows in my view. I think a
shortcut to just tile everything  visible (without forgetting the tags) will
rescue me.
Infact what do you think about putting tags in the windows (associated
atoms?) themselves so that tags are preserved after a dwm restart?

Ritesh

[dwm] climit + enhanced monocle and modified grid layout patches

[Ritesh Kumar]

Hi again,
I have whipped a few patches against dwm4.7 too... They are all
available at http://www.cs.unc.edu/~ritesh/dwm/index.html
The climit is basically a twist to clientspertag. It shows the number of
hidden (due to climit) windows in the status bar. I find it really useful to
see if I have cpt enabled or not because I tend to forget that in the course
of my work :).
The enhanced (or scrolling) monocle kicks in when climit is set to one
(fullscreen) window. In that case, just changing focus changes the client
being shown.
 The above patch requires (quite a few) changes to (only) dwm.c.

 I have another grid layout patch which stretches out the first column
of the grid (which also contains the master window) if the number of grid
cells is higher than the number of windows to show. I haven't integrated it
with climit yet so it is useful separately. The patch is on dwm.c is
again... but its a single function which can be put in a separate file.

Ritesh

Re: [dwm] Screenshot suggestion for the wiki

[Ritesh Kumar]

On Nov 5, 2007 5:37 PM, Asbjørn Clemmensen <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 05, 2007 at 04:12:35PM +0100, Leonhard Scherer wrote:
> > Jeremy O'Brien wrote:
> > >On Mon, Nov 05, 2007 at 03:25:24PM +0100, markus schnalke wrote:
> > >
> > >>Think it would be nice to see dwm handling some utf8 characters in the
> > >>status line.
> > >>
> > >>
> > >>A user-based screenshot gallery wouldn't be bad either. To show the
> > >>different looks dwm can have.
> > >>Maybe just another wiki page?
> > >>
> > >>
> > >>meillo
> > >>
> > >>
> > >
> > >I like the user-gallery idea.
> > >
> > >
> > I also really like the idea, especially if there would be some
> "configuration-sharing" for dwm. Like this one could see how different color
> combinations look on the
> > desktop and thus give some inspiration to other users.
> >
>
> Perhaps adding the option to attach .Xdefaults/.Xresources along with
> .vimrc
> and whatever else might be relevant when discussing color themes.
>
> --
> Asbjørn
>
>
I definitely like the idea of a wiki showing dwm/shell/vim color schemes.
Also, a list of some cool scripts for status text will give a head start to
some of us who have just time being displayed there :).

_r

Re: [dwm] clientspertag status message

[Ritesh Kumar]

On 11/5/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
>
> On Mon, Nov 05, 2007 at 02:24:49PM +0100, Szabolcs Nagy wrote:
> > On 11/5/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
> > > No, if tile() would depend on the focus history you won't be
> > > able to ever focus something else, than the master client.
> >
> > yes and that's what we want in a fullscreen layout (the focused client
> > is always the maximized)
> >
> > are there any stack dependent tile() implementation?
> >
> > if there is then the solution could be:
> >  calc_focused();
> >  layout->arrange();
> >  adjust_stack();
> >
> > which is a bit ugly and increases complexity...
>
> Well, just use a stack-based tile() or monocle() implementation.


That's what we have right now... the  discussion is basically about  that
one line which repeats the "next focussed window finding algorithm after
view change" in focus(). Szabolcs (and myself) are basically making the case
that doing a focus() call before layout->arrange() doesn't change anything
for dwm but helps our new tile() to know about the selected window without
re-running dwm's focus history algorithm.
The question is basically about abstracting away 'stack' with just 'sel' for
tile() [Currently, sel is pretty much useless in tile()]. But I guess you
are right, let us expose the full focus history stack to tile() and let *it*
choose what is wants to query from it. We are basically making a case for an
uptodate 'sel' too in tile().

_r

Re: [dwm] clientspertag status message

[Ritesh Kumar]

On 11/2/07, Szabolcs Nagy <[EMAIL PROTECTED]> wrote:
>
> On 11/2/07, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
> > The monocle layout implementation would have been simpler if focus(NULL)
> was
> > called in arrange() *before* layout[].arrange(). That would have ensured
>
> > that sel was correctly updated before the layout routine did its task. I
> > would have been able to assume that sel == NULL => no windows to show in
> > this view.
> >
> > What do you say Arg? Can you reorder the operations in focus() so that
> > pancake and I don't have to replicate the "next selected window finding
> > algorithm" in the layout routine?
>
> note that focus changes client order so
>
> focus(NULL);
> layout->arrange();
>
> is slighly different from
>
> layout->arrange();
> focus(NULL);
>
>
> otherwise i agree, it's reasonable for arrange to know the focused window
>
>
This is something that has been troubling me for some time... focus changes
only the order of windows in the stack (the variable in dwm.c which keeps
focus history) right? However, layout[].arrange() only use clients or
nextclient(). How does using focus change the client order in the layout?

_r

Re: [dwm] 4.7 is delayed

[Ritesh Kumar]

I have a few comments...

Do you want to keep LENGTH(), seltags and prevtags in config.def.h? My
configuration doesn't need them and I doubt if somebody else's will.

I think now I understand your concern about my solution to the inputtext
behavior. What do we do if we read in a string which has '\n' or '\0' in the
middle instead of at the end? It won't happen with well behaved scripts, but
we are certainly not fool proof with my patch.

The lines in run() that this discussion is about:
default:
stext[offset + r] = '\0';
for(p = stext; *p && *p != '\n'; p++);
if(*p == '\n') {
*p = '\0';
offset = 0;
}
else
offset = (offset + r < len - 1) ?
offset + r : 0;

This is certainly cleaner than my solution :)
However, the lines above would keep the text till the read '\n' and
*discard* the rest of the text which was read in. Note that this will cause
the next iteration of read() to read in the partially available text and
display it from offset 0. Also, if it is terminated by a \n and a pause
follows then we have partial data showing for the pause duration in the
statusbar.
Now, we could try discarding the string *before* the middle \n. This means
that we will briefly display the partially available string and then
(hopefully in the next instant) read the rest of the string and display it.
That will cause flicker... again not so good.

I think the best option is to double buffer this thing. So while the input
is being read (till we encounter a \n), we keep displaying the old string.
So long as there is a pause between the read()ing of any two \n's we won't
have flicker or incomplete string display.

Here is my patch... The basic idea is to keep reading in a separate buffer
(buf). If a \n or \0 is read then take the front portion of buf (delimited
by \n or \0) and use it for stext and take the back portion of buf and use
it the new buf and offset.

Feedback is welcome :)

_r


diff -r 21aae6fc2bc5 dwm.c
--- a/dwm.c Mon Nov 05 02:55:33 2007 -0500
+++ b/dwm.c Mon Nov 05 04:27:54 2007 -0500
@@ -229,6 +229,12 @@ Regs *regs = NULL;
 /* configuration, allows nested code to access above variables */
 #include "config.h"

+/* convenience */
+#define LENGTH(x) (sizeof x / sizeof x[0])
+
+Bool seltags[LENGTH(tags)] = {[0] = True};
+Bool prevtags[LENGTH(tags)] = {[0] = True};
+
 /* function implementations */
 void
 applyrules(Client *c) {
@@ -1283,6 +1289,7 @@ run(void) {
int r, xfd;
unsigned int len, offset;
XEvent ev;
+   char buf[sizeof(stext)];

/* main event loop, also reads status text from stdin */
XSync(dpy, False);
@@ -1302,7 +1309,7 @@ run(void) {
eprint("select failed\n");
}
if(FD_ISSET(STDIN_FILENO, &rd)) {
-   switch((r = read(STDIN_FILENO, stext + offset, len -
offset))) {
+   switch((r = read(STDIN_FILENO, buf + offset, len -
offset))) {
case -1:
strncpy(stext, strerror(errno), len);
readin = False;
@@ -1312,14 +1319,18 @@ run(void) {
readin = False;
break;
default:
-   stext[offset + r] = '\0';
-   for(p = stext; *p && *p != '\n'; p++);
-   if(*p == '\n') {
-   *p = '\0';
-   offset = 0;
+   for(p = buf + offset; r>0 ; p++, r--,
offset++) {
+   if(*p == '\n' || *p == '\0'){
+   *p = '\0';
+   strncpy(stext, buf, len);
+   p += r - 1; // p is buf
+ offset + r - 1
+   for(r = 0; *(p-r) && *(p-r)
!= '\n'; r++);
+   offset = r;
+   if(r)
+   memmove(buf, p - r +
1, r);
+   break;
+   }
}
-   else
-   offset = (offset + r < len - 1) ?
offset + r : 0;
}
drawbar();
}

Re: [dwm] clientspertag status message

[Ritesh Kumar]

On 10/31/07, Szabolcs Nagy <[EMAIL PROTECTED]> wrote:
>
> On 11/1/07, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
> > Currently changing/toggling tags works correctly, however, the window in
> the
> > new view may or may not be focused :(. Any ideas?
>
> you can either raisefocused() or focus(nexttiled(clients)) depending
> on what client would you like to be active (sel or top)
>
>
> a possible raisefocused:
>
> void
> raisefocused(void) {
> XEvent ev;
> XWindowChanges wc;
>
> drawbar();
> if(!sel)
> return;
> if(sel->isfloating || !(ISTILE))
> XRaiseWindow(dpy, sel->win);
> else {
> wc.sibling = barwin;
> wc.stack_mode = Below;
> XConfigureWindow(dpy, sel->win, CWSibling |
> CWStackMode, &wc);
> }
> XSync(dpy, False);
> while(XCheckMaskEvent(dpy, EnterWindowMask, &ev));
> }
>
>
Thanks Szabolcs,

 I know very little about X programming so its hard for me to figure out
your suggestion. However, actually I needed something much simpler.
Dwm remembers your previously focussed windows. Changing view from one tag
to another makes sure that the focussed window on one tag is remembered when
we switch back to that tag. Now in the enhanced monocle layout, I was just
maximizing the selected client and banning the rest of the windows. The
problem was that when switching to a view in which the previously selected
client was not visible anymore, I had to find some visible client to
maximize again. I used nexttiled(clients) to find that client. Of course,
this client may not be the same as the client which the subsequent call to
focus(NULL) (in arrange()) would use for selection. The fix was rather
simple, instead of using nexttiled(clients), I used the same algorithm which
focus() uses to find the next client to select on a view change.
The monocle layout implementation would have been simpler if focus(NULL) was
called in arrange() *before* layout[].arrange(). That would have ensured
that sel was correctly updated before the layout routine did its task. I
would have been able to assume that sel == NULL => no windows to show in
this view.

What do you say Arg? Can you reorder the operations in focus() so that
pancake and I don't have to replicate the "next selected window finding
algorithm" in the layout routine?

Bottomline:
This now implies that that the enhanced monocle basically just always keeps
the currently selected client maximized. If the view is changed and a new
client is selected by dwm for selection, *that* is the window which is
maximized in the enhanced monocle layout.

The new patch (over pancake's nmaster/clientspertag) is here... it differs
in a single line from the patch given in my previous mail (but I am
including the entire patch here for easier comprehension).

What do you think pancake? Any suggestions? Can you include it in your next
patch revision?

diff -r 18756f3d803d config.h
--- a/config.h  Tue Oct 30 22:39:33 2007 -0400
+++ b/config.h  Wed Oct 31 15:08:00 2007 -0400
@@ -41,6 +41,20 @@ Layout layouts[] = {
 /* Status text */
 char* statusbar[] = { cptstext, inputtext };

+static void custom_focusnext(const char* a)
+{
+   focusnext(NULL);
+   if(cpt == 1)
+   arrange();
+}
+
+static void custom_focusprev(const char* a)
+{
+   focusprev(NULL);
+   if(cpt == 1)
+   arrange();
+}
+
 /* key definitions */
 #define MODKEY Mod1Mask
 #define KEYS \
@@ -54,8 +68,8 @@ Key keys[] = { \
{ MODKEY,   XK_s,   spawn, "exec
.dwm/audio_toggle.sh" }, \
{ MODKEY,   XK_space,   setlayout,  NULL
}, \
{ MODKEY,   XK_b,   togglebar,  NULL
}, \
-   { MODKEY,   XK_n,   focusnext,  NULL
}, \
-   { MODKEY,   XK_e,   focusprev,  NULL
}, \
+   { MODKEY,   XK_n,
custom_focusnext,   NULL }, \
+   { MODKEY,   XK_e,
custom_focusprev,   NULL }, \
{ MODKEY,   XK_h,   setmwfact,  "-
0.05" }, \
{ MODKEY,   XK_o,   setmwfact,
"+0.05" }, \
{ MODKEY,   XK_m,   togglemax,  NULL
}, \
diff -r 18756f3d803d nmaster.c
--- a/nmaster.c Tue Oct 30 22:39:33 2007 -0400
+++ b/nmaster.c Thu Nov 01 21:02:32 2007 -0400
@@ -96,12 +96,28 @@ void
 void
 ntile(void) {
unsigned int i, n, nx, ny, nw, nh, mw, mh, th;
-   Client *c;
+   Client *c, *t;

for(n = 0, c = nexttiled(clients); c; c = nexttiled(c->next))
n++;

n = getclientspertag(n);

Re: [dwm] clientspertag status message

[Ritesh Kumar]

On 10/31/07, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
>
> On 10/31/07, pancake <[EMAIL PROTECTED]> wrote:
> 
>
> > This still doesn't completely achieve the 'scolling through all windows'
> > > effect. Probably the easiest alternative (as you suggested) is to
> > zoom() on
> > > the focussed client automatically on focusnext() if cpt = 1... and
> > that
> > > would be a cool improvement to clientspertag. One way is to have a
> > > cptfocusnext doing the cpt related chores and calling the actual
> > focusnext
> > > appropriately. config.h handles binding Ctrl - j to cptfocusnext so
> > that's
> > > not a problem either. This solves the problem for clientspertag but
> > ofcourse
> > > is not general enough for a number of hooks (How about a config.c?
> > That
> > > could actually handle a lot of other problems too.).
> >
> > Uhm the zooming way is not ok at all because it modifies the clients
> > list
> > and breaks the focusnext()/focusprev(), so imho the right way to achieve
> > this is by having an index and a counter. Something like a moving window
> >
> > with
> >
> > Here's a sample:
> >
> >  Window (size = cpt)
> > =-Index-=> +--+
> > |  |
> > [ client0 ] [ client1 ] [ client2 ] [ client3 ]
> >
> > So, we should be able to change the starting index into the clients list
> > to start handling clients and keeping cpt as the size of our view for
> > the current tag.
> >
> > So, we can hook ^alt+j and ^alt+k to move this index with soemthing like
> >
> > cptidx++ or so.
> >
> > We can make cptidx=0 when entering in 'cpt' mode. And always make't fit
> > for all the clients on the current view.
> >
> > This way. dwm.c will remain as is, and we can 'handle' when focusing a
> > non-visible client (out of the window) and shifting right or left the
> > window.
> >
> > I think this way we can make cpt more consistent and functional, but
> > we also need the visible-clients indicator.
> >
> > Thanks for discussing the cpt stuff. I need some feedback to think on
> > some concepts and so..let see if we finally got the proper approach
> > for this patch.
> >
> > --pancake
> >
> >
> You are right, zoom will alter the order of the clients in the client
> list.
> I am wondering, do you want the window scrolling behavior if there are two
> or more windows? My guess is that this is useful only if cpt = 1. Also,
> instead of using a cptidx you could just use sel (the currently selected
> client). Actually, forgive my impatience... I gave it a shot and the
> scrolling monocle works with the following patch :). The main trick is
> somehow calling arrange on a focus change.
> Using sel instead of cptidx also means that when I deactivate cpt mode,
> the window I am currently viewing (in monocle) is now the focussed window in
> the tiled layout. I guess we can move custom_focus* to nmaster.c so that
> it is less of a hack.
> What do you think?
>
> _r


Okay, a little bug fix. Now changing tagviews does the right thing. (Earlier
it used to not display anything on a view change but used to show something
the moment custom_focusnext was called).
Currently changing/toggling tags works correctly, however, the window in the
new view may or may not be focused :(. Any ideas?

diff -r 18756f3d803d config.h
--- a/config.h  Tue Oct 30 22:39:33 2007 -0400
+++ b/config.h  Wed Oct 31 15:08:00 2007 -0400
@@ -41,6 +41,20 @@ Layout layouts[] = {
 /* Status text */
 char* statusbar[] = { cptstext, inputtext };

+static void custom_focusnext(const char* a)
+{
+   focusnext(NULL);
+   if(cpt == 1)
+   arrange();
+}
+
+static void custom_focusprev(const char* a)
+{
+   focusprev(NULL);
+   if(cpt == 1)
+   arrange();
+}
+
 /* key definitions */
 #define MODKEY Mod1Mask
 #define KEYS \
@@ -54,8 +68,8 @@ Key keys[] = { \
{ MODKEY,   XK_s,   spawn, "exec
.dwm/audio_toggle.sh" }, \
{ MODKEY,   XK_space,   setlayout,  NULL
}, \
{ MODKEY,   XK_b,   togglebar,  NULL
}, \
-   { MODKEY,   XK_n,   focusnext,  NULL
}, \
-   { MODKEY,   XK_e,   focusprev,  NULL
}, \
+   { MODKEY,   XK_n,
custom_focusnext,   NULL }, \
+   { MODKEY,   XK_e,
custom_focusprev,   NULL }, \
{ MODKEY,   

Re: [dwm] clientspertag status message

[Ritesh Kumar]

On 10/31/07, pancake <[EMAIL PROTECTED]> wrote:


> This still doesn't completely achieve the 'scolling through all windows'
> > effect. Probably the easiest alternative (as you suggested) is to zoom()
> on
> > the focussed client automatically on focusnext() if cpt = 1... and that
> > would be a cool improvement to clientspertag. One way is to have a
> > cptfocusnext doing the cpt related chores and calling the actual
> focusnext
> > appropriately. config.h handles binding Ctrl - j to cptfocusnext so
> that's
> > not a problem either. This solves the problem for clientspertag but
> ofcourse
> > is not general enough for a number of hooks (How about a config.c? That
> > could actually handle a lot of other problems too.).
>
> Uhm the zooming way is not ok at all because it modifies the clients list
> and breaks the focusnext()/focusprev(), so imho the right way to achieve
> this is by having an index and a counter. Something like a moving window
> with
>
> Here's a sample:
>
>  Window (size = cpt)
> =-Index-=> +--+
> |  |
> [ client0 ] [ client1 ] [ client2 ] [ client3 ]
>
> So, we should be able to change the starting index into the clients list
> to start handling clients and keeping cpt as the size of our view for
> the current tag.
>
> So, we can hook ^alt+j and ^alt+k to move this index with soemthing like
> cptidx++ or so.
>
> We can make cptidx=0 when entering in 'cpt' mode. And always make't fit
> for all the clients on the current view.
>
> This way. dwm.c will remain as is, and we can 'handle' when focusing a
> non-visible client (out of the window) and shifting right or left the
> window.
>
> I think this way we can make cpt more consistent and functional, but
> we also need the visible-clients indicator.
>
> Thanks for discussing the cpt stuff. I need some feedback to think on
> some concepts and so..let see if we finally got the proper approach
> for this patch.
>
> --pancake
>
>
You are right, zoom will alter the order of the clients in the client list.
I am wondering, do you want the window scrolling behavior if there are two
or more windows? My guess is that this is useful only if cpt = 1. Also,
instead of using a cptidx you could just use sel (the currently selected
client). Actually, forgive my impatience... I gave it a shot and the
scrolling monocle works with the following patch :). The main trick is
somehow calling arrange on a focus change.
Using sel instead of cptidx also means that when I deactivate cpt mode, the
window I am currently viewing (in monocle) is now the focussed window in the
tiled layout. I guess we can move custom_focus* to nmaster.c so that it is
less of a hack.
What do you think?

_r

diff -r 18756f3d803d config.h
--- a/config.h  Tue Oct 30 22:39:33 2007 -0400
+++ b/config.h  Wed Oct 31 15:08:00 2007 -0400
@@ -41,6 +41,20 @@ Layout layouts[] = {
 /* Status text */
 char* statusbar[] = { cptstext, inputtext };

+static void custom_focusnext(const char* a)
+{
+   focusnext(NULL);
+   if(cpt == 1)
+   arrange();
+}
+
+static void custom_focusprev(const char* a)
+{
+   focusprev(NULL);
+   if(cpt == 1)
+   arrange();
+}
+
 /* key definitions */
 #define MODKEY Mod1Mask
 #define KEYS \
@@ -54,8 +68,8 @@ Key keys[] = { \
{ MODKEY,   XK_s,   spawn, "exec
.dwm/audio_toggle.sh" }, \
{ MODKEY,   XK_space,   setlayout,  NULL
}, \
{ MODKEY,   XK_b,   togglebar,  NULL
}, \
-   { MODKEY,   XK_n,   focusnext,  NULL
}, \
-   { MODKEY,   XK_e,   focusprev,  NULL
}, \
+   { MODKEY,   XK_n,
custom_focusnext,   NULL }, \
+   { MODKEY,   XK_e,
custom_focusprev,   NULL }, \
{ MODKEY,   XK_h,   setmwfact,  "-
0.05" }, \
{ MODKEY,   XK_o,   setmwfact,
"+0.05" }, \
{ MODKEY,   XK_m,   togglemax,  NULL
}, \
diff -r 18756f3d803d nmaster.c
--- a/nmaster.c Tue Oct 30 22:39:33 2007 -0400
+++ b/nmaster.c Wed Oct 31 15:31:56 2007 -0400
@@ -103,6 +103,20 @@ ntile(void) {

n = getclientspertag(n);

+   if(cpt == 1) { // Scrolling monocle layout
+   for(c = nexttiled(clients); c; c = nexttiled(c->next)){
+   if(sel && c!=sel){
+   ban(c);
+   continue;
+   }
+   }
+   if(sel)
+   c = sel;
+   else
+   c = nexttiled(clients);
+   resize(c, wax, way, waw - 2*c->border, wah - 2*c->border,
False);
+   return;
+   }
/* window geoms */
mh = (n <= nmaster) ? wah / (n > 0 ? 

Re: [dwm] input status text bug?

[Ritesh Kumar]

On 10/31/07, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
>
> On 10/31/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
> >
> > Hi Ritesh,
>
>
> 
>
>
> > Well let's have a look at the relevant bits in the code:
> >
> > (a) switch(r = read(STDIN_FILENO, stext, sizeof stext - 1)) {
> > [...]
> > default:
> > (b) for(stext[r] = '\0', p = stext + strlen(stext) - 1; p >=
> > stext && *p == '\n'; *p-- = '\0');
> > (c) for(; p >= stext && *p != '\n'; --p);
> > (d) if(p > stext)
> > (e) strncpy(stext, p + 1, sizeof stext);
> > [...]
> >
> > (a) Reads the next bunch of stdin, beginning at stext[0] and
> > ending at stext[r].
> >
> > (b) 0-terminates stext, and trims rightmost '\n' from right to left
> > only.
> >
> > (c) If p still does not point to stext, it now seeks for a '\n'
> > character leftwards.
> >
> > (d) If during (c) such a '\n' character was found, it is the
> > begin of the last line which has been read.
> >
> > (e) Hence, we copy the last line read only to stext, beginning
> > at the '\n' character + 1 to stext. It is 0-terminated already.
> >
> > So in my eyes, assumed the complete output of the input script
> > is read, the code is correct and does what it is supposed
> > to do: it only displays the last line read from stdin (this might
> > be a bunch of data which is not '\n'-terminated yet during this read
> > round of course).
>
>
> The problem is that select will notify dwm the moment *anything* is
> available on stdin... and that could be partial data.
> There is one semantic difference between the code snippets. While the
> original one retains the last line of given multiline input, the suggested
> snippet shows the first line. However, its hard to think of a situation
> where somebody would pour in multiline text (all in a small amount of time)
> for the status as dwm would not be able to show all of it anyways regardless
> of the semantics.
>
> If you like to debug, you could add an
> >
> >   fprintf(stderr, "'stext == %s'\n", stext);
> >
> > in there between (c) and (d). Then we can make sure that your
> > guess is correct.
> >
> > If the input is not read during one read call as you believe,
> > then at least there must be some flashing, because dwm will
> > actually render the  at the status bar, but maybe
> > your system is really fast and you don't notice this.
>
>
> I will do this and post the results.
> You are right about my system... its really fast :). Actually, I did see a
> flash but it was merely a flicker and happened only sometimes.
>
> _r
>
> Okay, I tried the debug: the output with the previous code is
inputtext == 
inputtext == Wed Oct 31 14:46:32 EDT 2007
inputtext == 
inputtext == Wed Oct 31 14:46:33 EDT 2007
inputtext == 
inputtext == Wed Oct 31 14:46:34 EDT 2007
inputtext == 
inputtext == Wed Oct 31 14:46:35 EDT 2007
inputtext == 
inputtext == Wed Oct 31 14:46:36 EDT 2007

So, read() is really not reading all of the 'intended text to be read' in
one go.

_r

Re: [dwm] input status text bug?

[Ritesh Kumar]

On 10/31/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
>
> Hi Ritesh,





> Well let's have a look at the relevant bits in the code:
>
> (a) switch(r = read(STDIN_FILENO, stext, sizeof stext - 1)) {
> [...]
> default:
> (b) for(stext[r] = '\0', p = stext + strlen(stext) - 1; p >=
> stext && *p == '\n'; *p-- = '\0');
> (c) for(; p >= stext && *p != '\n'; --p);
> (d) if(p > stext)
> (e) strncpy(stext, p + 1, sizeof stext);
> [...]
>
> (a) Reads the next bunch of stdin, beginning at stext[0] and
> ending at stext[r].
>
> (b) 0-terminates stext, and trims rightmost '\n' from right to left only.
>
> (c) If p still does not point to stext, it now seeks for a '\n'
> character leftwards.
>
> (d) If during (c) such a '\n' character was found, it is the
> begin of the last line which has been read.
>
> (e) Hence, we copy the last line read only to stext, beginning
> at the '\n' character + 1 to stext. It is 0-terminated already.
>
> So in my eyes, assumed the complete output of the input script
> is read, the code is correct and does what it is supposed
> to do: it only displays the last line read from stdin (this might
> be a bunch of data which is not '\n'-terminated yet during this read
> round of course).


The problem is that select will notify dwm the moment *anything* is
available on stdin... and that could be partial data.
There is one semantic difference between the code snippets. While the
original one retains the last line of given multiline input, the suggested
snippet shows the first line. However, its hard to think of a situation
where somebody would pour in multiline text (all in a small amount of time)
for the status as dwm would not be able to show all of it anyways regardless
of the semantics.

If you like to debug, you could add an
>
>   fprintf(stderr, "'stext == %s'\n", stext);
>
> in there between (c) and (d). Then we can make sure that your
> guess is correct.
>
> If the input is not read during one read call as you believe,
> then at least there must be some flashing, because dwm will
> actually render the  at the status bar, but maybe
> your system is really fast and you don't notice this.


I will do this and post the results.
You are right about my system... its really fast :). Actually, I did see a
flash but it was merely a flicker and happened only sometimes.

_r

Re: [dwm] input status text bug?

[Ritesh Kumar]

On 10/31/07, Sander van Dijk <[EMAIL PROTECTED]> wrote:
>
> On Oct 31, 2007 7:01 AM, Vasil Dimov <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 30, 2007 at 23:04:33 -0400, Ritesh Kumar wrote:
> > [...]
> > > I went through the source code and fixed the status input handling
> code to
> > > make sure it flushes the input status text only if in encounters a
> '\n'.
> > [...]
> > > if(FD_ISSET(STDIN_FILENO, &rd)) {
> > > -   switch(r = read(STDIN_FILENO, inputtext,
> sizeof inputtext - 1)) {
> > > +   pos = inputtext[strlen(inputtext)-1] != '\n' ?
> strlen(inputtext) : 0;
> > > +   switch(r = read(STDIN_FILENO,
> &(inputtext[pos]), sizeof inputtext - 1 - pos)) {
> > [...]
> >
> > Hmmz, aren't you trying to calculate strlen() of something undefined
> > here?
>
> And also, when inputtext[0] = '\0', where does
> inputtext[strlen(inputtext)-1] point to?


Nice catch! Actually, I didn't think of this when I first developed the
patch.
However, the read() call always returns atleast one char in inputtext for
the default switch case. So, we are always bound to have strlen(inputtext) >
1 for all cases.
But I guess its better to be safe and put a check in for strlen(inputtext)
while calculating pos.

_r

Re: [dwm] input status text bug?

[Ritesh Kumar]

The full patch (against dwm 4.6 + clientspertag) is present at
http://www.cs.unc.edu/~ritesh/dwm/index.html
It should not be difficult to chop out unwanted bits from it :)

_r

On 10/30/07, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
>
> Hi folks,
> I came across this curious behavior for the input status text...
>
> 

[dwm] input status text bug?

[Ritesh Kumar]

Hi folks,
I came across this curious behavior for the input status text...

I used to run dwm using the following bash script:

while true; do
date;
sleep 1;
done | dwm

... and things used to run fine :).

I changed it to:

while true; do
cat $HOME/.dwm/status_* ;
date;
sleep 1;
done | dwm

The status_* files contain text without trailing \n's.
Surprisingly , the contents of the statusbar didn't change (only date, no
other status text) ... even though the while loop outputs something like
 Tue Oct 30 22:46:56 EDT 2007
 Tue Oct 30 22:46:57 EDT 2007
 Tue Oct 30 22:46:58 EDT 2007
...

My guess is that read() reads the status_* text and date in two successive
calls causing the date to prevail till sleep 1 is done.

I went through the source code and fixed the status input handling code to
make sure it flushes the input status text only if in encounters a '\n'. The
patch is given... unfortunately it is over my (recently posted) status text
patch. I moved the trimming of trailing \n's to another function  setstext()
(introduced by my status text patch)... however, the relevant code can be
moved to the function run().

What do you guys think... did I accidentally break something?

_r

diff -r a5b57a189379 dwm.c
--- a/dwm.c Tue Oct 30 22:17:27 2007 -0400
+++ b/dwm.c Tue Oct 30 22:31:24 2007 -0400
@@ -1295,8 +1295,7 @@ restack(void) {

 void
 run(void) {
-   char *p;
-   int r, xfd;
+   int r, pos, xfd;
fd_set rd;
XEvent ev;

@@ -1315,7 +1314,8 @@ run(void) {
eprint("select failed\n");
}
if(FD_ISSET(STDIN_FILENO, &rd)) {
-   switch(r = read(STDIN_FILENO, inputtext, sizeof
inputtext - 1)) {
+   pos = inputtext[strlen(inputtext)-1] != '\n' ?
strlen(inputtext) : 0;
+   switch(r = read(STDIN_FILENO, &(inputtext[pos]),
sizeof inputtext - 1 - pos)) {
case -1:
strncpy(inputtext, strerror(errno), sizeof
inputtext - 1);
inputtext[sizeof inputtext - 1] = '\0';
@@ -1326,10 +1326,7 @@ run(void) {
readin = False;
break;
default:
-   for(inputtext[r] = '\0', p = inputtext +
strlen(inputtext) - 1; p >= inputtext && *p == '\n'; *p-- = '\0');
-   for(; p >= inputtext && *p != '\n'; --p);
-   if(p > inputtext)
-   strncpy(inputtext, p + 1, sizeof
inputtext);
+   inputtext[pos+r] = '\0' ;
}
drawbar();
}
@@ -1426,6 +1423,9 @@ setstext(void) {
stext[0] = '\0';
for(i=0; i

Re: [dwm] clientspertag status message

[Ritesh Kumar]

Hi pancake,
Thanks for reviewing the patch. :)
I understand your concern about not having to change dwm.c. I had
initially thought about a way to do it using the conventional stdin
statusbar. But, is seemed a little roundabout to take a string in the same
process out of it and then bring it back in using stdin... but I guess
that's just my feeling. There are also some other problems using a fifo.
- the fifo needs to be unique for every concurrently running dwm session. I
however have only one screen... so not exactly my problem :)
- writing to a fifo would block dwm in the printf. Worst yet, a little
mis-scriping at the statusbar end can cause a hung dwm.
- it will be hard for multiple extensions/patches to send data to the same
fifo. I guess some bash scripting and grepping at the stdin-statusbar end
could to away this problem at the cost of a slight inconvenience.
That's why I wanted to solicit some feedback regarding a status text
configuration thing in dwm.c/config.h which could be used by other
extensions.

I really like your idea about tagging the rest of the windows (after a
clientspertag operation) a separate tag. It goes well with dwm's tagging
paradigm too. Since the presence of a window with a tag is shown by dwm in
the left statusbar, it gets rid of my whether-or-not-cpt-is-active dilemma
too. However, activating cpt when seeing one tag and deactivating it when
seeing another can cause all the windows in the 'rest of clients' tag to be
tagged with the new tag. Also, if we are currently viewing a set of tags
then it is not easy to say what tags to assign to the 'rest of clients' when
deactivating cpt. Life doesn't seem to be all rosy with the tagging paradigm
here ;).

 About the enhanced monocle layout replacement, I can actually do the
following without problems:
 (Lets say I have two windows on a tag).
 Activate cpt=1. [Now the window in the master tag is full screen, The
number of hidden windows is shown in the status bar].
 Ctrl - j shifts focus to the hidden window. Visually, the red border
from the full screen is removed.
 Ctrl -  zooms on the newly focussed window.

This still doesn't completely achieve the 'scolling through all windows'
effect. Probably the easiest alternative (as you suggested) is to zoom() on
the focussed client automatically on focusnext() if cpt = 1... and that
would be a cool improvement to clientspertag. One way is to have a
cptfocusnext doing the cpt related chores and calling the actual focusnext
appropriately. config.h handles binding Ctrl - j to cptfocusnext so that's
not a problem either. This solves the problem for clientspertag but ofcourse
is not general enough for a number of hooks (How about a config.c? That
could actually handle a lot of other problems too.).

Regards,
_r

P.S. thanks for putting the patch on the wiki.

On 10/27/07, pancake <[EMAIL PROTECTED]> wrote:
> Hi Ritesh!
>
> Welcome to the mailing list.
>
> Thanks for the patch, but I would like to discuss it before merging
> it to my patch because I don't want to make cpt modify dwm.c.
>
> I think stdout of dwm is probably a missunderstood friend.
> We can change all this patch by just adding a printf("%d/%d,cpt,n)
> and piping the stdout of dwm to a fifo reading it from stdin
> to show this value in the statusbar.
>
> cpt is very useful for me. I use it so many times and I understand
> that it can be replaced by making visible/hidden another tag with
> the 'rest of clients'. for example
>
>   * have two clients on tag 1 and one in tag 2
>   * press control+meta+2 twice
>
> This take more sense with the tagging concept and imho, this is the
> reason why cpt is not in dwm core.
>
> But I feel more confortable with cpt (mostly because I lets me decide
> how many clients I want to see instead of keeping sense contents on
> each tag and remember what tag contains.
>
> The other reason I find cpt useful is for using it as a enhaced
> monocle layout replacement. If we found a way to always show the
> focused window at the first position of the list we can have
> a 'scrolleable' view of a tag reducing the view to N clients per
> tag, but making the focused client always visible.
>
> I tried to do this patch but I was unable to find a proper way
> without using zoom(NULL) or without modifying dwm.c, coz there's
> no way to hook a callback to focusnext() and focusprev().
>
> What do you think about this concept?
>
>
>
> On Fri, 26 Oct 2007 05:32:32 -0400
> "Ritesh Kumar" <[EMAIL PROTECTED]> wrote:
>
> > Okay,  I revisited the patch and made some improvements.
> >  - variable names should be saner.
> >  - the status bar now shows the number of windows hidden instead

Re: [dwm] clientspertag status message

[Ritesh Kumar]

Okay,  I revisited the patch and made some improvements.
 - variable names should be saner.
 - the status bar now shows the number of windows hidden instead of
the actual cpt value.

_r

diff -r 32c4d4563805 config.h
--- a/config.h  Thu Oct 25 19:24:28 2007 -0400
+++ b/config.h  Fri Oct 26 05:08:55 2007 -0400
@@ -37,6 +37,9 @@ Layout layouts[] = {
{ "[]=",tile },
{ "><>",floating },
 };
+
+/* Status text */
+char* statusbar[] = { cptstext, inputtext };

 /* key definitions */
 #define MODKEY Mod1Mask
diff -r 32c4d4563805 dwm.c
--- a/dwm.c Thu Oct 25 19:24:28 2007 -0400
+++ b/dwm.c Fri Oct 26 05:22:22 2007 -0400
@@ -167,6 +167,7 @@ void setclientstate(Client *c, long stat
 void setclientstate(Client *c, long state);
 void setlayout(const char *arg);
 void setmwfact(const char *arg);
+void setstext(void);
 void setup(void);
 void spawn(const char *arg);
 void tag(const char *arg);
@@ -192,7 +193,8 @@ void zoom(const char *arg);
 void zoom(const char *arg);

 /* variables */
-char stext[256];
+char inputtext[256];
+char stext[512];
 double mwfact;
 int screen, sx, sy, sw, sh, wax, way, waw, wah;
 int (*xerrorxlib)(Display *, XErrorEvent *);
@@ -551,6 +553,7 @@ drawbar(void) {
dc.w = blw;
drawtext(layouts[ltidx].symbol, dc.norm);
x = dc.x + dc.w;
+   setstext();
dc.w = textw(stext);
dc.x = sw - dc.w;
if(dc.x < x) {
@@ -1312,21 +1315,21 @@ run(void) {
eprint("select failed\n");
}
if(FD_ISSET(STDIN_FILENO, &rd)) {
-   switch(r = read(STDIN_FILENO, stext, sizeof
stext - 1)) {
+   switch(r = read(STDIN_FILENO, inputtext,
sizeof inputtext - 1)) {
case -1:
-   strncpy(stext, strerror(errno), sizeof
stext - 1);
-   stext[sizeof stext - 1] = '\0';
+   strncpy(inputtext, strerror(errno),
sizeof inputtext - 1);
+   inputtext[sizeof inputtext - 1] = '\0';
readin = False;
break;
case 0:
-   strncpy(stext, "EOF", 4);
+   strncpy(inputtext, "EOF", 4);
readin = False;
break;
default:
-   for(stext[r] = '\0', p = stext +
strlen(stext) - 1; p >= stext && *p == '\n'; *
-   for(; p >= stext && *p != '\n'; --p);
-   if(p > stext)
-   strncpy(stext, p + 1, sizeof stext);
+   for(inputtext[r] = '\0', p = inputtext
+ strlen(inputtext) - 1; p >= inputtext
+   for(; p >= inputtext && *p != '\n'; --p);
+   if(p > inputtext)
+   strncpy(inputtext, p + 1,
sizeof inputtext);
}
drawbar();
}
@@ -1418,6 +1421,14 @@ setmwfact(const char *arg) {
 }

 void
+setstext(void) {
+   int i;
+   stext[0] = '\0';
+   for(i=0; icpt){
+   snprintf(cptstext, 8, "{%d} ", n-cpt);
+   return cpt;
+   }
+
+   cptstext[0] = '\0';
+   drawbar();
+   return n;
+}
+
 #ifdef NMASTER
 int nmaster = NMASTER;
 void
@@ -87,7 +101,7 @@ ntile(void) {
for(n = 0, c = nexttiled(clients); c; c = nexttiled(c->next))
n++;

-   if (cpt!=-1 && n>cpt) n = cpt;
+   n = getclientspertag(n);

/* window geoms */
mh = (n <= nmaster) ? wah / (n > 0 ? n : 1) : wah / nmaster;
@@ -136,7 +150,7 @@ dntile(void) {

for(n = 0, c = nexttiled(clients); c; c = nexttiled(c->next))
n++;
-   if (cpt!=-1 && n>cpt) n = cpt;
+   n = getclientspertag(n);

/* dynamic nmaster */
if (n<5) inc = 0;
@@ -266,7 +280,7 @@ tilecols(void) {
else
rows = nrows;

-   if (cpt!=-1 && n>cpt) n = cpt;
+   n = getclientspertag(n);

/* window geoms */
mh = (n <= nmaster) ? wah / (n > 0 ? n : 1) : wah / nmaster;


On 10/25/07, Ritesh Kumar <[EMAIL PROTECTED]> wrote:
> Hi,
> I am new to the list, so hi again :)
> I developed a small patch for dwm with pancake's clientspertag to
> show if clientspertag is active. This basically adds additional status
> text of the form '{n}' to the current status text where n is the
> number of clientspertag currentl

[dwm] clientspertag status message

[Ritesh Kumar]

Hi,
I am new to the list, so hi again :)
I developed a small patch for dwm with pancake's clientspertag to
show if clientspertag is active. This basically adds additional status
text of the form '{n}' to the current status text where n is the
number of clientspertag currently active.
However, I think a flexible way to show status messages could be
used by additional patches to show some textual data on the dwm status
bar. clientspertag seemed like a good candidate but I don't know about
any others. I was curious to know what you guys think.
 And thanks for developing dwm... its truly wonderful :)

_r


diff -r 32c4d4563805 config.h
--- a/config.h  Thu Oct 25 19:24:28 2007 -0400
+++ b/config.h  Thu Oct 25 20:28:00 2007 -0400
@@ -37,6 +37,9 @@ Layout layouts[] = {
{ "[]=",tile },
{ "><>",floating },
 };
+
+/* Status text */
+char* status_text[] = { cpt_stext, stext };

 /* key definitions */
 #define MODKEY Mod1Mask
diff -r 32c4d4563805 dwm.c
--- a/dwm.c Thu Oct 25 19:24:28 2007 -0400
+++ b/dwm.c Thu Oct 25 22:36:55 2007 -0400
@@ -167,6 +167,7 @@ void setclientstate(Client *c, long stat
 void setclientstate(Client *c, long state);
 void setlayout(const char *arg);
 void setmwfact(const char *arg);
+void setitext(void);
 void setup(void);
 void spawn(const char *arg);
 void tag(const char *arg);
@@ -193,6 +194,7 @@ void zoom(const char *arg);

 /* variables */
 char stext[256];
+char itext[512];
 double mwfact;
 int screen, sx, sy, sw, sh, wax, way, waw, wah;
 int (*xerrorxlib)(Display *, XErrorEvent *);
@@ -551,13 +553,14 @@ drawbar(void) {
dc.w = blw;
drawtext(layouts[ltidx].symbol, dc.norm);
x = dc.x + dc.w;
-   dc.w = textw(stext);
+   setitext();
+   dc.w = textw(itext);
dc.x = sw - dc.w;
if(dc.x < x) {
dc.x = x;
dc.w = sw - x;
}
-   drawtext(stext, dc.norm);
+   drawtext(itext, dc.norm);
if((dc.w = dc.x - x) > bh) {
dc.x = x;
if(sel) {
@@ -1418,6 +1421,14 @@ setmwfact(const char *arg) {
 }

 void
+setitext(void) {
+   int i;
+   itext[0] = '\0';
+   for(i=0; i