Re: The one improvement I'd like on ctwm
On Fri, Oct 12, 2018 at 12:19:06AM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > MAYBE if we can link an event to "letting go of ALT", that could be > bound to a new action that modifies the ring to behave like a stack. > But I haven't looked yet how easy or hard that would be. Yeah, we start extending the altkeymap-ish functionality even further to having whole different modes. Well, modal editors are Obviously Correct(tm), so I guess it makes good sense for WM's too :-) Sounds like something a lot of parts of the code would need to know about, though... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: The one improvement I'd like on ctwm
On Mon 08 Oct 2018 at 20:40:55 -0400, Steve Litt wrote: > Contrastingly, ctwm keeps the windows on a given workspace in a ring > buffer. This requires two different keystrokes: One to navigate > clockwise, and one to navigate counterclockwise. For whatever reason, > even after 2 months using specially created hotkeys for these > circular navigations, I couldn't get my muscle memory to work with the > 2 key solution. The window manages that keep a stack instead of a ring also have 2 different key bindings for forward and backward, but the second one isn't used much, typically. Usuallt ALT-TAB and SHIFT-ALT-TAB. I just looked at the code, and in principle it isn't hard to change the ring into a stack. Adding an option to do it is just a bit more work. BUT: it would be useless. Other window managers keep some kind of box open as long as you keep the ALT (or for me WINDOWS) key down. You can press TAB several times. When you finally let go of ALT, the then-selected window is really made active, and pulled to the top of the stack. But ctwm doesn't work like that. Every time you hit the key combination, it immediately switches to the next window in the ring. If you pull that one out to the "top", you'd simply keep switching between two windows. MAYBE if we can link an event to "letting go of ALT", that could be bound to a new action that modifies the ring to behave like a stack. But I haven't looked yet how easy or hard that would be. But if it is possible it would be a nice configuration flexibility. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: The one improvement I'd like on ctwm
> I wanted to be able to type into the partly covered window > [...] > It would have been intolerable to always have to bring the > text window to the top in order to provide text input. So > in that context, the mouse was used to interact with the > program being tested and demonstrated and also used to > change input focus between the test/demo window and the > partly covered text window. That's mostly my style of working. And if you have a trackpoint on your keyboard, you don't even have to move your hand to move the pointer. > In most other contexts, e.g. editing latex source in a text > window and every now and again viewing the formatted PDF file > generated from the text, I don't need to use the mouse and > can use keyboard to write the file and generate pdf, and if > needed, to raise and lower the editor window. Indeed. But zooming in to a particular region to check some detail in the PDF is *much* simpler using the mouse and the "marquee zoom" feature of acroread or gv. > I also don't know any way to use keyboard to select and paste > text between applications, e.g. from a text file in the editor > to a web browser window, or vice versa. I've configured both xterm and vim to use shift-insert to paste text from the X11 selection. In vim you can use registers "*" and "+" to copy text to/from the X11 selection and clipboard. For firefox, pentadactyl/vimperator provide lots of useful keyboard commands (e.g., select an URL in a text window, got to firefox and press "P", which makes firefox open that URL in a new tab; you can select text from a web page using "caret mode").
Re: The one improvement I'd like on ctwm
Thanks for the latest comments. I thought I should clarify this: AS > > Perhaps I don't need this > > because I set focus to follow mouse always? SL > Yes! It sounds to me like your interface usage is primarily mouse, but > with some hotkeys thrown in for extra efficiency. Not really. I like to stick with the keyboard as long as possible. But there are exceptions. E.g. in the past I did some programming (using pop11 in poplog) that included running a simulation that was under development, in a graphical window where use of mouse was part of the demonstration (e.g. showing how a simulated sheepdog would notice and react to a sheep moved by the mouse). During interactive development and debugging (a feature of pop11's incremental compiler) it was often useful to have the text window with code to drive the simulation, and the larger interactive graphical window partly covering the text window. I wanted to be able to type into the partly covered window, e.g. to edit code or give commands to the program, while retaining the option to use the mouse to interact with the display -- moving objects, clicking on buttons, moving sliders, etc. It would have been intolerable to always have to bring the text window to the top in order to provide text input. So in that context, the mouse was used to interact with the program being tested and demonstrated and also used to change input focus between the test/demo window and the partly covered text window. In most other contexts, e.g. editing latex source in a text window and every now and again viewing the formatted PDF file generated from the text, I don't need to use the mouse and can use keyboard to write the file and generate pdf, and if needed, to raise and lower the editor window. I also don't know any way to use keyboard to select and paste text between applications, e.g. from a text file in the editor to a web browser window, or vice versa. I am puzzled by this: [AS] > > This means that Meta + Left arrow goes one way round the windows in > > the current workspace and Meta + Right goes the other way. Surely > > easy to remember? [SL] > It would seem so. And I had similar (but better and faster > ergonomically) hotkeys for the same functionalities. I thought for sure > my fingers would get used to it. But they never did, after a solid > month of everyday (everyminute, actually) use. That it did not work despite those features sounds very strange. Feel free to try my version in case it has a different effect on your hippocampus, or whatever! Best wishes. Aaron http://www.cs.bham.ac.uk/~axs
Re: The one improvement I'd like on ctwm
On 10 Oct 2018, Steve Litt wrote: > On Tue, 9 Oct 2018 20:48:58 +0100 > Aaron Sloman wrote: (snip) >> However if the windows occupy different portions of the screen, with >> only partial overlaps, what becomes visible will depend on where the >> mouse pointer is. > > The preceding sentence is an absolute showstopper for me. I can't work > in and environment where focus depends on mouse hover. (snip) Heh, I'm just the opposite: I would love to configure things so that no window can ever steal focus. It is /never/ what I want them to do. Just now moving back to ctwm though the packaged binary of it for NetBSD seems to be still back on v3.8.2. -- Mark
Re: The one improvement I'd like on ctwm
Steve Litt sl...@troubleshooters.com
wrote:
> I switched away from Openbox, to ctwm, for about 2 months, before
> switching back to Openbox.
Ctwm was my favourite for many years (from around 1995?) but for a while I
switched to Openbox because ctwm wasn't available for some reason, or had
stopped working properly (on my fedora PC and laptop). I don't remember
details.
As soon as ctwm came back to life I returned to it. One reason I prefer
it is the *much* simpler syntax for .ctwmrc compared with the xml format
of openbox.
> .
> Contrastingly, ctwm keeps the windows on a given workspace in a ring
> buffer. This requires two different keystrokes: One to navigate
> clockwise, and one to navigate counterclockwise. For whatever reason,
> even after 2 months using specially created hotkeys for these
> circular navigations, I couldn't get my muscle memory to work with the
> 2 key solution.
I wonder whether it depends on the keys you choose.
I have
WarpRingOnScreen
"Left" = m : all : f.warpring "prev"
"Right" = m : all: f.warpring "next"
This means that Meta + Left arrow goes one way round the windows in the
current workspace and Meta + Right goes the other way. Surely easy to
remember?
I have a similar scheme for cycling through my 12 workspaces, using
Ctrl + Left and Ctrl + Right
Function "GoLEFT"
{ f.prevworkspace
f.unfocus
}
Function "GoRIGHT"
{ f.nextworkspace
f.unfocus
}
## invoked by Ctrl + Left or Right Arrow key
"Left" = c: all : f.function "GoLEFT"
"Right" = c: all : f.function "GoRIGHT"
===
If I have a lot of windows in a workspace, and only a few of them are open
and stacked, I can cycle through the open ones, whose boundaries contain
the mouse pointer, using Ctrl + Up
"Up"= c: all : f.raiselower
However if the windows occupy different portions of the screen, with only
partial overlaps, what becomes visible will depend on where the mouse
pointer is.
But I may have failed to understand the requirement.
> As another useful enhancement, most WM/DEs (Window managers and Desktop
> Environment) flash on the screen the name of the program that would gain
> focus if you let go. I have no idea how easy or difficult that would be.
Not sure I understand this. Let go of what? Perhaps I don't need this
because I set focus to follow mouse always?
Aaron
PS
For several months I've been worried about ctwm because I use right click
on titlebar to minimise a window and it only worked intermittently.
Then a few days ago it stopped working altogether, just after I had
installed the latest ctwm. I was about to start investigating whether ctwm
was broken then thought I should try another mouse. It worked. Apparently
the old mouse had an intermittently failing right mouse button for some
time, and now it's completely dead.
Moral: stop assuming that only software goes wrong...?
