RFC: Optional Scrollbar

chetgurevitch commented 7 years ago

@joehillen @tbodt @mattmahn

Seems there's some interest in a scrollbar so I figured I'd open an issue to keep discussion seperate from #657. I don't have a whole lot of knowledge in this area but I'm fairly certain a native implementation isn't possible, or at least that it would require a ton of changes to winit, possibly glutin and/or a new crate. Also native window decorations are broken in wayland and won't necessarily be getting fixed, so even if we did manage a native scrollbar somehow I doubt it'd work there.

Given the above I think we should work on the assumption that a scrollbar would have to be platform agnostic and implemented within alacritty.

rivertam commented 6 years ago

Now that scrollback has been implemented, I would like to see this RFC given some more attention. Any indicator that we're currently not at the bottom of the window or that there is scrollback history one could scroll through would be really nice, I think.

I think a very early version of this feature could just be changing the window title to include little details like [Scroll: 88%] or something. That said, that could already exist and I wouldn't know it because I hide the window title with i3.

I wouldn't want to click it or anything. Just an indicator would be nice. Right now, I don't know if I'm actually at the bottom of the window or not.

hook-s3c commented 5 years ago

maybe also a thumbnail map down the side like some IDEs have

b-fuze commented 5 years ago

This would be really nice. At the moment scrolling is taking too long and I'd like if I can just quickly scroll/skim through with a scrollbar.

nixpulvis commented 5 years ago

I wonder sometimes how much a ScrollToLastCommand action would help with a lot of my long scrolling TBH.

chrisduerr commented 5 years ago

Fyi I've looked into that and it's not possible to do that without modifying the shell.

nixpulvis commented 5 years ago

@chrisduerr yea, I guess so... Then I guess that's a shell feature I'd want. Though now we need a way to allow a shell to scroll the history.

chrisduerr commented 5 years ago

@nixpulvis iTerm does this and it requires both support from the shell (I believe they use some custom prompt command or something like that) and support from the shell.

So it's in no way a good solution from what I've seen. The only reason it works is because they have full control over the initial state the OS is shipped in.

nirfse commented 5 years ago

@chrisduerr Thank you for looking into this. While this is completely out of scope of current issue, maybe it'd be a good idea for consideration to experiment on at least some custom shell, e.g. rust-based Ion Shell (https://github.com/redox-os/ion).

flying-sheep commented 5 years ago

@chetgurevitch window decorations are (except from GTK land) pretty separate from GUI widgets, and since a while ago server side window decorations are a thing for wayland too.

So in order to get a native scrollbar, we’d have to use a cross platform GUI library like libui (and run into problems like libui not supporting Qt and therefore not being native in KDE Plasma).

But I think drawing our own scrollbar shouldn’t be too hard and if we’re sticking to a basic boxy style it wouldn’t look out of place. We could add mouse controls config since on different DEs, clicking on the scroll bar track either warps the scrollbar position there or just scrolls a page in this direction.

nixpulvis commented 5 years ago

There are two parts of a scrollbar I would consider to be fundamental.

The bar itself
The gutter it resides within

We'd need the bar to only appear when there is at least 1 line in the scrollback region. Dragging the bar would scroll, at first, a single line at a time, then multiple as the size of the scrollback region grows.

Clicking on the gutter region should probably scroll by pages. "Warping" the bar to the center of the place you clicked seems hard to predict, and for that reason I'd recommend not doing that. Instead, allowing the gutter to be clicked and held should provide roughly the same functionality, since once the bar reaches the mouse it could be designed so that it stops there.

There's a bit of a stylistic determination to be made for how much gutter space is shown when only one line is possible to scroll. I'd say it should be close to a square. Similarly I might argue that the bar itself cannot become much smaller than the same square size.

I've also seen nice scroll bars what are very narrow until you mouse over them. If done well this might be a good fit here, though generally I'm against dynamic features like this.

I'm not a fan of the extra clutter needed for arrows at the top and bottom, though it might be the only way to allow mouse interaction to always scroll by a single line. Do we care? It might be confusing, but I suppose they could only show up once dragging the bar will jump more than one line.

Food for your 2 cents.

flying-sheep commented 5 years ago

Clicking on the gutter region should probably scroll by pages. "Warping" the bar to the center of the place you clicked seems hard to predict, and for that reason I'd recommend not doing that.

That’s not our decision, it’s something to be configured on the DE level that we optimally conform to and at least allow to configure manually.

For GTK, the default is to warp on left click and scroll by pages on shift-left or middle click, and in Qt, the default is to scroll a page on left click and warp on middle click. I changed GTK’s setting for consistency:

$ cat .config/gtk-3.0/settings.ini
[Settings]
...
gtk-primary-button-warps-slider=false

samal-rasmussen commented 5 years ago

A scrollbar would be super nice, but I'd take a simple percent number indicator in the top right corner for now, just so I know how far back I've scrolled. Right now I just get lost if I try to scroll back.

NotAFile commented 4 years ago

It seems like this is really three issues. Or rather, there seems to be three reasons for people wanting a scrollbar, which maybe might be better addressed individually?

The first is people knowing how far away they are from of the bottom of the output to be able to find things within the scrollback. One solution here would be the ability to set "marks" on locations in the buffer and jump to them. If this is possible via escape sequences, people could easily insert it into their PS2 prompts to get the "jump to last command" functionality. I assume this is how the macos feature works?

The second thing, what I personally care about is, some ability to scroll faster. PgUp/Down does this, but you are loosing the velocity control offered by a scrollbar or mouse wheel. One possible workaround for would be the ability to press some keybinding, such as shift, to act as a scroll-multiplier. This works for me in vim, but alacritty does not seem to have any support for it.

A third thing I've personally used scrollbars for is detecting when new output has been written by a command while scrolled back. That might also be better indicated in some other way, such as a faint glow at the bottom of the screen.

kchibisov commented 4 years ago

@NotAFile

The second thing, what I personally care about is, some ability to scroll faster. PgUp/Down does this, but you are loosing the velocity control offered by a scrollbar or mouse wheel. One possible workaround for would be the ability to press some keybinding, such as shift, to act as a scroll-multiplier. This works for me in vim, but alacritty does not seem to have any support for it.

Oh, it seems like our docs don't mentions mention one thing about our bindings.

You can have multiple same bindings, so they'll be triggered all together.

for example I'm using this thing to scroll faster. (don't follow the idea of Ctrl + Key in shell, since it's not a good thing todo, but I don't use those keys anyway).

  - { key: Y,        mods: Control, action: ScrollLineUp,   mode: ~Alt       }
  - { key: Y,        mods: Control, action: ScrollLineUp,   mode: ~Alt       }
  - { key: Y,        mods: Control, action: ScrollLineUp,   mode: ~Alt       }
  - { key: Y,        mods: Control, action: ScrollLineUp,   mode: ~Alt       }
  - { key: Y,        mods: Control, action: ScrollLineUp,   mode: ~Alt       }
  - { key: E,        mods: Control, action: ScrollLineDown, mode: ~Alt       }
  - { key: E,        mods: Control, action: ScrollLineDown, mode: ~Alt       }
  - { key: E,        mods: Control, action: ScrollLineDown, mode: ~Alt       }
  - { key: E,        mods: Control, action: ScrollLineDown, mode: ~Alt       }
  - { key: E,        mods: Control, action: ScrollLineDown, mode: ~Alt       }

So basically it scrolls 5 lines. You can do the same thing with every action, keys, mods.

And for mouse we have https://github.com/alacritty/alacritty/blob/15cc07c069b09f109ed18fb94e02e9650be7fa33/alacritty.yml#L88

NotAFile commented 4 years ago

@kchibisov you're kind of misunderstanding what I mean in both cases.

I'm not looking to scroll faster via keyboard, PgUp is plenty fast. But a keyboard doesn't give me the speed control that dragging a scrollbar or turning a mouse wheel gives me.

I don't want to increase my base scroll speed either. The multiplier of 3 works fine for normal scrolling. But being able to increase that multiplier using a modifier, like in vim, would cover the things I currently wish I had a scrollbar for.

chrisduerr commented 4 years ago

A scrollback that can be dragged around is definitely out of scope of this project. The main reason why this issue is still open, because an indicatior to show position in the scrollback buffer is not completely out of question.

kchibisov commented 4 years ago

But being able to increase that multiplier using a modifier, like in vim, would cover the things I currently wish I had a scrollbar for.

You can't have scrollbar in vim anyway, since it should be handled by vim and not alacritty. The only thing where having scrollbar is possible is outside of alt-screen to scroll through your scrollback buffer, so it won't solve your vim problem.

KevinBuchs commented 4 years ago

I have been using Alacritty in earnest for about a month now. I do very much miss the scrollbar for going far back into my output. I am not understanding why it would need to be implemented in the shell. It can certainly be accomplished by a series of Page Ups. Alacritty is so darn fast that executing rapid fire pages ups would not take long, and they would certainly be faster than pushing Page Up 10,000 times.

Here is an alternative UI implementation that might make it more pleasing to implement. I don't need an actual scrollbar, but some way to indicate to scroll "this far" back. So, turn the full display area into a mouse click reader that scrolls proportional to how far up the vertical dimension of the display area I click. A command to activate this could be tied to a keyboard shortcut and it would be great. Just determine how many display pages fit in the total scroll back buffer and take the fraction proportional to click location and execute that many Page Ups.

chrisduerr commented 4 years ago

If it's just about scrolling to the top as quickly as possible, vi mode should be much quicker than a scrollbar.

KevinBuchs commented 4 years ago

Yeah, for me it is not scrolling back to the top. But scrolling back some fraction of the full scrollback buffer to find the command I last issued or somewhere in its output.

nixpulvis commented 4 years ago

I think the visual indication of where you are in the scrolling is actually really important, however it shouldn't clog up my screen when I'm not using it.

I also wish there was an easier way to scroll using the mouse sometimes, since pressing the wrong key can send you all the way back down to the bottom, it's often "safer" to just scroll using the mouse.

dancojocaru2000 commented 4 years ago

I just needed a scrollbar and, since Alacritty doesn't have one, here I am to add my input.

Especially in interactive-ish (line by line, think REPL) programs, where output is potentially long, a scroll bar to accurately and quickly scroll to the desired point feels essential.

mitar commented 4 years ago

Given that Alacritty is backed by GPU, we can do with scrollbar even more interesting things:

I would prefer that on the right there is always a small space where scrollbar goes, with empty if there is nothing to scroll. (Like 4 px wide, I anyway use 4px wide padding, so it would match well.)
When there is content to scroll, that space is filled with indicator of amount and location, the scroll bar.
As you move around (in Vi mode or using scrollwheel) the indicator moves as well.
If you hover over the scrollbar, it expands to the left and shows in fact a highly zoomed out map of the whole scroll buffer. Because we have GPU this could be simply minified version of the whole view backed by GPU. So one could quickly see an outline of the content and know where to scroll to. No more searching up and down to find something. Sublime has something like that.
During search, in that map also all places where the search term have been found would be highlighted. So you could have an overview of that as well (if you hover over the scrollbar).

Titaniumtown commented 4 years ago

I would really love for alacritty to get a scroll bar! That's the one feature that I wish alacritty had, because it can get super annoying when you have to scroll manually to find something a long way back. Hope this gets added!

soanvig commented 4 years ago

The main issue is user doesn't know where he is in the scroll buffer. Whether it's on top, bottom, middle, how much there is to scroll, and so forth

Some optional map of buffer would be interesting addition on the side of a window would solve these problems. It can be visual non-draggable bar, or a full-featured preview with tiny letters.

Bug-Reaper commented 4 years ago

Is there a specific rust library for GUI scroll bar we’d want to use here? Where could we hook the initialization of said scroll bar. Where can watch the console text buffer?

up-to-you commented 4 years ago

It seems that this issue is a candidate to pin, according to its popularity and scrollbar demand. The point of disagreements and different opinions about scrollbar is that some approaches can involve window management layer of abstraction. However, i think, it could be implemented as a simple TUI-like bar rendering, as a native solution in alacritty.

jberryman commented 3 years ago

I wonder sometimes how much a ScrollToLastCommand action would help with a lot of my long scrolling TBH.

Fyi I've looked into that and it's not possible to do that without modifying the shell.

Presumably you could use a heuristic that treats "last command" as the line after some pause of N ms of output. Or the point the user last input text, if that's available to alacritty. Or a configurable string that exists in the user's prompt. All would get 99% of the way there.

rumpelsepp commented 3 years ago

As alacritty might mostly be used with tmux or screen, what's the value of a scrollbar? It's pretty much useless.

eternal-sorrow commented 3 years ago

@rumpelsepp not everyone uses screen or tmux.

rumpelsepp commented 3 years ago

Then how do you even use this terminal emulator as it does not support tabs, etc.? That's a serious question.

eternal-sorrow commented 3 years ago

Use multiple windows of it?

rumpelsepp commented 3 years ago

Well, I see this quickly becomes offtopic and goes into the personal preference corner. I am fine as long as its optional.^^

dancojocaru2000 commented 3 years ago

I wonder sometimes how much a ScrollToLastCommand action would help with a lot of my long scrolling TBH.

Fyi I've looked into that and it's not possible to do that without modifying the shell.

That shouldn't really be a problem. As far as I know, other terminal emulators handle this by asking the users to modify their shell prompt to output a certain custom escape sequence. That way, the terminal emulator can mark the line where that escape sequence was used as a line where the command was executed.

eternal-sorrow commented 3 years ago

modify their shell prompt to output a certain custom escape sequence

this can also be used to notify user when the long running command is completed

rumpelsepp commented 3 years ago

I do it this way:

$ long_running_command; notify-send "I am done"

dancojocaru2000 commented 3 years ago

I do it this way:

$ long_running_command; notify-send "I am done"

That one is certainly not a cross platform solution, although that's also beside the subject of this issue.

Though using that escape sequence in the prompt would indeed be a good marker for when a command is finished.

rumpelsepp commented 3 years ago

I am not a fan of this suggestion. Outputting custom escape codes from my shell prompt sounds awkward. Further I need to setup this stuff for all machines I am using… What's wrong with searching for the last shell prompt via the builtin search functionality? Takes 2 seconds.

dancojocaru2000 commented 3 years ago

You are welcome to use that if it's convenient for you.

Nobody would force you to change your shell prompt if the current solutions available are satisfactory. That would be an opt-in improvement for those who need it.

rumpelsepp commented 3 years ago

I better jump out of this discussion now, as I am a) not the maintainer of this project und b) I probably would reject everything in here. :) So sorry for my disturbance!

cocoonkid commented 3 years ago

+1

magnus-ISU commented 3 years ago

I've been working on this for a couple hours and I have something to show for it.

https://user-images.githubusercontent.com/75949275/129661480-322cc7c0-78ec-4d98-aa96-5e20f697dcfe.mp4

It is obviously nowhere near ready, even ignoring that I don't have a GUI figured out either (once you highlight something, attempting to scroll will automatically highlight stuff for evermore) but there is one glaring issue that I think I should ask about now, early on. Both left and right mouse buttons are used for highlighting stuff, and they work in different ways (right mouse button will expand a selection, left mouse button will create a new one). Selecting lots of output can be useful. But there are only two mouse buttons, so I'm not sure what exactly scrolling should be bound to, which would make sense and not make it more annoying to select something in some situations.

I toyed with the idea of holding both mouse buttons would trigger this, and continue any selection you had already started (or not select anything if you hadn't), but realized that on a laptop for example that holding both mouse buttons is not always easy.

To give some more information, I intend to create an overlay on the right-hand side of the terminal which, while you are scrolling with this, would show your relative position in the scrollback (to the top and bottom, if they are close enough) as well as offering a sort of preview of the file like (but just rendered with rectangles for occupied/free cells, not a tiny font like someone postulated above). I am also not experienced with GUI programming, so I have no idea how to do this yet, but I imagine I will be able to figure it out.

I like that this feature leaves the terminal exactly the same when you aren't using it, which a 4px scrollbar on the side wouldn't for example. Though it doesn't fulfill either the first or the third utility of a scrollbar that @NotAFile discusses, so maybe it isn't the best solution.

magnus-ISU commented 3 years ago

Because I was curious, I tried implementing both-mouse-buttons-to-initiate-scroll and it was pretty easy and fixes all the issues with selections I mention above. But it may have accessibility issues, so I'm not sure if it is the solution.

Though I am now thinking that pressing a keyboard modifier + single mouse might be a good solution too, and you could just have it so as long as 2 keys are pressed that you configure, then it will start scrolling. Which would allow people to configure it pretty much any way they want, either LMB+RMB as the two keys or put ctrl+RMB in the config twice, or put a keyboard shortcut, or anything.

Invertisment commented 3 years ago

Reply to https://github.com/alacritty/alacritty/issues/775#issuecomment-580895339. I was used to use scrollbar in mate-terminal but I found that this one has page-up commands (in this config Ctrl+Shift+K would go up a page):

  - { key: J, mods: Control|Shift, action: ScrollPageDown }
  - { key: K, mods: Control|Shift, action: ScrollPageUp }

As I prefer keyboard I think I'll use these. The scrollbar would be useful for seeing where but not as much. Also ScrollToLastCommand would be great as well.

Edit: You already have a scroll bar. Step 1: toggle VIM mode with Ctrl+Shift+Space Step 2: top right corner shows the position in the terminal: [29/1559] Step 3: Use my config of page-up with Ctrl+Shift+K Awesome! The only thing that could be even better would be to get that number pop up when you have scrolled anywhere else except bottom (but that may interfere with copying, but that's another story).

jturcotte commented 3 years ago

Awesome! The only thing that could be even better would be to get that number pop up when you have scrolled anywhere else except bottom (but that may interfere with copying, but that's another story).

I have been testing this change locally for quite a while and it works pretty well, no issue with copying. Is this worth in a pull request?


diff --git a/alacritty/src/display/mod.rs b/alacritty/src/display/mod.rs
index cce3c8bd..8c355be5 100644
--- a/alacritty/src/display/mod.rs
+++ b/alacritty/src/display/mod.rs
@@ -548,6 +548,9 @@ impl Display {
         } else if search_state.regex().is_some() {
             // Show current display offset in vi-less search to indicate match position.
             self.draw_line_indicator(config, &size_info, total_lines, None, display_offset);
+        } else if display_offset != 0 {
+            // Also show the current display offset if the user scrolled.
+            self.draw_line_indicator(config, &size_info, total_lines, None, display_offset);
         }

         // Push the cursor rects for rendering.

darkguy2008 commented 2 years ago

Hi, I just changed my terminal from Gnome Console to Alacritty (mostly due to the speed and customization options, that the new Gnome Console lacks) but then again I also find that, even though Alacritty is "powerful", it's missing something very basic and core of any app that has scrolling elements: A scrollbar indicator.

To add my use case, when looking at logs, I'd like to see how far I am from the bottom, and actually use it to drag the contents to view other parts of whatever I'm looking at in the terminal. Not having such indicator has been a really bad UX for me because first I have to use the scroll wheel a lot to get to the bottom, and then scroll up again, to somehow orient myself in the scroll area (and no, please don't suggest any weird keybindings or to use the keyboard, we're in 2022 and the mouse is as important as the keyboard).

It baffles me that the PR above ( #6001 ) was closed with a " There is no desire to always have the line indicator visible when scrolled into history. ". Well, that might be your desire, but this issue speaks for 100+ people, including myself and judging by the "likes" and activity of this issue that I stumbled upon when doing a Google search for "alacritty scrollbar" and this one popped up first in the search results.

I think this is an indicator that having a scroll bar is really important - if not a basic, core feature - for a terminal. I might be beating a dead horse here though, and the feature is actually implemented but hidden somewhere in the settings (I couldn't find it though) so any guidance, or at least insight on when this feature is planned to be developed/released, is appreciated.

Thanks!

Invertisment commented 2 years ago

Scroll wheel... Try adding this to your config:

## Line up/down
map alt+k scroll_line_up
map alt+j scroll_line_down

# Page up/down
map alt+u remote_control scroll-window 25- # 25 lines
map alt+d remote_control scroll-window 25+ # 25 lines
map alt+shift+u scroll_page_up
map alt+shift+d scroll_page_down

Also there is selection mode which I don't remember how to enable because since I started using these key bindings I don't need the indicator.

darkguy2008 commented 2 years ago

@Invertisment will that add a scrollbar indicator I can drag using my mouse or use as reference, like this? Because this is what I'm looking for and what I think this issue is related to - otherwise, maybe I should create a new issue?

MrBruz commented 1 year ago

It's been 5 years. Please give us a bloody scrollbar. It's a standard feature and if you disagree just don't enable it in your config.

dancojocaru2000 commented 1 year ago

@Footsiefat I'd like a scroll bar as well, but this attitude will never get you anything. It's just toxic.

This is an open source project and, unless the author owes you some money or something, there is absolutely zero obligation for anyone to add features you want.

Arguing for why the feature would be useful is all well and good. But demanding stuff is a sure way of never getting it. Want something enough that you demand it? Code it yourself and make a pull request.

alacritty / alacritty

RFC: Optional Scrollbar #775