Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for docked windows in the various layouts at each edge #2391

Open
trygveaa opened this issue Feb 23, 2020 · 10 comments
Open

Support for docked windows in the various layouts at each edge #2391

trygveaa opened this issue Feb 23, 2020 · 10 comments
Labels
enhancement

Comments

@trygveaa
Copy link
Sponsor Contributor

I'm working on a kitten for incremental search in the backlog using the marks feature, but I've run into some issues.

Currently I'm starting the kitten with new_window @ kitty +kitten search.py, but I haven't found a way to specify the size of the window. I can resize it afterwards, but that looks bad and pushes the text in the original window upwards more than necessary. Additionally, it's not possible to resize it to less than 6 lines (I would like it as a single line).

Here it what it looks like:
kitty-kitten-search-2020-02-23_11 23 31

Another issue is that if I have multiple windows in kitty, the resize command will resize those too.

Additionally, it would be nice if the kitten could get the instance for the window it was started from (and possibly the other windows in the tab). Currently, I have to run kitty @ ls to find the windows in the same tab. Then I have to run all the marker and scroll commands via the remote protocol because I don't have the window instance available like you have if you run a kitten in the same window. Or is there some other way to do this that I haven't found?

This is the script I have so far:
https://github.com/trygveaa/kitty-kitten-search/blob/master/search.py
@kovidgoyal
Copy link
Owner

kitty's layout system does not really support fixed size windows, and in
more complex layouts such as the grid layout or the new splits layout
there is no way to have this at all.

In order to implement it one would need a "docks" system for the layouts
where you can have windows "docked" at the edges. Similar to how it is
done in tiling window managers. This is a fair bit of
work, since all layouts would have to modified for it, but should not be
too hard.

I'm not sure what you mean by the "window it was started from"? The
window that was active before you run the kitten in a new window? Hw are
you running the kitten, via launch?

Also taking a step back, is the reason you want to do this, rather than
using scrollback_pager because scrollback_pager does not allow live
searching of the output? Of course it could just be because it's cool :)

@trygveaa
Copy link
Sponsor Contributor Author

trygveaa commented Feb 23, 2020 •
edited

In order to implement it one would need a "docks" system for the layouts
where you can have windows "docked" at the edges. Similar to how it is
done in tiling window managers.

Right, yes, this seems like a good solution.

I'm not sure what you mean by the "window it was started from"? The
window that was active before you run the kitten in a new window? Hw are
you running the kitten, via launch?

Yes, the window that was active before I ran the kitten. I have mapped a key to new_window @ kitty +kitten search.py, so I'm running the kitten by pressing that key. Not sure if this is the best way, or if I could do it another way?

Also taking a step back, is the reason you want to do this, rather than
using scrollback_pager because scrollback_pager does not allow live
searching of the output? Of course it could just be because it's cool :)

There are multiple reasons:

  • Live incremental search
  • Typing less characters. In less you have to press /, then the search term, then enter. And you have to do this each time you want to change the search.
  • Being able to use the hints kitten after searching for some text. This is not possible when using scrollback_pager.
  • Scrolling to the last match automatically if it's out of view. With less you have to press N after searching if the search term is outside of the current view. I haven't implemented this in the kitten yet, but it's a goal.
  • Continuous search of live output is also a nice feature you get with this kitten.

kovidgoyal added a commit that referenced this issue Feb 23, 2020
@kovidgoyal
Allow passing the currently active kitty window id in the launch command
a82e45a 
See #2391
@kovidgoyal
Copy link
Owner

kovidgoyal commented Feb 23, 2020 via email

@kovidgoyal kovidgoyal changed the title Ability to open a kitten in a small window Support for docked windows in the various layouts at each edge Feb 23, 2020
@trygveaa
Copy link
Sponsor Contributor Author

trygveaa commented Feb 23, 2020 •
edited

Thanks!

Btw, you wrote @kitty_active_window_id and @kitty-active-window-id in the documentation and @active-kitty-window-id in the code.

@trygveaa
Copy link
Sponsor Contributor Author

@kovidgoyal: Do you think the docked windows should be for each of the inner windows, at the edges of each inner window. Or do you think it should be for the whole tab, at the edges of the tab/os window?

I started implementing docking to the edges of the tab, but then I realized that might not work well with the stack layout. One issue with it is that when moving to the next/previous window one would only be able to move to the docked window from the neighboring normal windows in the list of windows. Another potential issue is that the search kitten would probably need to change which window it searches in when one changes window.

The first issue could be solved by adding a new shortcut for switching between the docked windows and the normal windows, and let next/previous window only switch between windows of the same type.

For my search kitten, I think it would make sense to have docked windows for each of the inner windows if it only searches in that window, and to have docked windows for the whole tab if it searches in all the windows.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Feb 27, 2020 via email

@trygveaa
Copy link
Sponsor Contributor Author

  1. There can potentially be multiple docked windows per edge

Yes, I agree.

  1. Docked windows should not be resizable and probably should not be
    moveable

I agree that they should have a fixed size and not change when new windows are opened or the os window is resized, but shouldn't the user be allowed to resize them and change the order of the docked windows?

  1. Do we want per window/per tab docked windows or both? I would incline
    towards having both. The launch command can take a --dock-type argument
    which can take choices: tab-bottom-edge, window-bottom-edge,
    tab-top-edge, etc.

Yeah, both would be the best solution, it's just more work.

  1. What happens when a user tries to open an overlay window over a
    docked one? For example unicode_input or hints?

Not sure. If it's docked to a window, maybe we can open the overlay over both the window and the docked windows. If it's docked to the tab, I'm not sure. Maybe open it over the whole tab?

  1. How do we navigate between docked windows and normal windows using
    the keyboard??

I guess either they are included in the normal next/previous window list, or one can switch between the normal window and the docked with a specific key.

  1. If they are per window docks what happens in stack layout when
    changing windows? Do the per window docks get hidden too?

Yes, I think the per window docks should be hidden and the per tab docks should remain when switching between windows in the stack layout.

  1. Do the move to neighbor operations work over docked windows? I
    incline towards yes

I see four possibilities here when those operations are triggered from a docked window:

  • They move between windows of both types
  • They move between the docked windows in the same window
  • They move between all the docked windows.
  • They ignore the docked windows and moves to the next normal window when triggered from a docked window.

Which did you mean?

  1. With per window docks there should probably be a shortcut to
    easily switch between window and its associated dock. Maybe
    kitty_mod+tab

Sounds good. If there are multiple docked windows, I guess it should switch to the one that were last active?

  1. Do the switch to window by number shortcuts work for docked
    windows??

Probably not? I'm not sure.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Feb 28, 2020 via email

@kovidgoyal kovidgoyal mentioned this issue Mar 19, 2020
Closed
@trygveaa trygveaa mentioned this issue Apr 9, 2020
Closed
@kovidgoyal kovidgoyal mentioned this issue Jul 3, 2020
Closed
kovidgoyal added a commit that referenced this issue Aug 19, 2020
@kovidgoyal
Attempt to use the User Notifications API
2fafdae 
Apple are deprecating the usual Notifications API in favor of this
travesty, for Big Turd. It requires users to approve a local
notification from software they have explicitly installed!!

Apparently the macOS ecosystem is full of

a) developers that are stupid enough to spam their users with notifications
b) users that are stupid enough to not be able to block notifications
from applications they dont like, instead needing to grant permission
for a notification popup!!

Note that this commit is not functional, since as far as I can tell
on Catalina the permission request always fails with the very helpful
error message: "Notifications are not allowed for this application"
Presumably, the plumbing for allowing notifications will only be present
on Big Turd. And yes, I have tried it with a signed and notarized
(more Apple branded security theatre) application.

At this point I give up. I will simply implement #2391 someday and use
that to show notifications. So much for all the little control freaks
running around in the toilet bowl that looks like a spaceship.

I just wasted eight hours of my life on these fools.
@kovidgoyal kovidgoyal mentioned this issue Nov 14, 2020
Closed
@gregflynn
Copy link

Sorry for the necrobump here but I wanted to throw out a (possibly stupid) idea in this vein. This thread and the other dupe threads try to solve the "tmux status bar" feature request using kitty windows of a fixed size and fixed location within the window layout, which causes extra complexity in the layout code to account for these new fixed windows.

Would it be better/easier to implement this feature the same way visually we have the tab bar? For instance in a simple example, if i have the tab bar set to the top, and the space it would use if set to the bottom could render the status-line.

Some definite caveats I'll throw out:

  • Assumes/requires everyone's status-line to be a single line, less flexible than the window layout approach but do we need that flexibility?
  • What if i want both on top or bottom? we could punt on supporting this until someone asked but feels a little dirty, could 50/50 split the bar in that case or something else

@kovidgoyal
Copy link
Owner

Personally I'd rather fix this properly and with full flexibility, one and for all. Using an additional tab-bar might work ok for statusbar like displays but there are more use cases than that, and I dont want to end up building multiple solutions for it.

@kovidgoyal kovidgoyal mentioned this issue Apr 4, 2021
Closed
@kovidgoyal kovidgoyal mentioned this issue May 14, 2021
Closed
@kovidgoyal kovidgoyal mentioned this issue Aug 19, 2021
Closed
@trygveaa trygveaa mentioned this issue Apr 8, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gregflynn @trygveaa @kovidgoyal