Add <G> and <gg> to scrolling (?) about vimac

[dexterleng]

@NolanChan

There's a 'Building' section in the README.

You can start off in the scroll mode view controller, which is activated by ModeCoordinator upon scroll mode shortcut activation.

The ScrollModeInputListener listens for keystrokes, which is then converted into a ScrollEvent being emitted (which the view controller listens for).

The steps that I would take to tackle this task:

1. Start listening for G (gg seems a little complicated for now)

Add the ScrollDirection (scrollToBottom) here

Hardcode the G key to emit this ScrollDirection by adding the binding here

2. Reacting to ScrollEvents

Refer to on(scrollEvent:): https://github.com/dexterleng/vimac/blob/faa07ea2b7d4b7fa77dc219dd68cd929316efe69/ViMac-Swift/ViewControllers/ScrollModeViewController.swift#L103

There are currently two "Scrollers" - Smooth and Chunky. You can create a new one called ScrollToBottomScroller.

As for the implementation details of this Scroller, you can copy the ChunkyScroller, but scroll by a fixed amount (the distance to reach the bottom of the scroll area). As for how to calculate the distance to the bottom of scroll area, I have no idea. You could look at the properties of an AXScrollArea through Xcode's Accessibility inspector or docs. Alternatively, you could just scroll down by a huge amount like 99999999.

For gg support

You will have to modify the scroll input abstractions I've created to react to double key presses. Perhaps refer to how vimium structures their code to handle this.

Hope this helps :) Look forward to your contribution.

[zant]

I second this, and I'd like to try implementing it, do you think it will be a nice feature to have? @dexterleng

[dexterleng]

@gonzachr Of course! Let me know if you need help navigating the codebase.

[NolanChan]

I'd actually be really happy to help as well! I gotta watch some swift videos, but @dexterleng is there a place you'd recommend writing the code in the codebase? :D

@dexterleng also do you have a short writeup on how to develop this app locally? Thanks!

[zant]

@NolanChan It's all yours! I actually ended up being more busy than I thought these days, glad you commented!

[dexterleng]

There is a command fn + arrow-left and fn + arrow-right that appears to scroll up/down to bottom. I believe it activates AXScrollArea scroll left/right by a page action. You could choose to activate that action instead of doing a calculation or scrolling by an absurd amount.

[NolanChan]

Wow, this is very informative, thank you Dexter!

[colossatr0n]

I took a stab at this and ran into a couple dead ends. I was able to get the ScrollModeActiveScrollAreaViewController to listen for G and then send the appropriate key kVK_Home/kVK_End. The problem is that the key event isn't picked up by the scroll area after it's activated.

To replicate the issue, activate a scroll area with Vimac and press the Home key or End key on the keyboard. If you're using an Apple keyboard, do Fn + left arrow or Fn + right arrow. Nothing should happen because the scroll area doesn't pick up the event. However, if you click after activating a scroll area and then press those keys, the view will scroll to the top or bottom, but that will break things as you'll no longer be able to press Tab to switch scroll areas or Esc to exit the scroll area.

I'm wondering if there's a way to programmatically select the same view that gets selected when clicking, but without actually clicking. If there were a way, the focus could be given to the view that responds to Home/End when Home/End is pressed, the Home/End event could be resent, and then the focus could be returned back to the Vimac scroll view.

Other than that, I'm not sure how the key events could be propagated through the Vimac scroll view.

[dexterleng]

@colossatr0n

To replicate the issue, activate a scroll area with Vimac and press the Home key or End key on the keyboard. If you're using an Apple keyboard, do Fn + left arrow or Fn + right arrow.

Right - The overlay window that Scroll Mode brings forward steals input focus from the active window. The same way Spotlight or Alfred does it.

However, if you click after activating a scroll area and then press those keys,

If you click on the overlay window, it ignores mouse events (self.ignoresMouseEvents = true), so that click event gets sent to whatever is behind the overlay window (the scroll area), causing the overlay window to lose focus and no longer steal input.

This is actually a bug - if the overlay window loses focus, scroll mode should just deactivate itself.

[dexterleng]

Seems like the Home and End solution may not be the best solution because:

1. The overlay window steals input from the active window
2. It only works on a single scroll area. I believe it only works on the largest scroll area on the active window?

I would suggest simply emitting a scroll event (see ChunkyScroller) with an absurd scroll value.

[dexterleng]

The Home and End solution will require the changing the overlay window to not steal input, but instead, receive input through installing a global event tap (CGEvent.tapCreate).

The global tap will then decide whether to ignore the event (and alert the overlay window of it) or forward it to the frontmost window.

I will probably have to do this in the future to support hints for context menus (see #77) since an input stealing window causes open context menus to close.

[colossatr0n]

@dexterleng I believe this issue can be closed.