Options for padding around the tab bar - Final #3685
Conversation
Remove changes to DO NOT EDIT files added automatically generated files Working again, final commit
|
I am wanting this feature as well; however, it has a few issues. I cloned your repo and tested as follows:
before:
after:
|
If you have the skill, could you try to fix these issues yourself? I'll be working on them simultaneously, but I can't work well on a bug I can't replicate EDIT: I looked into expanding the clickable area, and it would be nontrivial to implement. Currently the margin height is implemented by pushing the tab bar down or raising it up, depending on whether the tab bar is on the top or bottom edge. On the bottom the extra height is below the tab bar, part of the tab bar, while on the top the extra height is above the tab bar, that is, not part of the tab bar, but before it. I'll still keep looking for a way to get around this, but I spent a lot of time in this part of the code and don't know of another way to do it. Plus, having the clicking functionality relegated correctly to the tab bar text isn't apparently a bad thing. If I had more knowledge of the tab bar itself, that is, knew how to add padding in the tab bar before the tab bar text itself, I may be able to do it (expand the clickable area) |
|
Pretty sure I just fixed your fullscreen issue, will you try it and let me know? At any rate, having another set of eyes is always good for these things, maybe you can figure out about extending the clickable area? |
|
I have confirmed your changes have fixed the full screen issue. Unfortunately, I don't have time to dig into the source code myself to look into the extending the clickable area. One thing that is odd though is that the clickable area does indeed extend to the bottom edge of the OS window when the tab bar is at the bottom. Its only when the tab bar is at the top that the clickable area does not extend to the top edge of the OS window. Should be consistent IMHO. How difficult would it be to not just have padding between the tab bar and the edge of the OS window but also on the other side? i.e., have padding on both sides of tab bar?
I want it spaced out little. Though what I want can be somewhat achieved using |
|
For the click area, as I said above:
Basically, I didn't edit the clickable area, I don't know how to. It working correctly when on the bottom edge is just a side effect.
As for the padding on both sides of the bar, I should be able to implement that and am working on it right now Some help from a maintainer may give the needed push in the right direction for the click area, but as for now (once I get the padding on both sides feature in) I'll go ahead and call it complete |
|
Note that for clickable area, relevant code is in mouse.c |
|
Is there an easy way to set up an option like the window_padding_width that takes in multiple values at the same time? I think it would be cleaner to do like I have looked in mouse.c but I couldnt seem to find something relevant to what I need, and nothing about making clicks outside of the tab bar (above/"before" it). The most relevant piece I saw is window_for_event, which points back to os_window_regions in state.c -- but no way to add the clickable padding between the os window top and the start of the content for the tab_bar. My looking into mouse.c has circled back to os_window_regions, the function I was editing in the first place. This suggests that I've been editing the clickable areas the whole time -- still I don't know how to add the clickable padding to before/above the text? Almost done with the inner and outer padding |
|
On Fri, Jun 04, 2021 at 09:29:14AM -0700, jsphnecclia wrote:
Is there an easy way to set up an option like the window_padding_width that takes in multiple values at the same time? I think it would be cleaner to do like `tab_bar_margin_height 19.0 22.0` or something rather than
```
tab_bar_margin_height_outer 19.0
tab_bar_margin_height_inner 22.0
```
Define a parser for it in kitty.options.utils named
tab_bar_margin_height, see for example
box_drawing_scale() have it return a tuple of two floats.
The define the two float fields for this in the Options struct in
state.h
The in to-c.h define a converter function named tab_bar_margin_height,
to convert this tuple to those two fields.
Finally in options/definition.py set ctype='tab_bar_margin_height' and
option_type='tab_bar_margin_height' and run ./gen-config.py
I have looked in mouse.c but I couldnt seem to find something relevant for changing the clickable area, and nothing about making clicks outside of the tab bar (above/"before" it). The most relevant piece I saw is window_for_event, which points back to os_window_regions in state.c -- but no way to add the clickable padding between the os window top and the start of the content for the tab_bar. My looking into mouse.c has circled back to os_window_regions, the function I was editing in the first place. This suggests that I've been editing the clickable areas the whole time -- still I don't know how to add the clickable padding to before/above the text?
Yes you need to make sure the tab bar region returned bu
os_window_regions includes your padding and then the mouse evets should
be automatically handled.
|
|
Could you take a look at my os_window_regions code? I feel like I'm doing what youre suggesting (like when I set the padding through |
|
@salmankhilji see if the latest merge works how you wanted. Use the settings tab_bar_margin_inner and tab_bar_margin_outer |
|
I just implemented it myself, less work than reviewing your code, but thanks for the implementation, it helped guide me. Note I dropped the retain option, as I dont much see the point of it. |
|
The retain option is pivotal for me. Without it there's no way to set the padding of the top of the window to the prompt (when there are not enough tabs to activate the tab bar) that doesn't have unexpected side effects when the tab bar activates. (Really the pivotal option would be 'min_tab_margin_height', 'retain_tab_bar_margin_height' was a work around to get what I think would be the most common use of the 'min_tab_margin_height' option, that is, say if you have a tab_bar_margin_height.outer of 19.0, the min_tab_margin_height would take the value of 19.0. A more customizable min_tab_margin_height would be better, though.) 'min_tab_margin_height' would be an option for padding between the top of the window and the padding specified by window_padding_width/window_margin_width. It 'takes the place' of the tab bar when the tab bar is not hidden, but also not yet activated by the requisite amount of tabs.
This is ok: but if you want to add padding between the top of the screen and the prompt you would use window_padding_width. However, window_padding_width means different things in different places. You come across this difference often when opt.tab_bar_hidden is false and min_tab is set. When there is no tab bar it is between the top of the screen and the prompt -- but when the tab bar is present, window_padding_width is between the tab_bar and the prompt, as opposed to the top of the screen and the tab bar, which is what you might expect. Instead that area is defined by tab_bar_margin_height.outer. If you try to add padding with the tab bar gone, you end up with something like this:
Sure there's padding without the tab bar, but this padding translates to a messed up, bloated tab bar when it does activate.
This is better: It is usable/beautiful with both one/no tabs and with tabs amounting to above min_tab. The top of the window is coherent. It's pretty. It's functional. It is what I set out working on this feature to achieve. It's definitely a feature worth adding in to the app, and, After spending so much time on this feature, It would really suck to have to patch it in manually every time I update the app. I definitely think that I could not be the only user who would use such a feature. (Also where the meaning of |
|
I dont follow, simply set tab_bar_min_tabs to 1 that way the tab bar will always be present and you can use the new options to control the padding. Nor do i understand why you would want padding between the top of the contents and the top of the OS Window, but not want it between the top of the contents and the bottom of the tab bar when it is visible. |
|
In the case where you want the tab bar to be invisible for one tab set the inner tab bar margin to 0 and use window padding with an outer tab mar margin. That way you get the same gap between the top of the window and either the shell or the tab bar regardless of whether it is visible. |
|
It doesn't make sense to have a tab bar of one (especially when decluttering is a goal), and sometimes min_tabs may be set for higher than one or two in normal use anyway. It's not that I want padding between the top of the contents and the OS window and not the top of the contents and the bottom of the tab bar, it's that I want different padding between the two. Like in my second set of images above - I want that 27.0 (27.0 window_padding_width) point padding on the left, but not the 36.0 (19.0 tab_bar_margin_height_outer + 27.0 window_padding_width) padding in the tab bar on the right. Instead (in the last set of images) I want the 27.0 (8.0 window_padding_width padding + 19.0 min_tab_margin_width) on the left and 27.0 (19.0 tab_bar_margin_height.outer + 8.0 window_padding_width) on the right. I don't think I was able to get your 'invisible tab bar' effect to work, and I don't think thats what I'm thinking of anyway: Here the tab bar is also bloated and ugly. Again the margin on the left has a different semantic meaning than the difference on the right. Again, there's no way to set the padding of the top of the window to the prompt (when there are not enough tabs to activate the tab bar) that doesn't have unexpected side effects when the tab bar activates. It is a subtle difference but it carries a lot of weight. It makes sense to add the min_tab_margin_height to our update containing a set of different tools for managing the tab bar. |
|
On Sun, Jun 06, 2021 at 10:15:57AM -0700, jsphnecclia wrote:
It's _not_ that I want padding between the top of the contents and the OS window and not the top of the contents and the bottom of the tab bar, it's that I want _different_ padding between the two. Like in my second set of images above - I want that 27.0 (27.0 window_padding_width) point padding on the left, but not the 36.0 (19.0 tab_bar_margin_height_outer + 27.0 window_padding_width) padding in the tab bar on the right. Instead (in the last set of images) I want the 27.0 (8.0 window_padding_width padding + 19.0 min_tab_margin_width) on the left and 27.0 (19.0 tab_bar_margin_height.outer + 8.0 window_padding_width) on the right.
You are saying you want more space between content and OS window margin
and less space between content and tab bar. My question is WHY?
You are just arbitrarily deciding one looks ugly and one doesnt.
I don't think I was able to get your 'invisible tab bar' effect to work, and I don't think thats what I'm thinking of anyway:
<img width="664" alt="Screen Shot 2021-06-06 at 11 45 54 AM" src="https://user-images.githubusercontent.com/51343659/120932776-c8350000-c6bc-11eb-860b-7b00791fcd59.png">
Here the tab bar is also bloated and ugly. Again the margin on the left has a different semantic meaning than the difference on the right. Again, there's no way to set the padding of the top of the window to the prompt (when there are not enough tabs to activate the tab bar) _that doesn't have unexpected side effects when the tab bar activates_. It is a subtle difference but it carries a lot of weight.
It makes sense to add the min_tab_margin_height to our update containing a set of different tools for managing the tab bar.
Where the one setting of the padding looks right, in another place the padding looks wrong. This points to the fact that the one setting should actually be separated into two settings. This is a feature that is trivial to add, and it makes our set of tab bar margin tools complete. I will be adding this feature for myself, but that's no fun for updates and is a really sucky way to end the past few months where I've been working on this feature (I sunk a lot of time working on this), when I'm sure that others would find a use for it as well. I hope you will reconsider and add the feature, if not by the points I made then by the strength of belief in which I made them.
Sorry it doesn't make sense to me. And I am yet to hear from anyone else
that says they want this feature. And no, whatever time you spent on
this feature was for YOUR benefit, not mine. I spent a whole bunch of
time guiding you and helping you, to the extent of actually implementing
it for you, for something that is utterly useless to me. It doesn't
obligate me to add what I feel is pointless bloat.
Take a step back. You basically want this because it looks nice to you to
have a smaller gap between the content and the tab bar than between the
content and the outer window margin. I really dont see why that makes
sense.
I have yet to be convinced that setting the tab bar outer margin and
window padding to the same value and tab bar inner margin to zero looks
ugly.
I think you are confusing the semantics of window_padding_with. window
here refers to kitty windows, more than one of which can be in a single
tab. They are not about defining the spacing between the border of the
*OS Window* and the content in it.
What you really want is to be able to define padding for *OS Window*.
This will let you specify the space between the borders of the OS Window
and *any content* inside it. And then you can independently specify the
spacing between the tab bar and content below it using the setting I
just added.
And this makes sense to me. I am willing to merge a patch that adds a
new setting: os_window_padding_width modeled on window_padding_width.
With this setting you will get the effect you think looks nice by
setting os_window_padding to X for the top edge and tab bar inner margin
to Y. X wil be the spacing between the content and the os window border
when the tab bar is hidden and Y will be the spacing between the content
and the tab bar when the tab bar is visible.
And this will make it possible to implement #3683 as well
|
I don't think arbitrary is the right word. It's an aesthetic difference that is hard to explain
Basically, yes, but I don't think I'm the only one who would think so/prefer the option.
With aesthetics it is often hard to describe why something looks off or ugly, like it was hard to explain why a tab bar with a little padding from the top was better than one with no padding. I mentioned things being ugly here because I expected you to see what I see without needing the explanation, which falls short of and is less powerful than experience. I will try to explain but it comes down to a gut feeling:
I could list more but I hope now you see that my thinking is not arbitrary. I'd like to mention again here what I said above: There's no way to set the padding of the top of the window to the prompt (when there are not enough tabs to activate the tab bar) that doesn't have unexpected side effects when the tab bar activates.
I meant that while no one would think to ask for this feature, if it were added people would stumble upon it when configuring their tab bar and be like "I didn't know I needed this" and use it.
I am not saying the time I sunk was for your benefit, that's not what I meant at all. It most certainly was for my benefit, I learned a lot, I figured out a lot. I am very thankful for your help over and over again with the whole project - I was almost done with my implementation when you finished it for me. It meant a lot to me. I want to share what I worked on with everyone else. I'm unclear what you're referring to as pointless bloat -- Is that just
I am not sure if that's what I'm going for or not, plus that's the start of a whole new project. Anyway - you can see now that my thinking is not arbitrary, but has a lot of reason behind it, and I hope you will rethink the inclusion of min_tab_margin_height. With the inclusion of min_tab_margin_height, there would be a sensible way to add padding however large at all states of the process:
I mainly wanted to address this point of yours:
I gave my why and explained my decision process. Now I'll leave it to you. I understand if you don't see it this way, it's your project. and I don't mean to 'fan the flames' of this discussion with this long post, but I just had to try to offer an in-depth explanation of the way I see it, in the hopes that you might see it that way too. If not, oh well. Sincerely, thank you, for making this program and maintaining it and everything, and especially for the time you spent helping me out. Cheers for tab bar margin! |
|
Sorry, no, I am not going to add min_tab_bar_height. I am willing to add
os_window_padding however as it takes care of your requirements and also
another persons, killing two birds with one stone.
And no you don't need to send the PR for it, I will get around to it when
I have the time.
|
See 3436 and 3684
Adds options for padding/margin around the tab bar.