Re: [dwm] What functions do I really use?

Ok, let's take it as understood that I don't use dwm in the way most people think is same :-) Also, I know dwm is "Anselm's wm" (whilst wmii is "community's wm"). I'm saying things so they get into discussion, even if they may not be suitable for dwm. Also, obviously thanks to Anselm for all his work on dwm. |Personnaly, I rarely/never use the following features/functions: | |- titlebars of clients (I really can live without them, I never | look at them), removing titlebars could reduce the source | about 70 lines, maybe more with some restructurings |- viewall/toggleview: (I never view more than one tag per time, | although I use the other way around, tagging some | clients with more than one tag that they appear when | viewing different tags) - I haven't implemented a patch, but | this could make seltag[] obsolet, and at least the functions | I listed here, approx. yet another 50-70 lines | -> instead this feature, I would consider holding | a pertag array for client order instead, to remember the | per-tag layout correctly, this might add yet another 20-30 | lines It took me a while to figure out what to use "multiple viewed tags" for, but it's helpful to "park" auxiliary things, like build windows, graphical debugger, postscript viewer (when writing papers), etc, into a tag all on their own. When I'm working on source most of the time I don't want them visible. But when, eg, you've done a batch of editing and want to compile it's simple to add the "build window" tag to those viewed, build-and-fix-typos, then when finished remove the "build window" tag. Likewise for other things. It's also useful to do a "temporary merge" of two different kinds of things, eg, one tag with "program source code windows" and "experiment display windows" when you want to compare between the two. (Aside: one personal change is that, when multiple tags are viewed, new clients just get the highest set tag rather than all set tags; otherwise I find I spend more time removing unwanted tags from newly created clients than the other way around.) I personally don't use the "stdin display" portion of the tagbar, and I suppose I don't really use the "focussed window's name" part either. I do both look at the tags part and do a lot of my changing viewed tags by clicking on it. I don't really move clients around by clicking on it because I'm nervous which client'll count as focussed at the time. (I know the focus weirdnesses are X issues that dwm does its best to cope with.) Another personal hack is to have a dot (opposite corner to the "current clients tags" dot in tag bar) on the tags which displays if the tag has any clients tagged with it. This is partly useful to avoid having to search through all tags (rather than just non-empty ones) if I forget where something is, but it also allows a simple "notification hack" for cases like mozilla download windows: I want to see when the process stops, but I don't need to see the whole window whilst it's happening, so I park it in a temporary unused tag (which now gets a dot). If I occasionally glance at that tag, when the dot has disappeared I know the window has been closed and so the process has finished. Obviously all X clients implementing a well-defined notification protol the WM could use would be the ideal world, but this makes things work-ish with the apps I use ;-) Off-topic: ======== The two issues I'm grappling with at the moment are: 1) I still want to figure some way for an application to request a window become visible to the user. (For example, in a build window I want to click on a compiler file:error line and jump to that window.) Yeah, ill-behaved clients could conceivably bugger about with this, but I'd find it useful. The bigger issue is the semantics for it: the obvious thing is add (one of) the "to become visible" window's tags to those currently viewed, but that may put a lot of other windows with that tag onto the screen making every window tiny. Still thinking... 2) Multiple-tag views allow viewing unions of clients, but I often want to temporarily look at a subset of the clients in the current view so as to get more screen space. (Eg, with a screen of five code windows I want to view just two side-by-side in long columns so I can compare them.) I've got functions to "push to temporary tag" and "pop temporary tag" that make assumptions that the most relevant tag is the highest tag, so that I can do all work purely with relative commands (eg, "push", "pop", rather than have to remember exactly what the workspaces are called and what their key-shorcuts are). This works reasonably, but I often want to use two (or more stacks at once) which isn't possible this way. For example, this afternoon I'm trying to work on a simulation program so I'm primarily concerned with it's guts and have a "pushed" temporary tag for that. Unfortunately, my generic code that writes graphical output seems buggy, so I'd like to push those files to another temporary tag, but with the "assumed highest tag" way of pushing I can't, so I've had to add another tag "manually" and remember what its key-shortcut is. One option would be to think about making this "stack" notion real, rather than simulating it within a linear array. However, that seems to make it impossible to use consistent key-shortcuts. Again, still pondering... If I get any inspiration about how to do these things neatly I may have a go at implementing them. Anyway, those are my thoughts, cheers, dave tweed Send instant messages to your online friends http://uk.messenger.yahoo.com
Received on Wed Nov 22 2006 - 14:13:47 UTC