Hi all, After 2 months of using ctwm on a day to day basis, I went back to Openbox. Then, after another month of thinking about the situation, I can say *why* I went back with three concepts:
1) Ring based instead of stack based window change 2) No "which window" feedback while cycling around window list 3) Dual focus All 3 of the above involve work in just one workspace. All 3 of the above happen while operating ctwm with the keyboard. RING BASED INSTEAD OF STACK BASED WINDOW CHANGE ----------------------------------------------- It's easy enough to declare alt+tab "f.warpring next", and even declare alt+grave as "f.warpring prev", but that doesn't make switching windows the intuitive, muscle memory activity that occurs with Openbox, Xfce, LXDE, KDE, and Win9x. Those iterfaces implement the window list as a stack instead of a ring. Every press of Alt+Tab without releasing Alt plunges one deeper into the stack, and if you pass the bottom of the stack, you cycle to the top of the stack. The head of the stack is always the current window, the next one down is the previous current window, etc. It turns out, at least for me, I "just know" the first 3 or 4 levels of the stack, but I can't keep a mental model of ctwm's window ring in my mind, so switching windows causes greater stress and more errors and takes more time for me. I'm probably not alone: That's why most window managers use the stack approach. NO "WHICH WINDOW" FEEDBACK WHILE CYCLING AROUND WINDOW LIST ----------------------------------------------------------- On most window managers and on Win9x, while keeping your thumb on Alt, each depress of the Tab key moves some sort of pointer through some sort of list of the windows. Feedback consisting of outlining the frame of the current destination window just isn't enough: If you have 8 windows on this workspace, you're not going to remember which was where. You need a list with names and probably more identification. Implementing "which window" feedback would go a long way toward making the ring organization of windows more useable. It wouldn't enable muscle memory, but it *would* enable one to Alt+Tab or Alt+Grave directly to the correct window, without second-robbing blown attempts. DUAL FOCUS ---------- As far as I know, this never happens for people who operate ctwm with their mice. It's a keyboard thing. Sometimes, when a new window pops up or an old (that was on top) goes away, you get a situation where one window appears to have focus according to its colors and on-toppedness, but another window receives the keystrokes. Sometimes the colors and on-toppedness tell different stories. +++++++++++++++++++++++++++++++++++++ NOTE: I'm talking about windows at the same levels. Obviously, if one window is one or more levels above another, split focus wouldn't be unexpected. +++++++++++++++++++++++++++++++++++++ The effect this has on the user is disconcerting and counterproductive. Every time the user sends an email from Claws-Mail and the compose window vanishes, [s]he is left with Claws-Mail *looking like* it has focus, but it really doesn't, and the user must do Alt+Tab then Alt+Grave to get where [s]he expects to be (complete focus on Claws-Mail). POSSIBLE IMPROVEMENTS --------------------- A window stack is pretty easy to maintain. You need a top pointer, a bottom pointer, and a current pointer, and a function to remove the selected window from the stack and push it onto the top. You could implement variables WindowStack and WarpStackOnScreen to parallel WindowRing and WarpRingOnScreen. Also needed would be f.warpstack as a parallel to f.warpring. Then it's just a matter of the user doing this: WindowStack WarpStackOnScreen #... "Tab" = m : all : f.warpstack "next" The dual focus situation can be straightened out with a new variable, perhaps named "UniFocus", which guarantees that all elements of focus be presented on exactly one window: Either the one newly popped up, or if one vanishes, the window that had focus before that one (the window stack would help there), or the window chosen by Alt+Tab. An exception would be made when windows are at different levels. I have abso-lutely no idea how to implement the "which window" feedback while alt+tabbing, other than the visual feedback should be attached to f.warpring (and f.warpstack should you choose to implement it). I do know it would make ctwm much more useful for those choosing to operate their user interface with the (much speedier) keyboard. KEYBOARD CENTRICITY ------------------- Looking at the system.ctwmrc that comes with ctwm, as well as the various .ctwmrc's exampled on the web, it's evident that most current and past ctwm users anticipate heavy mouse usage, which makes sense for those using two or three terminals and maybe one GUI program, all on a large monitor. But as the number of windows increases, replacing mouse usage with keyboard usage improves productivity, because you can execute three or four keyboard commands in the time it takes to grab the mouse and then move your hand back to keyboard home position. Try it some time: You might never come back. Although most ctwm's are set up for keyboard, the current version of ctwm is quite capable and productive using the keyboard, if properly set up. In fact, I'd rather operate ctwm using the keyboard than use *any* window manager or desktop environment using the mouse. If you type more than 30 words per minute and typically have more than 6 windows open, I think the same would be true of you, once you get used to operation via keyboard. So, if ctwm's keyboard interface can be made more effective, that's a very good thing. More people using it via keyboard means more productivity based publicity means more people using it via keyboard, ... SUMMARY ------- I used ctwm 8 hours a day, 7 days a week, for over two months. During that time I made a great many successful adaptations, both in my muscle memory and in code and ~/.ctwmrc, to make ctwm operate quickly and efficiently for my business needs and typing skills. But no adaptation I could make eased three focus related problems that caused me stress and slowed me down: 1) Ring based instead of stack based window change 2) No "which window" feedback while cycling around window list 3) Dual focus In other words, this isn't a case of a new user griping "hey, why can't your software have all the advantages my old software gave me?" I made every possible effort to adapt before suggesting changes. I suggested changes for each of the three perceived focus problems. My suggestions for 1 and 3 would not be default, thus would not effect existing setups. My suggestion for #2 would effect current setups in a way that I'd imagine would be universally perceived as good, but it would be easy to make that suggestion dependent on a non-default variable so no existing setup would perceive a change. I might be able to do a lot of the work on the Window Stack. Thanks, SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
