-
-
Notifications
You must be signed in to change notification settings - Fork 956
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.
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
Support for docked windows in the various layouts at each edge #2391
Comments
kitty's layout system does not really support fixed size windows, and in In order to implement it one would need a "docks" system for the layouts I'm not sure what you mean by the "window it was started from"? The Also taking a step back, is the reason you want to do this, rather than |
Right, yes, this seems like a good solution.
Yes, the window that was active before I ran the kitten. I have mapped a key to
There are multiple reasons:
|
So the way to do this would be to use launch rather than new_window
https://sw.kovidgoyal.net/kitty/launch.html
this is the new unified command for all kinds of child process
creations. You can see its implementation in launch.py
I have just implemented support for passing the id of the active window
in it.
…On Sun, Feb 23, 2020 at 05:24:11AM -0800, Trygve Aaberge wrote:
> 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.
> 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 you get with this.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#2391 (comment)
--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
Thanks! Btw, you wrote |
@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. |
Well there are several things to think about:
1) There can potentially be multiple docked windows per edge
2) Docked windows should not be resizable and probably should not be
moveable
3) 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.
4) What happens when a user tries to open an overlay window over a
docked one? For example unicode_input or hints?
5) How do we navigate between docked windows and normal windows using
the keyboard??
6) If they are per window docks what happens in stack layout when
changing windows? Do the per window docks get hidden too?
7) Do the move to neighbor operations work over docked windows? I
incline towards yes
8) With per window docks there should probably be a shortcut to
easily switch between window and its associated dock. Maybe
kitty_mod+tab
9) Do the switch to window by number shortcuts work for docked
windows??
…On Wed, Feb 26, 2020 at 02:13:10PM -0800, Trygve Aaberge wrote:
@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.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2391 (comment)
--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
Yes, I agree.
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?
Yeah, both would be the best solution, it's just more work.
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?
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.
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.
I see four possibilities here when those operations are triggered from a docked window:
Which did you mean?
Sounds good. If there are multiple docked windows, I guess it should switch to the one that were last active?
Probably not? I'm not sure. |
On Thu, Feb 27, 2020 at 08:15:01AM -0800, Trygve Aaberge wrote:
> 2) 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?
I think that's unnecessary complication, docks are typically used to
display fixed information. There is no need for them to be resizable.
You could potentially make them moveable, but then you have to deal with
not just re-ordering but also changing edges/moving from per tab to per
window, etc. Simpler to just have them fixed.
> 4) 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?
This will require some experimentation, I dont know what is feasible off
the top of my head. In the docked to window case, using the window is
obv fine. In the docked to tab case, it might actually be better to open
overlay windows as new normal windows.
> 5) 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.
There is also the use case of a statusbar type dock window which should
not be able to receive focus and be excluded from navigation.
> 7) 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?
If we allow dock windows to be re-orderable then between dock windows
and possibly changing edges. Otherwise no-ops.
> 8) 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?
Yes, last active would be most useful I think.
> 9) Do the switch to window by number shortcuts work for docked
windows??
Probably not? I'm not sure.
Not a strong preference here, we'll see.
…
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2391 (comment)
--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
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.
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:
|
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. |
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](https://user-images.githubusercontent.com/601966/75110661-1261b180-5631-11ea-958e-1b3d885746a2.gif)
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
The text was updated successfully, but these errors were encountered: