GNOME Bugzilla – Bug 392551
Disassembly window has a huge scroll bar length
Last modified: 2020-11-06 20:22:14 UTC
Scrolling through 0x00000000 to 0xffffffff address space via the scrollbar in disassembly view is very painful. Introducing bookmarks would help somewhat, but the issue of the scrollbar on the right of the window being useless is still there. One idea is to have two scrollbars. one page scrollbar and another address scrollbar (the normal editor scrollbar). Page scrollbar would move the view area (page) in the address space in steps of page and address scrollbar would act normally to scroll through the current page. The page scrollbar can be a widget that would look like a scale (marked with memory addresses) with a rectangular shading that could be dragged along the scale. This scrollbar can stay on top of the disassembly window. Just like what F-spot has with its 'years scrollbar'. I think the same widget can be used too. http://f-spot.org/Image:Main-window.png Since the left scrollbar would have a reasonable range (the size of a page), scrolling (either via mouse or scrollwheel) would be more meaningful and controllable. if the user scrolls past the begining or end of the scrollbar, it can automatically advance or retreat the page scrollbar by 1 unit and wrap itself to the other end -- giving a continuous scrolling.
I don't use the scrollbar to go to a particular place because it is not precise enough especially in the disassembly window. The disassembled instruction depend on the address, most of the time you don't get the same instruction for address A, if you start disassembling at A or A - 1. Currently, the right way to move in this window is to use the Goto dialog in the context menu, because you can be sure that you start at the beginning of a real instruction (in my test, I have used eip value). I think we need to add other ways, allowing to go to the beginning of each label, going to the instruction corresponding to one source code line and so on. Then, I don't see a need to go farther than a few pages from the initial address. In this case clicking on the scrollbar to move page by page or on the arrows to move line by line is enough I think. The scrollbar is not completely useless. I'm agree that dragging the cursor in the scrollbar is currently useless but I do not see a need for this. I don't really like your two scrollbars idea, it will take more space and I find this split a bit artificial. Instead, I can propose: A zoom: I display only one line every 64Kb of data and this can be changed using the context menu. I'm afraid it will be a bit complex to use. A non linear scrollbar: I can use half of the scrollbar to represent address near and reserve the other half for the remaining address. I find the idea interesting but it could be a bit strange to use. In order to find more ideas, in which situation do you think it will be useful to drag the scrollbar ?
(In reply to comment #1) > I'm agree that dragging the cursor in the scrollbar is currently > useless but I do not see a need for this. > That's exactly my point. If you use keyboard up/down/pageup/pagedown, then the scrolling is fine and usable. But since scrollbars are supposed to be an alternate way to scroll the view using a pointing device, it made sense to make it also usable. Otherwise, we might as well keep it hidden (not presenting the user a UI element that is not usable). > I don't really like your two scrollbars idea, it will take more space and I > find this split a bit artificial. Instead, I can propose: > Okay, I don't either :). > A zoom: I display only one line every 64Kb of data and this can be changed > using the context menu. I'm afraid it will be a bit complex to use. > Not sure how the view would be usable in zoomed mode. > A non linear scrollbar: I can use half of the scrollbar to represent address > near and reserve the other half for the remaining address. I find the idea > interesting but it could be a bit strange to use. > Yes, sounds like an interesting idea :). You can try it out. > In order to find more ideas, in which situation do you think it will be useful > to drag the scrollbar ? > As I explained, the scrollbar is a UI element that has a very well defined function. We should either make it work right or not show it at all. Here are a few more suggestions: 1) Hide the scrollbar completely. Let the user use keyboard or scrollwheel to scroll the content. 2) If you will miss the (functional) clicky parts of the scrollbar, just have two buttons in the scrollbar for page up/down. Or 4 buttons: pageup/lineup/linedown/pagedown buttons. .. No draggable bar. 4) Use a velocity scrolling. It's not entirely uncommon UI element. Some applications that can not be properly scrolled in linear way use such approach. Basically, your draggable bar always stay in the middle. Depending on how far the user drags it from the middle, the scrolling happens at that speed. Releasing the drap brings back the bar in middle.
> > A non linear scrollbar: I can use half of the scrollbar to represent address > > near and reserve the other half for the remaining address. I find the idea > > interesting but it could be a bit strange to use. > Yes, sounds like an interesting idea :). You can try it out. Ok, I will try this. > 1) Hide the scrollbar completely. Let the user use keyboard or scrollwheel to > scroll the content. No, I'm still clicking on it and I like the look of this scroll bar. > 2) If you will miss the (functional) clicky parts of the scrollbar, just have > two buttons in the scrollbar for page up/down. Or 4 buttons: > pageup/lineup/linedown/pagedown buttons. .. No draggable bar. If I cannot find a better solution, this will work. > 4) Use a velocity scrolling. It's not entirely uncommon UI element. It can be interesting too, I will try this too. All this need some test, I will correct the easy bugs first.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/anjuta/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.