Menu
▾
▴
#1197 Scroll with Middle Mouse Button
open
2
2019-10-26
2017-08-16
No
Hi folk, why scintilla/scite does not have yet document scroll with Middle Mouse Button?
Please add this feature.
Here an example with a text editor (is not based on scintilla)
blob:http://imgur.com/1a0fcc24-e662-4cf4-b4be-dfa4220f66e5
Sorry, i shared wrong link, here the example:
http://i.imgur.com/vfJNaan.gif
Document scrolling is unpleasant, making the text scroll around wildly when the middle mouse button is accidentally pressed.
If anyone really thinks this is a good idea and contributes an implementation, it should be optional.
Hi. I've just added something much like this to my personal fork. Here's the diff.
And this is what it looks like over here:
Hope that this is a good compromise. Cheers!
P.S. It seems to also demonstrate a bug? I.e. if you put your cursor over a word and then e.g. click on a scrollbar arrow, it will scroll but also highlight all those word...
It isn't implemented as an option.
I can't work out how to download a text diff from GitHub to apply it.
Just append ".patch" at the end of the URL, e.g.
https://github.com/dejbug/scintilla-for-kronotope/commit/19c2e779a08ef343ff398e566d885add08923bb9.patch
Thanks Colomban! I should have posted the direct url.
Neil, welcome back from beautiful Scotland. I shall add a boolean and
paste the link to a new version of the patch. I'll look into adding
the SCI_ stuff,. Maybe SCI_FINGERSCROLL? Or whether there's another
option that could be sensibly extended.
Didn't quite anticipate that somebody might want to disable such an
awesome little feature!
Hi. So here's the complete patch. I'm posting from gmail, hope this works.
P.S.
I've had a couple issues with the scripts on my windows box which I'm
not sure you'd consider bugs.
First, there's FileGenerator.py's 'lineEnd' correction logic. Should
it really create different output depending on the host OS?
Second, APIFacer.py seems to have a rather gratuitous requirement for
Python 3+. Rewroting line 30 it to this:
unicode(characterPrevious).isnumeric() and unicode(characterNext).isnumeric())
makes it work with Python 2.7 just fine. There is a method
'IsNumeric(s)' in the script which seems to have been meant to address
this?
line endings for FileGenerator has a separate issue at [feature-requests:#1294].
Related
Feature Requests:
#1294Thank you Zufu,
the issue reads closed but I would really like to make it keep the
line ending it finds in the file. In addition I could rewrite the
script to take arguments, in case one wants to override this.
Attached is a cleaned up version of the patch, excluding everything
secondary to the actual feature. I'm slowly getting the hang of this.
Cheers!
On 10/16/19, Zufu Liu zufuliu@users.sourceforge.net wrote:
Related
Feature Requests:
#1294We should add horizontal scrolling for non-wrap mode as well, shouldn't we?
Making this feature a lot more useful.
I'll get to it asap. I'm working on "fixing" bookmarks right now, so that
jumping to one will (try to) restore the exact view. It will reduce jet-lag.
That is not how browsers implement middle button scrolling where the middle-click selects a scrolling mode that continues after mouse up and moves up or down depending on whether the mouse position is above or below the initial click. The mouse cursors associated with this are dot with up arrow or dot with down arrow depending on direction like the first reply video. There may be an initial (or continuing) cursor on click of a circle containing a dot with an up and down arrow.
Scrolling like a touch screen is a different thing. A problem with the contributed implementation is that the contact point (finger) slips against the document.
It's more of a compromise with the idea of both, based on my personal preference. The current behavior feels much more natural to me.Natural for a text editor, that is; in that it scrolls by line instead of by pixel, and in that it doesn't apply some natural "reading velocities" to the scroll.
You seem to be thinking about a more comprehensive package?, which would include those other two behaviors as the major options. I'll look into it but don't think I will be working on it soon, because this one works just beautiful for me.
Neil, in case you're judging based on the demo, I urge you to compile it in and test the feel of it yourself. I think you will agree that it is useful independently of how badly it approximates the OP's or a touchscreen user's expectations.
Cheers! ;)
There is this ugly breaking of the metaphor (row-by-row scrolling) where it comes to horizontal scrolling though. It would have to be column-by-column scrolling?, but how many pixels is a column for variable fonts?
We could use the font's average charwidth or the width of X or something. We could look at the width of a row's first visible char, favouring the hot-clicked line. The latter would give the user more control but could also be confusing initially.
It seems that pixel-by-pixel dragging is much simpler conceptually. It could be implemented quickly, leaving the more natural scrolling (for a text editor) as a special case.
As to the OP's actual wishes, I may have seen or hallucinated seeing an autoscroll ticker/timer somewhere in a file which could perhaps be appropriated for this.
In any case, Neil, this isn't something for your upcoming release, so feel free to ignore my chatter and focus on your work.
Last edit: Dejan Budimir 2019-10-21
The original poster's video looks like the way middle button scrolling works in browsers so that is what should be addressed in this tracker issue. An implementation could turn up someday.
Scrolling by dragging the document with the middle button is really a different feature so should be a separate issue.
I have run with the patch which is why I mentioned the slipping as it made it feel bad to me.
Last edit: Neil Hodgson 2019-10-21
You're right of course. It's a different feature.
I wonder if such smooth pixel-scrolling is at all sensible here, since it would no longer align the top row with the borde. Unless we let it snap-to at dragend. But if it make sense to do this, then there's nothing to stop us implementing a more comprehensive package here.
As for the slippery grip on the drag surface, that may be fixable by making the cursor snap to a row border. I'll look into this. Keep the feedback coming. Cheers!
I wasn't asking for pixel scrolling - it slips by multiple whole lines.
I see. You're saying the demo gif doesn't look at all like what your getting. Strange. I've checked with default settings. It really shouldn't slip by more than
editor.vs.lineHeightin any case.First off, the patch was against the scintilla of
scite420.tgz, since I don't have Mercurial installed.The
FingerScrollmixin (and please feel free to change the name!) calls only intoEditorand only viaSetMouseCapture,DisplayCursor(which are irrelevant), andScrollTo, andTopLineOfMain. I can see nothing wrong there either, so it must be in my code, which is just too simple to suggest itself as the source of a mistake.I would be looking at possible differences in our SciTe settings, your's and mine, Neil, but I've read through the docs a couple times and off the top of my head there is nothing that suggests itself to me. Do you have any idea what could be going on?
I'll better wait for the incoming
scite 421.tgzand try again.P.S.
Editor::ScrollToandEditor::ScrollTextmake me curious about what happened to those two in edit history. There is no longer any difference betweenRedrawandScrollTexthence much ofScrollTo's logic is superfluous. Where exactly would I be posting any cleanup patches? They are not exactly bugs.It looks something like what I am seeing but I'm using a larger window. The patch appears to be only moving one line at a time so will have problems with quick mousing. I'd expect the implementation to just be scrollto(original top + delta position in lines).
External name is more important and FingerScroll may make people think its about touchpad interaction. Maybe MIDDLEBUTTONSCROLL but then someone is sure to want to map it to another button or modifier.
I'd likely want multiple changes to follow the same style as the rest of Scintilla (PascalCase methods for example), avoiding assignment in call, and moving methods out of the header.
That makes sense. Instead of +/- 1 we should be +/- deltarows. And I'll try to lint it more in-tune with the rest of the code, once it works. As to the mapping to other MBs (plus modifiers) that should be a matter of just typing it out as well.
It would be nice if we could find a name for it. The "finger" was just the first that came to mind when seeing the "hand" cursor. In a PDF reader it would be called the hand-tool, so maybe something in that direction. Cheers!