Re: Alt+Tab behavior [ now with experimental code on a new branch ]
On Mon 08 Mar 2021 at 13:34:26 -0600, Matthew D. Fuller wrote: > I guess we're post-py2 now, so I should updated the webpage to talk in > terms of brz... I am indeed not so fluent with bazaar/breezy that I am up to date with the latest developments. I am using "bzr qlog" a lot to visualise the history. There is development going on to update this to breezy, python3 and Qt5 (since Qy4 is deprecated too). As far as I could see, the code is there but there is not release of it yet. Maybe there are some details that are still blocking that; I haven't tried it. https://code.launchpad.net/qbrz -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a new branch ]
On Tue 29 Dec 2020 at 15:16:10 +0100, Rhialto wrote: > You can still find the branch at > https://code.launchpad.net/~ctwm/ctwm/windowstack > (lp:~ctwm/ctwm/windowstack). I "rebased" this branch because of recent commits to trunk. Bzr doesn't have a "rebase" command, so when I say "rebased", I say "I have painstakenly cherry-picked all relevant commits to a new branch". And when I say "cherry-picked", because bzr also does not have a cherry pick command, I mean "I used a script I randomly found on the Internet". So the branch is now called https://code.launchpad.net/~ctwm/ctwm/windowstack2, because it isn't a rebase but a new branch. Also, some weirdness snuck in (because it was entangled somewhat with the window ring cleanups that are now on trunk) and I had to add an extra commit to fix that. I haven't checked if it needed even more fixups. If history rewriting were a bit easier, I would have combined it with the first commit. There is a "bzr-rewrite" plugin, but it hasn't been updated since 2012 and it doesn't work with Python 3.7. https://bugs.launchpad.net/bzr-rewrite/+bug/1918171 -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a branch ]
On Sun 27 Dec 2020 at 18:51:57 +0100, Rhialto wrote: > So, after some thinking I made a first go at a window ring that behaves > like a stack. I made some small tweaks in the code, and a user-visible change. I noticed that the so-called RingLeader (the window that is the starting point for Modifier-Tabbing) can change when you enter or leave windows[1]. That is no good if you want to see the ring as a stack, since it rotates the stack. So I have designated the Ring pointer, which points to the "start" of the ring, as the fixed starting point. [1] Aside: I would think it should be based on focusing, not mere mouse movement, but that's how it is right now. You can still find the branch at https://code.launchpad.net/~ctwm/ctwm/windowstack (lp:~ctwm/ctwm/windowstack). -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a branch ]
So, after some thinking I made a first go at a window ring that behaves like a stack. Based on the following observations: - The difference between a window ring and a stack is effective at the moment the modifier key is released. - at modifier-down time, we remember the "top of the stack". - at modifier-up time, we move window we moved to (if any) to the top of the stack. - So if we can do some administrative work both when the modifier is pressed and when it is released, we can make a ring into a stack. - We can already make bindings for pure modifier keys. - All current bindings are for key-down events. - We can make bindings for key-up events if we pretend this is a new modifier. # This makes bindings for the usual window ring: "Tab" = m4 : all : f.warpring "next" "Tab" = m4 | s : all : f.warpring "prev" "Return" = m4 : all : f.ring # This turns the window ring behaviour into a stack behaviour: # Note that the Super key corresponds to modifier 4. "Super_L" =: all : f.warpring "startstack" "Super_L" = up | m4: all : f.warpring "finishstack" You can find a branch at https://code.launchpad.net/~ctwm/ctwm/windowstack (lp:~ctwm/ctwm/windowstack). I guess that's a "ctwm" more than needed but I had to try a few times to get the syntax right and I didn't want to overwrite trunk. There are some things in it that I'm not so happy about yet. - Names of things. startstack and finishstack aren't the best names, but the code in f.warpring looks at the first letter only right now to decide, so I wanted distinct first letters. - I factored out some code to manipulate the window ring (add and remove a window) and I'm not sure in which source file that belongs. - There are probably some edge cases that this code doesn't handle. I tested it lightly and that seemed to work though. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Alt+Tab behavior
On Tue, Dec 22, 2020 at 02:29:13PM -0500, Steve Litt wrote:
> Hi Tina,
>
>
>
> I'm writing this email in hopes I can understand how you use ring
>
> based alt+tab in the current ctwm, the goal being that maybe I can use
> it as effectively as you do.
>
YMMV on "effectively", but here goes:
1) .ctwmrc
# These windows will be excluded from the "warp ring", ie. not
included in the
# alt+tab cycle
#
WindowRingExclude {
"dclock"
"WorkSpaceManager"
"TWM Icon Manager"
}
(I see no need to tab into the WM or Icon managers)
2) .ctwmrc
"Tab" = m : all : f.warpring "next"
"Tab" = s | m : all : f.warpring "prev"
(So, yes, correct)
> Some questions...
>
>
>
> * When pressing alt+tab, what is your thought process as you do it?
>
Not much THOUGHT involved ;) but "I want to move to the next window
in the list of windows", basically.
> * What do your actions look like as you do it?
Not sure how to answer this one. I press down on the left-alt key
with my thumb, then the tab with my ring-finger (left hand). Repeat
until the window I desire come into focus (auto-raise is on)
If the window is on a different desktop I use left-alt-shift+h|j|k|l
to switch desktop, THEN alt+tab.
> * Do you have some special keyboard technique, or do you just press alt
> and keep on tabbing?
Yes. This is the part I prefer to Windows. alt+tab gives me the next
Window in a fixed cycle.
> * Do you have a way of recognizing when you're on the desired
window?
Yes again - active windows have a bright red border (1px wide);
inactive have black (I use a black background) and fade out.
> * What do you do if you alt+tab once too often, and need to go back
> one window?
alt+tab+shift goes a step back. (left thumb+left ring finger+left
pinkie)
Note that I use specific desktops (8x) for specific tasks, so there
are rarely more than 3-4 windows per desktop.
--
- Tina
Re: Alt+Tab behavior
Steve Litt wrote in response to Tina Holmboe: > On Tue, 22 Dec 2020 10:48:15 +0100 > Tina Holmboe wrote: > > > On Thu, Dec 17, 2020 at 09:09:22AM -0500, Steve Litt wrote: > > > > > Could you please add stack-based Alt+Tab behavior to ctwm? My guess > > > is it would require the following: > sl...@troubleshooters.com wrote: > I'm writing this email in hopes I can understand how you use ring > based alt+tab in the current ctwm, the goal being that maybe I can use > it as effectively as you do. Although not requested, here's what I do for what I think is being discussed. I use Control + Left or Right to go round workspaces in one or other direction and Control + Up to cycle throught stacked windows within a workspace. E.g. # Use control key plus left or right arrow to go to next or previous # workspace (next and previous in the order listed in workspace # definitions, treated as a cyclic list.) "Left" = c: all : f.function "GoLEFT" "Right" = c: all : f.function "GoRIGHT" ## This prevents warping to windows in other workspaces (I think) # comment it out if you wish to warp to arbitrary other windows. WarpRingOnScreen ## Cycling through a stack of windows in the same workspace, using Ctrl+Up "Up"= c: all : f.raiselower [All this after swapping Ctrl and CapsLock] I'm happy to receive improvements. Aaron
Re: Alt+Tab behavior
On Tue, 22 Dec 2020 10:48:15 +0100 Tina Holmboe wrote: > On Thu, Dec 17, 2020 at 09:09:22AM -0500, Steve Litt wrote: > > > Could you please add stack-based Alt+Tab behavior to ctwm? My guess > > is it would require the following: > > IDIC indeed ... > > Personally I use the alt+tab functionality on both Linux with CTWM > and, at work where I have no choice, on Windows. The ctwm variation > is without doubt the most sane and useful I've ever found. > > So I, for one, would much prefer to keep it as-is. I'd hope you guys > atleast consider a configuration option to do so. Hi Tina, I'm writing this email in hopes I can understand how you use ring based alt+tab in the current ctwm, the goal being that maybe I can use it as effectively as you do. First of all, as I remember, and it's been a couple years, alt+tab isn't defined in system.ctwmrc or any of the example .ctwmrc files, so I'm assuming you've assigned alt+tab to f.warpring "next" or f.warpring "prev", or somehow both. Is this correct? Some questions... * When pressing alt+tab, what is your thought process as you do it? * What do your actions look like as you do it? * Do you have some special keyboard technique, or do you just press alt and keep on tabbing? * Do you have a way of recognizing when you're on the desired window? * What do you do if you alt+tab once too often, and need to go back one window? Thanks, SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: Alt+Tab behavior
On Tue, 22 Dec 2020 10:48:15 +0100 Tina Holmboe wrote: > On Thu, Dec 17, 2020 at 09:09:22AM -0500, Steve Litt wrote: > > > Could you please add stack-based Alt+Tab behavior to ctwm? My guess > > is it would require the following: > > IDIC indeed ... > > Personally I use the alt+tab functionality on both Linux with CTWM > and, at work where I have no choice, on Windows. The ctwm variation > is without doubt the most sane and useful I've ever found. > > So I, for one, would much prefer to keep it as-is. I'd hope you guys > atleast consider a configuration option to do so. > > -- > - Tina Yes! Of course it would be a config option, and not the default. I'd never want to force a workflow change on people using the current ctwm. As long as the possibility exists to have stack-based Alt+Tab exist after suitable configuration, even if not the default and requiring one to opt in, I'm ecstatic. The way I envision this thing happening, if it happens at all, is that from your point of view, CTWM alt+tab behavior would remain the same as always. From my point of view, I'd redefine the Alt+Tab behavior to call functions from the stack-based window access code. And now that you mention it, I'd recommend that, if we can ever get the alt key, as well as shift, ctrl, and the windows key is called, to recognize key up and key down, that would be a configuration option that defaults to no. My goal here would be to keep the stack-based behavior as separate to the rest of ctwm as possible. It would never want my convenience feature to force anybody else to change their workflow patterns. I'm going to write a separate response to your post asking you some questions. Thanks, SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: Alt+Tab behavior
On Thu, Dec 17, 2020 at 09:09:22AM -0500, Steve Litt wrote: > Could you please add stack-based Alt+Tab behavior to ctwm? My guess is > it would require the following: IDIC indeed ... Personally I use the alt+tab functionality on both Linux with CTWM and, at work where I have no choice, on Windows. The ctwm variation is without doubt the most sane and useful I've ever found. So I, for one, would much prefer to keep it as-is. I'd hope you guys atleast consider a configuration option to do so. -- - Tina
Re: Alt+Tab behavior
On Thu 17 Dec 2020 at 09:09:22 -0500, Steve Litt wrote: > What do you think? We thought about this before, but I couldn't find it quickly, so I'll summarize what I remember from it. The big difference with a window stack is (assuming Alt-Tab as hotkey) is that it does different things depending on when you let go of Alt. For ctwm Alt-down Tab-downup Tab-downup Alt-up is the same as Alt-down Tab-downup Alt-up Alt-down Tab-downup Alt-up because it doesn't look at Alt-only key events (I think [1]). But for the first sequence, you switch to the 2nd window down your stack, and for the second one, you switch to the 1st window on your stack and then back to the original (which is on top of the stack after the first switch). Also, you need to be able to express the difference in the key bindings in some sensible manner. Then the rest is trivial. Patches welcome, I'd say. H if [1] isn't true, or could easily be fixed so that you can write a key binding that matches an Alt-up or an Alt-down specifically, possibly you could get quite far by using f.altkeymap to switch between various states... I didn't try to elaborate on this thought though. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Alt+Tab behavior
Hi all, A few years ago, for a solid month, I gave up my beloved Openbox for ctwm. Here are some articles: http://troubleshooters.com/linux/ctwm/ My reason was to try to use something EVEN MORE lightweight than Openbox. The benefit I found was configurability beyond my most pie-in-the-sky hopes. After a solid month I went back to Openbox for one and only one reason: The behavior normally associated with Alt+Tab on other window managers, DEs, and Windows UIs. Alt+Tab on Windows, Openbox, Gnome, IceWM, and most other user interfaces works with a stack. The current foreground window is at the top of the stack. You press the Alt key. The first time you simultaneously press Tab, you see a representation of the window second to the top of the stack. Release and press Tab again while still holding Alt, you see the third to top of the stack. Etc. When you finally release the Alt key, the window of the stack item you'd Alt+Tabbed to comes to the top, has focus, and the former top focus window becomes the second to the top of the stack. I dislike Microsoft and Bill Gates, but one thing I have to give them credit for is that in Win95, they sat down hundreds of users for useability tests, listened to those users, and make the Win95 User Interface a marvel of intuition and ease, not just for mouse fans, but for keyboard fans too. I worked a solid month with ctwm's ring based window navigation, performed every workaround I could think of, including assigning separate next and previous on the ring hotkeys, worked day in and day out with it for a solid month, that's hundreds or perhaps over 1000 uses of those keystrokes, and I just couldn't get used to it. I'm a guy who adapts to his machine or software. In my youth I built bicycles out of parts from dumpsters, and if my bicycle constantly steered to the left, within a couple days I didn't notice because I'd compensated for it. I've driven cars with stiff clutches, easy clutches, worn out loose clutches, brand new tight clutches, and no clutches at all (automatic transmission), sputtering engines on the border of stall, crisp engines with get-up-and-go, bouncy suspensions and stiff suspensions, without a problem after a couple days. But some things, like a bicycle, car or skateboard with oscillatory steering, or, more on topic, ring based as opposed to stack based window switching, I could never get used to. Could you please add stack-based Alt+Tab behavior to ctwm? My guess is it would require the following: 1) Detection of both key-down and key-up on mod keys such as Ctrl, Alt, Shift, and Windows. I'm pretty sure that's available from X. 2) A stack. That's trivial: I could code it myself, but connecting it to existing ctwm code would be difficult for me. 3) Whatever facility currently inserts windows into and deletes windows from the ring would also need to do the same thing with the stack. Implementation could be via at_plunge(), at_select(), at_add(), and at_delete() where "at" stands for "Alt+Tab". Naturally, they could be named anything. Here's pseudocode, keeping in mind there'd need to be one stack for each workspace: at_plunge() If not stacks_enabled return If at stack bottom Go to stack top else Go down one level on the stack at_select() If not stacks_enabled return Remove current item from stack Suck down everything above current by 1 Push current item onto top of stack Move window for now-top stack item to foreground Move ring pointer to now-top in ring at_delete() If not stacks_enabled return Remove current item from stack Suck down everything above current by 1 // No need to adjust the ring, other things did that at_add() If not stacks_enabled return Create new stack item for new window If new window intended to have focus Open new window, with focus Push the new stack item else Open new window below all else on workspace Insert new stack item at bottom of stack // No need to adjust the ring, other things did that The beauty of this is it's a tight module easy to plug in without major disruption to any other part of ctwm. It adds an alternative to the window ring, but doesn't replace it. It has a small interface to the existing ctwm: * Every time you add a window to the ring, add it to the stack. The stack is completely separate from the ring. * Every time you delete a window from the ring, delete it from the stack. * Every time you move the ring pointer and display a new window, perform a corresponding at_select() on the stack * Every time you do an at_select(), move the ring pointer to the selected window. * Add at_keycombo more item to .ctwmrc, which also implies s
