Re: [dev] number of visible windows?
On Fri, Jul 10, 2009 at 01:30:50AM +, Jacob Todd wrote: > Another odd thing I noticed today is that vanilla-dwm changes all of tags > layouts if you change the layout on a tag. Seems odd. That would be because you aren't changing the layout on a tag. Tags don't have layouts; you are changing the layout of dwm. Some of us don't think of tags as distinct workspaces. When I have more than one tag active at a time, then that's one "workspace" that I've temporarily built out of that combination, not several workspaces coexisting on one screen. >From this perspective, assigning the layout to dwm makes a lot more sense than assigning a layout to each tag.
Re: [dev] [dwm] number of tag limited?
On Thu, Aug 05, 2010 at 10:50:13PM +0200, thuban wrote: > However, I'm surprised that this is not the default use of dwm. It is > supposed to be suckless, and on my own, I think having "opened tags" > that are useless (meaning with no window inside) sucks at least a > little. Except that open empty tags aren't really a 'thing', or at least not as much of one as you seem to think. Tags are bit positions of an unsigned int that can be set/unset on each client and on each monitor. I hope that you're not proposing that a bit position shouldn't exist when nothing has it set. Those labels without any boxes on them are maybe wasting a bit of status bar real estate (but not enough that I ever notice) and maybe arguably the space to store the string but little else that can be helped short of using a smaller datatype for your bit array if that's really bugging you. In summary: unless your primary concern is how much stuff gets printed to the status bar, your problem seems to have a lot more to do with perception than with how dwm actually works.
Re: [dev] [dwm] number of tag limited?
On Fri, Aug 06, 2010 at 08:35:32AM -0400, Donald Allen wrote: > I think you are putting the cart before the horse. How tags are > represented internally is an implementation detail. The first concern > should be the actual behavior of dwm, because that is the software's > primary goal. How it accomplishes that behavior internally is a > consequence of design decisions about behavior, not the other way > around. Bear in mind that I was quoting what I read as a claim that dwm's implementation of tagging isn't as suckless as it should be. Taken in context with the concerns about "creating" and "destroying" tags, I interpreted that as a concern over the wastefulness of unnecessary infrastructure. My point in describing the implementation is that tagging in dwm has so little infrastructure behind it that there's none to be wasted. Tags in dwm aren't 'things' in the same way that they are in wmii (from what I recall of using wmii ages ago). They aren't specifically intended to be workspaces; they're states for controlling which windows happen to be visible at any given moment. This is why displaying more than one tag at the same time isn't a confusing mess. Not understanding this leads people to ask why pertag's functionality isn't in dwm by default. And this is why the problem of how 'to create the tag just when you move in' and to 'automatically remove them when they are no more used' is a figment of imagination. You can't actually solve it in dwm unless you implement the problem first, by reimplementing dwm's current tagging behaviour in a more sucking way or by implementing a different tagging behaviour where the problem makes any sense. You can trick yourself into thinking that it's the problem that you've solved by not displaying the label for unused tags, but what you'd have actually done is change the visual indicators for exactly the same behaviour as before. > I think Simon Parent's message, particularly the second paragraph, > discusses the real issue at hand, the user-interface implications of > displaying empty tags or not. To me, asking about how to manage the 'creation' and 'destruction' of tags implies a request concerning more than a different interface. Choosing not to display empty tags doesn't give any less of an impression that tagging creates something instead of just toggling a state. If anything, it reinforces the misconception. It's not really the interface at issue so much as the baggage carried along from one wm colouring how one interprets another.
Re: [dev] [dwm] number of tag limited?
On Fri, Aug 06, 2010 at 05:18:47PM +0200, thuban wrote: > but we can't minimize clients if we have too much opened... So how can I use > correctly clients in an overcrowded screen? Well, the main client will always have the full screen height so in principle it should always be usable and the monocle layout will give it the full screen width if that's still an issue. You might also find monocle handy for cycling through clients on an overcrowded screen if their titles don't give you enough information to know what you have selected. For having more than one client accessible at once ... fibonacci patch might help you deal with 2 or 3 on a crowded screen but mostly the answer is to plan ahead enough that you aren't overcrowding the screen and needing more than one client at the same time. There are limits to how much dwm can compensate for bad usage patterns.
Re: [dev] [patch] add Control-G and Control-D to dmenu
On Mon, Aug 09, 2010 at 12:07:11PM +0100, Connor Lane Smith wrote: > ^D isn't an emacsism insofar as using it in bash when not at the end > of the line works the same way. That said, I'm aware bash is a > monster. However: Actually, it is an emacsism insomuch as bash's manpage specifically describes the default line editing commands as emacs-style, in contrast to a vi-style that can be enabled in its place.
Re: [dev] Re: dwm puzzle [fixed; with blame]
On Sat, Sep 11, 2010 at 03:23:18PM -0400, Peter John Hartman wrote: > On Sat, Sep 11, 2010 at 01:35:10PM -0400, Peter John Hartman wrote: > > But now, after the upgrade, both firefox and open office behave like > > elitists: not only do they not tile in tile mode (they sit on top) they > > don't allow me to do focusstack either to flip to other things under the > > stack. Hence, MODKEY t, m, and the j and k don't work. I can make > > firefox behave if I hit F11 (oddly enough), but nothing I can do can get > > open office to behave. > > > > I have no Rules in my Rules section of config.h and I verified that this > > is the same even with a vanilla config.def.h as my config.h. Suggestions? > > ... > > In any case, that fixes the bug and now openoffice and firefox behave. > > Thoughts? Peter > I don't have any comments on the focus problems, but I find that openoffice actually ignores having isfloating set to false in my rules. I'm guessing that its insistence on not tiling is a side-effect of how manage() handles windows initialized with fullscreen dimensions: by making them floating, no-border clients AFTER calling applyrules(). I just deal with this by using MODKEY+shift+space to toggle isfloating on the client.
Re: [dev] Re: dwm puzzle [fixed; with blame]
On Sat, Sep 11, 2010 at 04:44:12PM -0400, Peter John Hartman wrote: > > I should have said in my original report that the MODKEY+shift+space > solution is the way I dealt with these problems; I had suspected that > the isfloating rule is being ignored in such cases, but when we ran > 5.8.2 it worked just fine; perhaps you have the same bug I do. Try > the latest hg tip. > > Peter > Before my previous post I tested with hg tip and didn't hit your bug. Then I realized that hg tip includes the change that fixed it for you, so now I've retested with one before hg tip and I'm still not getting your bug. I was able to open a terminal, then open openoffice (which goes floating fullscreen, hiding the terminal), focus the terminal using MODKEY+j (still hidden behind openoffice), and successfully run a command in the terminal. From my understanding of your report, you were not able to do this. It looks like we just have the auto-floating in common, which at least has a reasonable explanation for why dwm is doing it (whether or not it should is a different can of worms). The focus problem could very well be specific to certain compiler versions. gcc version 4.3.2 (Debian 4.3.2-1.1)
Re: [dev] [dwm] Fedora package
On Tue, Oct 19, 2010 at 05:02:02PM +0200, Moritz Wilhelmy wrote: > Petr, as most users also need to patch dwm.c to make dwm fit their needs, this > seems pointless to me... maybe you should also respect dwm.c if it's put in > ~/.dwm? > that way, one can also just extract the mainline tarball or clone the hg repo > in > ~/.dwm and perform local modifications. I think it's the sanest way to package > dwm (if at all) If a user is modifying dwm.c, I think that they've crossed the threshold where relying on a package manager for dwm has ceased to make any sense at all. A precompiled default version of dwm to give prospective users a sample of what it's like? Makes sense. Helping to compile in changes from a custom config.h? Eh, sure - encouraging people to treat it like a runtime config file is kind of bad but not all that terrible. But once they're fiddling with dwm.c what's the point in holding their hand? The next step to running make themselves is laughably small.
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
On Thu, Nov 11, 2010 at 02:40:54PM -0500, Peter John Hartman wrote: > I've made this request before, and always get yelled at, but it would be > nice if dmenu had a config.h file which allowed one to override the default > keybindings, set a default color/font, and so on and so forth. > > Peter Uh ... dmenu does have a config.h file. If all of your dmenu scripts use the same colour and font overrides you can easily save yourself the trouble by changing the default colours and font - which is what I wound up doing over a year ago, probably closer to two.
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
On Thu, Nov 11, 2010 at 10:31:44PM +, Connor Lane Smith wrote: > Not in tip. My argument is, if you want to configure defaults just add > an override dmenu script to your path: > > > #!/bin/sh > > /usr/local/bin/dmenu -fn ... -bg ... > > Easier than recompiling imo, and means everyone on a multiuser system > can share a single binary. > > cls Apparently I've gone long enough between pulls to not have seen that change (and your previous mention failed to register). As for "easier than recompiling", my ratio of "recompiles because I decided to change my color scheme" to "recompiles because of a new release or interest in checking out tip" is small enough that I'm confused as to how easiness comes in. It's not as though compiled defaults and interposing a script are incompatible on a multiuser system. Meh, I can't really think of a particularly compelling reason to put config.h back in, but from the perspective of someone who was using it, its removal feels strange and arbitrary and a bit like someone insisting that I get out of bed at some early hour on a weekend.
Re: [dev] [dwm] floating window if fullscreen
On Tue, Jan 25, 2011 at 01:14:17AM +, Nick wrote: > I like using fullscreen mplayer, and being able to switch between > different windows in monocle mode. However, if mplayer is set to > fullscreen (-fs), when I use the next/previous window key commands, > mplayer stays shown (though the keyboard focus does move). I don't > know if this is due to the mplayer window deciding it should float > (there are no such rules set up in my config.h). If I set no > fullscreen (-nofs) the problem disappears, providing the dimensions > of the window are less than my screen, otherwise the same thing > happens. > > I could set nofullscreen and x & y to a few pixels less than my > screen size in the mplayer config, but that is a little unclean, and > I'd really like to understand what's going on. Basically, when a client is first created dwm checks to see if its dimensions are the same as that of the monitor it's on. If so then the window is set to floating. This logic appears after applying any rules, a rule explicitly setting the window to be non-floating will be overriden by this behaviour. (I'm presuming that this is in order to respect fullscreen programs even when in a different layout.) If you have no use for this, then you can always remove it from your version (look in the function manage).
Re: [dev] DWM equivalent of wihack?
On Wed, Dec 07, 2011 at 06:46:13PM -0800, Suraj N. Kurapati wrote: > I want to launch a terminal with EWMH window type "dialog" so that it > opens in the floating layer but I don't want to add a rule to put *all* > terminals in the floating layer. In wmii, I would use the wihack tool > to accomplish this. How could I achieve this in DWM? > > In particular, I'm trying to launch top(1) in a terminal when I click a > region that shows the current system load average in my dzen2 statusbar. If you launch it as "xterm -e top" then the window's title will be "top" at launch and you can match against title "top" instead of (or in addition to if you really wanted to for some reason) class "xterm" in your rules.
Re: [dev] [dwm] Tags vs Monitors
On Thu, Jan 12, 2012 at 04:16:37PM +0100, Thomas Dean wrote: > But with two monitors, I constantly find myself moving windows between the > two, and searching for windows that I "lost" because I put them on the other > monitor, which makes them lose their previously assigned tags. You might find it helpful to go into sendmon and delete that one line that resets the window's tags to whatever's currently visible on the other monitor. That was pretty much the first thing I did when multihead support was added, since I rarely want to both move a window between monitors and retag it.
