On Thu, 12 Oct 2017 08:13:00 -0500 "Matthew D. Fuller" <fulle...@over-yonder.net> wrote:
> On Sat, Oct 07, 2017 at 10:13:35PM -0400 I heard the voice of > Steve Litt, and lo! it spake thus: > > > > I mentioned I was writing documentation about ctwm for > > Troubleshooters.Com. I finished the docs, and they're at > > http://troubleshooters.com/linux/ctwm > > Some notes in going through: > Thanks for this thorough feedback, Matthew. This email contains responses to the easy low-hanging fruit. > The nested/window-mode ctwm with -w is still high up on my mental > chopping block; it's a really weird thing that doesn't actually > work all that well in a lot of ways, has fingers mucking up a lot > of different parts of the code, and has been involved in some > weird bugs in the past even when you're not using it. Yes, -w is definitely twitchy. I once tried to import a base window into the ctwm -w window, and that made a mess that finally resulted in my killing X. > I would > definitely recommend not even mentioning its existence; xnest is > better in every practical and most impractical ways. I could recommend xnest, but not until I solve some of its problems. First, it's horribly underdocumented --- I spoze I could fix that. But also, ctwm acts funny within it. First is the deficiency also shown by ctwm -w: hotkeys are intercepted by the base server (display :0) before going to xnest (display :1), so hotkeys are out. Unless I include a menu path to execute dmenu, this is a severely retarding influence (no different than ctwm -w, though). So I can't really change this until I solve some problems with running ctwm in Xnest. > - "About Icons". I'd probably move this into a place talking about > the icon manager. In ctwm (and twm before it, for that matter) > I've always just used the icon manager and IconifyByUnmapping, so > icons never show up at all. Other people do differ. About a day after releasing this document, I realized ctwm is at a big disadvantage without full icon support. Also, Aaron Sloman pointed this out to me. And now you. I'll remove this very negative "About icons" sections, and probably add a full document on icons and the icon manager. > > > - install.htm > > - "Download either ctwm-4.0.1.tar.xz or ctwm-4.0.1.tar.xz." You > probably wanted one of those to be .gz. Fixed! > I'd consider skipping > talking about .gz depending on your audience, since it's just > there for what are now pretty old systems that lack xz. I left in the .gz. A lot of people still use that, especially for archival purposes. > > - "Testing ctwm" (and the cp'ing of system.ctwmrc earlier); trust > me, nobody running ctwm uses or thinks too highly of the > system.ctwmrc :). Note that it's also baked into the binary, so > if you don't have a .ctwmrc (or .twmrc, as a fallback), it'll get > used anyway, so you may not have to bother cp'ing it around. I'm glad to know I'm not alone in thinking the default messy. I left the blurb about copying to ~/.ctwmrc in there on the theory that we all like a known state. > > > - modernize.htm > > - (various comments handled in talking about config) > > - f.fullscreenzoom mentions using F11 to "come back", but that isn't > something ctwm would do unless you added a key binding for it > (which I don't see in your config). Some _programs_ (like > Firefox) use F11 Ouch! I hate giving bad advice: Thanks for pointing this out to me. I just fixed it, telling them to move the window down and to the left, then shrink it. > - "Accommodating Workspaces" > > - "There are two ways to navigate workspaces: Brute force menus, > and the super-magic workspace thingy, which looks like 8 > chicklets in 2 rows of 4 columns each. This section uses a > little of each." > > Actually, there's at least one more; keybindings, which you then > talk about and have in your sample config, and are probably > widely used anyway. I know that, and you know that, but the person not knowing it will probably encounter it as a 2x4. I thought about more explanation, and decided against it. > > Also, the size and layout of the WSM is pretty depending on how > you config it; e.g., mine (when it's shown, which is extremely > rarely) is currently a 3x3 grid, and in your sample config, > you've got it 8-wide in 1 row. Again, not wanting to overload the reader, I left this for her/him to discover. > > - menu_behavior.htm > > - The "Slide left" behavior for the mouse is wrong. Sliding left by > itself never does anything, no matter what entry you're on. Fixed. > > - patch.htm > > - vim-style menu navigation is an interesting idea. I'll bet there > are ways that could be cleanly(*) made an option. You bet there are. I had Vim-key menu navigation running for awhile (with my patch) but took it out because I don't like changing other peoples' code because I don't know their design priorities. My j,k,h and l hotkeys overrode ctwm's excellent first letter recognition, so probably in real life they should have a modifer like alt or ctrl. > > (*) Well, not significantly less clean than anything else around > that part of the codebase, anyway... > > - Re: the patch, I'd generally suggest something more like > > - if(!strcmp(keynam, "Return")) > { > + if(0 && !strcmp(keynam, > "Return")) { > > instead of messing with the string being compared; it's more > explicit about the intention to the reader, as well as making it > completely removable by the compiler. Or using the preprocessor > to remove it, but that takes TWO lines instead of one, so it's > obviously only half as good. You're right, of course, but I left the patch alone because as of your next version release this becomes a moot point and I remove all references to the patch. > > - stevelitt_ctwmrc.htm (and -1.0.ctwmrc) > > - I've academic interest in how MaxWindowSize is helping you. I had > it in my config for years, but I eventually took it out, because I > pretty much never saw it helping anything, and even once in a > great while (~yearly, if perhaps less) it got in my way. I'm not sure, but I think it makes sure my maximized windows are the correct size. Don't shoot me if I'm wrong. > > - BorderWidth and ThreeDBorderWidth. If you're > UseThreeDBorders'ing, BorderWidth is meaningless. I just set them to the same thing in case I switch between 3D and flat. > > - The various bits you have "Help kbd instantiated windows get > focus" commented probably need a little more precise explanation. > UsePPosition especially doesn't have anything to do with focus, > but with positioning, and ditto RandomPlacement. Possibly you > mean how that just plop the window somewhere rather than waiting > for the user to position? Of course, if you have RandomPlacement > on, UsePPosition wouldn't be needed for that anyway, and > RandomPlacement "on" is the default in 4.0.0+ as well. That .ctwmrc code was some of the first I wrote, before I was even sure I was going to spend any time with ctwm. It was a result of rapid fire trial and error to get the behavior I wanted. You're right about waiting for the user to position. In a workflow where 90%+ of all windows result from a hotkey, requiring the user to position the window would bring productivity to a halt. > > Now, I don't see any obvious reason it would be difficult or > ambiguous to add an AutoFocusToNewWindows or the like... there > are certainly the various (IMO unpleasant) side effects, but > that's not the WM's fault. I might examine that later. So far, my stevelitt.ctwmrc is working very well for me, so further experimentation is a lower priority. > > - You may want to rethink whether to set NoDefaults; as long as > you're making some adjustments to the icons on the titlebar > anyway, you may want to just take over from scratch. That's pure > personal style though. Turns out I regularly use the default provided iconize and resize buttons, and simply add to those. Given that the NoDefaults also removes some default behavior, according to the man page, I took the safe rout and left the defaults intact. > - On the menus: > > - There's probably no reason you need xcalc/xman/xmag on there :) xcalc and xman, you're right. Xmag, I did this: "Xmag" !"xmag -mag 3 -source 600x300 &" Yeah! Perfect! > > - menu "workspace-special" looks like a fossil from > experimentation; probably not needed in a dist'd config. Yeah, that'll be gone in 1.1 > > - I'd definitely lose the f.adoptwindow binding, along with the > other nested stuff above. Good catch. f.adoptwindow is just plain dangerous. That'll be gone in 1.1. Thanks so much for this detailed report! SteveT Steve Litt October 2017 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
