"Natural" mouse scroll direction #3902
Comments
mplementation example (not sure is it correct but it works) |
Sorry, forgot one more change for viewer |
Hi,
It's not only Mac, the GNOME desktop also defaults to natural scrolling.
I don't think that requiring to configure each and every terminal-based app separately is a viable approach. It might be a temporary workaround until a standard is designed and implemented. But there should be a standard that the world is converging to.
It might be for example an environment variable that's commonly recognized by terminal-based apps.
It might be a terminfo capability, and a different $TERM variable for natural scrolling.
It might also be the terminal emulator simply swapping the two directions, according to how the emulator itself behaves outside of mc, when scrolling the scrollbar. Which, in turn, should (and usually does) match the desktop's setting.
Oh, wait a second...
VTE (gnome-terminal and many others) actually does swap the reported directions when natural scrolling is enabled. That is, in these terminal emulators you automatically get your expected (that is, natural) scrolling behavior without the patch, and hence the patch's new config option would break it.
Now, it might be that VTE shouldn't do it and swapping should happen somewhere else. In any case, however, I'd rather see this topic being discussed among key players, a consensus being made, and then that getting implemented; rather than each and every player doing whatever random approach they feel like doing, leading towards a bigger and bigger mess.
What do popular terminal emulators on macOS (at least the default Terminal.app, as well as iTerm2) do?
Execute
and then scroll.
In case of legacy (non-natural) scrolling, rotating the mouse wheel or moving your fingers on the touchpad upwards should result in letter M followed by backtick, whereas rotating or moving fingers downwards should print stuff containing Ma. Is this indeed the case?
With new-style natural scrolling, is it the same, or is it swapped in these terminal emulators? |
1) It's proposed to be a setting, it could even be "hidden" i. e. don't have the dialog representation to change it, just a string in the ini file. So anyone who needs it could set it, like mac users. And it is disabled by default in the proposed patch, so behavior wouldn't change till user will explicitly set it. Sure, we can wait for the solution for years, but it's a simple patch that took about 30 minutes to made, as I haven't seen the mc sources since 1995, I suppose ;)) And I think it's not about the terminal but about the MC -how to treat "natural" scrolling in the panels.
2) As for the viewer, the current behavior is ok( i.e. "natural"). Not sure about the editor - as for me it's more "natural" to move the cursor up then scrolling up, not the document, so it might be a good idea to have a separate setting for this
3) Mac terminals (terminal, xterm and iterm2) reports "Ma" for scrolling up and "M`" for scrolling down. Not sure if I understood what do you mean by the "new-style" correctly, if you meant the proposed mc patch, it does not affect terminal, just mc as you can see in the attached sources |
Re 3) I meant "new-style" as a synonym for "natural". Based on what you say here ("Ma" for scrolling up...) and based on 2) mcview having "natural" scroll, these terminal emulators work just like VTE: they swap the two reported directions when natural scrolling is enabled.
(By the way, I checked VTE, and it doesn't do any explicit swapping on its own. It's an implicit result of receiving swapped directions from GTK+.)
In the panels, with a long file listing, eventually moving the selection up is the same action as moving the listing down (and vice versa).
So what you're actually asking for here is not natural scrolling, it's quite the opposite. You're asking here in this particular context to revert to the legacy behavior that mc has on non-natural-scrolling systems. And because your terminal emulator swaps the directions, you'd need to swap them back in mc.
"Not sure about the editor - as for me it's more "natural" to move the cursor up then scrolling up, not the document" – again, here you're asking for the traditional, "non-natural" scrolling.
I don't think it makes too much sense for mcedit to scroll in opposite directions than mcview, I don't think it makes sense to invert the scrolling direction based on the presence vs. absence of an insertion cursor, I could hardly imagine anything more confusing than this. (And what about mcview's hex mode which also has a cursor?) I'd say if you choose natural scrolling, you have to accept that you're no longer moving the cursor, but moving the content instead. And with short file listing, yes, it's confusing. A mixture of the two behaviors sounds terrible to me. (Mind you, I don't have a Mac, and once I tried to get used to natural scrolling but I couldn't live with it for more than about a day.)
Is there any precedence in other apps of what you're asking for? For example, a word processor where you move the document if it's read-only, but move the cursor (and hence the document eventually scrolls in the opposite direction) if the document is writable? Or an app where the global setting of "natural scrolling" affects the scrolling direction in some, but not all of its functionality? |
Well, looks like with your help I understood the problem. I'll try to explain my point as I believe now I even understood it myself ;) |
Replying to vik:
You said this, I'll get back to this later :)
<off>It's not clear to me why I couldn't switch, since I use natural scrolling all the time on my smartphone. I have three theories. One is that actually touching the content mentally differs so much from touching and scrolling somewhere else. The second is that on the smartphone I'm mostly consuming content, whereas on my laptop I'm producing a lot, and that might be so much different. The third is that it's just so hard to change something you've been used to for so many years. Anyway...</off>
Nope, or at least not for me. (We're talking about the standard file listing here, right?) First mc scrolls the content (the visible sublist of file names) as long as it can, and by the way does so by entire pages at each step. When it can no longer do so, then it switches to moving the cursor, by a single row at each step.
(At the very least, the drastic change in the amount doesn't make any sense to me, even with non-natural scrolling. Page Up / Page Down on the other hand first scroll the view exactly as the touchpad, but when it no longer can scroll, the cursor suddenly jumps to the top or bottom. This already makes more sense to me.)
This is where I refer back to your previous statement. Natural scrolling is not about dragging "something", it's about dragging "the contents" in particular, that is, definitely not the cursor. (Or let me know if I'm wrong here and back it up with examples please.) Clicking is the action that moves the cursor instead.
Again, I'm referring back to your statement I quoted at the top. According to that, the presence of a cursor should not influence the scrolling behavior, it should still scroll the contents. Do you call this confusing, or current mc's behavior?
As per the above, I'm firmly against this approach. And as you also say, this wouldn't be "natural" scrolling. Whether it's more "natural" than the current, or more confusing, is at least heavily debatable. I'd guess it would be even more confusing, by swapping back the up/down directions at some places. It might feel "okay" to you, but we have no data on how others would perceive it.
I definitely like this one much better. This is what "natural" scrolling is about, so this is the natural scrolling behavior by definition, and not something random that is just debatably "more natural" (or not) than the current one.
As far as I understand, this would require that no change occurs to the code that handles scrolling of the file listing, it should still scroll in the direction that it scrolls currently. The special code that moves the cursor by a single row if the contents can no longer be scrolled, should, however, be removed – maybe conditionally to a new config option.
Here I'd be brave enough to go one step further, and unconditionally remove this moving of the cursor by a single entry, even for non-natural scrolling. As said above, I find it weird anyway how the "speed" drastically changes. The behavior would still not be exactly the same as the behavior of Page Up / Page Down, but I don't think it's a problem.
---
I primarly had the file listing in mind while writing this answer, but other uses (most notably mcedit) should also be investigated. I'd say we should check how most other popular apps, especially native macOS ones (simple text editors, complex word processors etc.) behave, and mimic them.
Oh, by the way, when scrolling in these apps, does the cursor try to stay at the same physical position on the screen (the behavior equivalent to mc's), or does it drift to the top or bottom of the viewport (that is, try to stay at the same position within the document, as long as possible)? I'm truly curious about this. If the latter, we might need to adjust mc's behavior too.
Mouse scrolling jumps the viewport by 2 lines in mcedit, and by an entire page in the file listing. This is inconsistent. Jumping by entire pages is not the expected behavior with touchpad scrolling, and IMO isn't too useful either, touchpad should operate in much more fine-grained steps (especially with kinetic scrolling in mind). Why not make both the same, maybe let's say somewhere from 2 to 5 lines?
(Well well well, it should scroll by a single line upon every smaller movement of the fingers, but this requires an extension to the existing terminal emulator mouse protocols, see VTE #755183.)
When the contents can no longer scroll, mcedit still moves the cursor by the same amount (2 lines). Would be a sane behavior on the file listing, too.
mcedit's scrolling philosophy seems to be: Move the cursor by 2 lines within the document, and scroll so that the cursor stays at the same screen position as much as possible. Reasonable behavior. Not exactly what you'd expect with natural scrolling, though. So maybe that new config option, which I said I might be brave enough not even to introduce, just switch to the new behavior, so now I guess maybe that new config option would really be nice to have. |
Well, I just tried to explain how it's done in macos and what can be done in the MC.
Conclusion: the best way to implement natural scrolling is to scroll the content and do not move the cursor at all. Never. Scrolling shall be done line-by-line - one line per one mouse scroll event.
And about investigations - I did it and found that any mac app scrolls the content, cursor stands still in the same position in the CONTENT, not screen. I can make a short video, if you'd like, but hope I can explain without it. So, the content is scrolling, cursor remains in the same position in the content, so cursor can be moved away of visible area with the content because it remains on the same position in the content. |
What happens if I scroll far away, then press a key (e.g. a letter to be inserted into the document, or an arrow to move the cursor)? Does the viewport suddenly jump back so that the cursor (the place of edit) becomes visible?
So if I wish to scroll far away and edit the document there, I guess I need to scroll and then click, correct?
I'm not sure mc should implement this behavior, i.e. offscreen cursor. It would introduce a couple of other issues, e.g. how to show to the user which of the two panels is the currently active one (with its invisible cursor), what to do on TAB keypress. At the very least, implementing this behavior would require quite some design/behavior changes, so it may not be feasible right now. I guess I'd rather explore what's the best compromise between having natural scrolling, while forcing the cursor onscreen.
Here I understand you now. Moving the cursor isn't unacceptable for me, no, because for me, ultimately the single most important question is: which file is focused currently. And with that in mind, scrolling the viewport upwards while keeping the cursor at the same visual position is almost the same action as moving the cursor downwards; and vice versa. I understand that you wish this to work differently, and I'm fine with that.
I still totally don't understand this one. You keep claiming that you wish to have natural scrolling experience, yet you implement something that is the exact opposite of that and claim that it's good enough for you, so should be part of mc. Like, errrrr... sorry, no.
Do you want to have natural scrolling experience? Absolutely fine by me, I'd be happy to see it. But then let's implemenet natural scrolling, and not something different.
Easiness of implementation, to the extent that someone hardly familiar with the code can do it in 15 minutes, cannot justify an incorrect solution.
Again, you contradict yourself. You clearly stated that natural scrolling always scrolls the content, never the cursor. And yet you imagine how it would work if it moved the cursor, and want that to happen. Whereas I'd rather guess it would work the other way around. There's no use arguing about this. If natural scrolling always scrolls the content and never the cursor, we cannot start moving the cursor in whichever direction in the name of natural scrolling.
---
2-3-4-5x speed can be justified if without a multiplier scrolling would be very slow (you'd have to scroll way too much). Typically terminal emulators scroll about 3-5 lines on a single mouse wheel rotating click. In order to achieve the same behavior in a terminal-based app such as mc, it would need to scroll by one line upon every 1/3-1/5 of traditional unit seen from the touchpad. This requires extending the mouse protocol. Since it's not yet available, jumping by 3-5 lines at once might be a better overall experience than always jumping by 1 line, since the latter case scrolling is just painfully slow.
Moreover, for touchscreen devices scrolling should exactly follow the fingers' movement, see my brand new comment and link at the aforementioned VTE bug.
---
Sounds good to me.
I'm not sure. Anyway, the scrolling speed should be unified across mc. It could receive a new config option.
Veto from me on this one.
I agree that kinetic scrolling should be handled elsewhere, not in mc. (I do have kinetic scrolling, and I don't have the slightest idea who does that for me: the hardware, X11 or GNOME.) |
Replying to egmont:
Exactly.
I don't understand you. I told you that at the very beginning that it could be a bit difficult to implement this in the MC, and you answered that there shall be "standard" solution and called this behavior as a standard. So, here it is )))
But it's not a problem really, if user scrolled the cursor away from the visible area and forgot where it was, he can press a key or mouse to explicitly repositioning the cursor. So, the only problem is, that a lot of effort required to implement this. And on tab, as I checked in another file managers, cursor moves to another panel and currently active stays untouched with the active item out of the screen, but when tab is pressed again, the app scrolls the current item into the view.
Not visual position but position within the document. For example, cursor is on the third file - it will remains there but the whole content will scroll and third file will remains "current", marked by the cursor. The same for the editor - if the current cursor position is on the 5th line at the 11th character, cursor will stay there and whole document will scroll. What file is active is an important question, but from the UX point of view, if user cannot understand what is the current file, user will just select another one- it's "natural" decision and "natural" behavior. And, if user came to such a situation, it means that user used the scrolling feature to achieve that. And it means that user has a pointing/scrolling device. And it means that user can just select a file in one click, if he forgot where he is and who.
Let me explain it again in brief. Imagine - you move your finger down on the touchpad and cursor moves up. I don't understand how you don't understand that it's awful, terrible and annoying ))) So, if we'd take the concept that moving fingers on the touchpad reflects the cursor movement (as it is done right now but in the right direction) - such a behavior will be much more logical than the current one. Again - now, on the motionless screen, I observe the cursor moving up when I move my finger down and vice versa. So, cursor is moving in the opposite direction, and it is the most confusing on the still content.
It's just a quick fix to stop current weird behavior. Sure, natural scrolling in the way it's done in mac, would be much better.
Agree. Not really 15 minutes but 20+ years and 15 minutes (counting my first mc builds on sco 20+ years ago) but I completely agree anyway ))) That's why I asked for help here.
No contradictions. You asked how it's done in other apps, I did the short study and reported results. But I newer said it's the only way to implement the natural scrolling, and proposed another approach based on the current and existing functionality. It differs from the one observed in the mac apps, but still better than current, when cursor moves in the direction opposite to real fingers movement. And yes, it is still natural and I tried to explain why using real life examples
That's what the scrollbars were invented for;)
Touchscreen devices are in the another story, they would require the "touch" events support as its done in the modern mobile terminals. But even for the touchscreens, it is still weird to move cursor up when user moves fingers down
Nice and reasonable idea. But not related to the natural scrolling
Don't you agree that it's better than moving the cursor in the opposite direction? |
Initially it was absolutely not clarified what was the problem with mc's lack of natural scrolling. The fact that your patch swapped the two directions mislead me into thinking that the global configuration option of "natural scrolling" was totally ignored and mc always behaved as if this setting was disabled, and you simply swapped the up and down directions. It was later clarified that we're discussing something entirely different.
I'm totally lost again with what you're trying to say... Sigh... Where does a "reverse scrolling" happen in mc? It does not, in case you meant "the reverse of whatever the «natural scrolling» option is set to". Probably you wanted to say "reverse cursor movement".
Correct me if I'm wrong anywhere here:
There's two main components to this story, and let's absolutely clearly separate these two:
1) The first is the direction. I believe toggling the desktop-wide configuration option "System Preferences -> Trackpad -> Scroll direction: Natural" does one thing and one thing only: swaps up and down (as well as left and right; irrelevant here) for scrolling events everywhere. And because terminal emulators respect this setting, the directions are also always swapped in mc. All the rest of the story (that is, that scrolling should scroll the viewport and not move the cursor within the document, so the cursor might easily go offscreen) is irrelevant here remains untouched by this config option.
Let me know if I'm mistaken and if there's any app where flipping the desktop-wide "natural scrolling" config option does more than just swaps the directions.
Now you come and say that you'd want to have this option enabled (as it's macOS's default), yet want mc to revert the scrolling direction in some places, so that e.g. on long file listings you get exactly the non-natural scrolling direction. I don't see this request being justified at all: whatever your preference for scrolling direction is, I guess it should be consistent across the desktop, including mc. If file listing in mc scrolls in the reverse direction compared to everything else on your desktop, it's the most confusing thing I could imagine.
2) The second part of the story is all the other aspects of scrolling behavior. Here I understand that mc's behavior differs from most other apps, and I'm more than open to introducing a new option where scrolling means to scroll the contents and not to move the cursor. (You can see that in #3256 (mcview rewrite, behavior when reaching the end of the file) I heavily argued in favor of the behavior seen in modern apps rather than what legacy terminal-based apps do.)
This, on the other hand, should be independent from the first part of the story, that is, from the scrolling direction.
You seem to also mean this second part when you're talking about "natural scrolling", although technically it's a quite different thing, and even the wording on the macOS's config panel, namely "[checkbox] Scroll direction: Natural" suggests to me that the term "natural scrolling" should not have anything to do with these generic design principles.
---
It seems to me that you don't clearly separate these two things, instead you mix them in really weird and unusual ways, and look for a solution that entangles them more instead of clearly separating them.
I perfectly understand that the behavior when the cursor moves opposite to the finger movement is terrible.
It is also terrible if the contents scroll in the opposite direction as the rest of the desktop, because someone somewhere believes that the value of "natural scrolling", whatever it is set to, should be disobeyed.
Now imagine for a second this weird mixture: The long file listing in the panel obeys the "natural scrolling" setting, let's say it's enabled and you move your fingers downwards. As such, the viewport scrolls downwards, that is, you get to see earlier and earlier files. Let's assume that because we're afraid of heavily modifying mc's behavior, the cursor stays at the same visual spot, that is, keeps pointing to earlier and earlier files in the list. Then scrolling hits the top, hence stops. Let's again assume that we keep the current behavior of mc that we switch to moving the cursor. As per the terrible behavior you're worried about, you'd move the cursor downwards now (according to your fingers), so it'd go to later and later files in the listing. That is, for a while the cursor would move to earlier files, and then at some point it'd switch to moving to later files. Again a terrible behavior.
The solution is not to further mix everything into more and more complicated behaviors. The solution is to clearly separate the two parts of the story, to implement a behavior that matches most apps so that scrolling only scrolls the viewport and not the cursor. This would get rid of the terrible behavior you're worried about that the cursor moves opposite to the finger, and this would also get rid of the terrible behaviors I outlined in the previous two paragraphs.
Paying the price of introducing other weird behaviors (as per above) along with a probably hard to understand config option that has no clear semantics, to get a certain behavior that vik finds good enough, but has no predecence in other apps. Plus, all this falsely in the name of "natural scrolling". You won't get my buy-in for such hacks (and I don't see any point in continuing this already way too lengthy discussion in this direction.)
I understand that implementing fully the behavior of modern apps is nontrivial, requires heavily modifying the code, and it might not be feasible right now. I believe that a slightly modified behavior, where the cursor remains at the same visual position, should be pretty easy to implement (e.g. for the panel listing you'd simply have to wipe out the code that moves the cursor by 1 entry) and should result in a pretty good behavior. I believe this is a compromise we should aim for, or at least try and evaluate if it's good enough for a start. You do have my support in this approach, I'll most likely even vote for making this new behavior the default. Let me know please if you have doubts, worries, questions etc. with this approach. |
Too much words. let me summarize:
Did I forgot something? |
1) You clearly describe the overall scrolling experience in other apps. According to that, the problem is not that the cursor moves in the wrong direction (although it sure does move in the wrong direction), the problem is that the cursor moves at all.
2) When there are many files in the panel listing, and hence scrolling with the touchpad actually scrolls the listing (as expected), your patch (along with enabling the new config option) breaks it: makes it scroll in the opposite direction. I can't see how anyone could ask for this behavior, I can't see how you represent "mac users" in general here.
3) I'm sad to see how you don't get that most of my comments were relevant to the story. (Sure there were a few that weren't.)
4) No, I didn't say I wanted to leave everything as it is now. I said I'd be happy to see a patch that actually addresses and properly fixes the actual problems. I'd be happy to see a patch that makes mc behave like the rest of the apps with natural scrolling. Your patch doesn't take us closer to that, in fact, it takes us even further away from that, since you "fix" something that should entirely be removed instead (the cursor movement), while break something that works correctly without your new config option (scrolling in case of many files).
I'm one of the folks whose word probably matters, not the most, but to some extent.
Something else: Your modifications were a nightmare to apply, and compiles with tons of warnings about duplicate declarations. Please use "diff -ur [original] [modified]" or "git diff" for creating a proper diff, and please don't attach the complete new version of files, as that's unmaintainable if the file changes in the meantime. |
Just leave these "another apps" alone - we're talking about MC bug ))))
Looks like you just want to keep your opinion and don't want to admit it's a bug and it shall be fixed. Have no idea why, maybe you just hate the natural scrolling as you told before. But if even so, you could just not turn this option on and rest of mac users, including me, will be happy because it's really obvious - cursor shall not move up when users scroll down. It's absolutely clear.
All your comments are good and nice but it's a theory as you agreed that it's hard to implement the behavior you'd like to (as it seen in another apps). So, why don't just fix a bug, I wonder? I'd try to look at the code and implement "offscreen" scrolling when I'll have some more time than I have now, or maybe you or someone else could, but why don't just fix it now at least getting rid of that wrong opposite scrolling? It's really strange, I don't understand your motives - is it just a stubbornness? Do you really believe this setting will disturb and obstruct somebody/something? Don't understand... Sure, I can apply this patch to every new version by myself, but there must be other people having the same problem...
About my patch - sure, I removed some "spaghetti code" and added some "if" statements - maybe it's a bit confusing, but I surely didn't add anything that could produce warnings - just because there's no place to do so )))) Looking in the code I dare to suppose these warnings lasts from the 1995, they look so familiar like I've seen them all before ))) |
|
Replying to vik:
I have a good reason to refer to other apps: They define the standard behavior that most people are used to. If you want to convince me that mc should work as other apps do, it'll be quite easy. If you want to convince me to do something in mc that you yourself find logical, but we've never seen anywhere else, you'll have a much harder time. (And if that behavior is inconsistent, it'll be hopeless.)
What do these 3-4 closing parentheses mean? You keep using them.
IMO not by paying the price of breaking natural scrolling in some other cases.
I have already told you I don't know how many times that adding this setting you're suggesting breaks other things. As such it's a no-go. I don't know why the other possible quick fix would be to disable scrolling. I have for many times outlined yet another possible approach: disable cursor movement generated by the touchpad (but retain scrolling as it is now). I haven't heard from you what would be wrong with this approach. You only keep repeating your preferred approach, ignoring me showing why it's broken.
No, I clearly stated I agree it's a bug and I proposed a solution, with which (unlike with your proposal) I cannot foresee any problem.
I never said I hate natural scrolling. I could just not get used to it.
What I hate is the idea of sometimes having natural scrolling, while at some other places having its opposite. What your patch would do.
You keep putting words in my mouth that I absolutely did not say, in fact, said the opposite. Please stop this. Quote me literally if you need to.
You apparently missed that that's what I'd like to see, too. Not a heavy fix that implements offscreen cursors, at least not for now, as it would be a lot of work. Instead: just stop moving the cursor, leaving it at the same visual position, but have natural (or whichever your global preference is) scrolling for the contents. This should be really easy to implement.
Again, I don't want to get rid of this in your proposed way because it has other problems, introduces other bugs. I do want to get rid of this in a way that doesn't introduce new problems.
No, it is my desire to have a nice, clean, maintainable code, and config options that are usable and make sense for more than one person. A change that makes natural scrolling non-natural at some places doesn't fulfill these criteria in my eyes, even if it fixes something else.
I'd like to emphasize again that:
That's my point too. And I can't see how your proposed fix would be good enough, rather than totally confusing, for those other people.
You're much more confident than you should be.
I get 37 warnings that go like "setup.h:101:17: warning: redundant redeclaration of ‘mouse_reverse_scroll’ [-Wredundant-decls]".
In case you'd like to attach files in the future, please get familiar with the "diff" and "patch" tools, study how they are used pretty much everywhere, and accordingly attach a file that can be applied with one single "patch" command, without having to locate each file to be patched manually in the tree, thanks. |
|
Replying to egmont:
Oh my... Like my school teacher used to say: "and if they'd jump out the window, would you jump too?"
Just smiles, never mind
Sure. I found just one case - the viewer. And I forgot to attach it, fixed.
What "other things" are yu talking about???? I have no words. Every menu in the MC scrolls down when user scrolls it up and scrolls up when user scrolls it down! ))))))) This is the bug and the problem! And you keep talking about some virtual "breaking other things" - what things? Menus will be scrolled in the correct way? ))))) Just give a n example, what would be broken?
Please provide more details about these problems. I can show you at least one problem in your approach - menu scrolling wouldn't work.
I explained you so many times, natural scrolling is not about scrolling content, it's about moving something to the same direction that user moves his fingers. But you simply ignore it )))) Ok, I can repeat it once more - natural scrolling is not about scrolling content, it's about moving something to the same direction that user moves his fingers. And since current MC approach is to move the cursor, that means that cursor shall be moved in the same direction user moves fingers.
THIS would definitely break a lot of things, like menus I told you before
What "bugs"? Please explain
Nice clean maintainable code that scrolls in the wrong direction, I suppose? What "unclean" here in this setting? If you mean that mouse event is globally changed, I can do it not in the mouse.c but in the panel.c, tree.c, editwidget.c etc
Please, could you clearly repeat what problems? I saw just one - you wrote that this behavior would be "not the same as in the other apps". Sure, it will not be the same because it's hard to implement the same. So, lets do at least this, it's better than nothing. And you still ignore the fact, that it's just an option, and everyone who don't need it could just turn it off
I showed you at least one problem with this alternative. But ok, I suggested an alternative and implemented it, would you implement yours?
What will be confusing for other people??? Please explain if you can. It's an option in the ini, if someone don't need it he just won't turn it on. And you're still ignoring that fact
Because I have a reasons to )))) Not sure about you
Do you really want to say that it produced all these warnings? )))) I suppose you're doing something wrong because this change could not, surely, add any warnings at all.
Dear, I'm working with the diff and patch for more than 30 years now.)) but thank you for your advice anyway! Btw, the diff I attached is just made for the patch, so if you cannot use it' I'd suggest you to execute "man patch" command and read the text on the screen carefully )) maybe all these warnings will gone then as well?
Wel, you involved me in this again - tons of text and a little meaning. You definitely trolling me, are you? )))
Ok, could you clearly describe disadvantages of the solution I proposed, and also clearly describe yours? |
Replying to vik:
I have never seen smileys like this. And no, I didn't recognize them (I had a guess that these might be smileys, but I wasn't sure).
And, so it happens, this is exactly what's wrong with your approach to the bugs as well. You have found truly valid bugs (it took a couple of back and forth comments to clarify what your actual problems were, with even some brand new ones in your latest comment, nevertheless, these are actual bugs that should be fixed), but then you propose a solution that I don't see why others would understand.
Sorry to say, but if after having used them for 30 years you diff the files in the opposite order (as you did in the original report), or attach multiple diff files in a tgz so that I have to manually locate the files to patch (mind you, there are multiple mouse.c files in the source under different directories, I truly wonder how your tgz would look like if you needed to modify both), and after all this you tell me how to use "patch", well, that's a pretty good sign to treat anything you suggest with a certain amount of healthy doubt.
Your smileys are not well-recognized smileys, it's something that you understand, others don't. Your diffs are not well-recognized diffs, it's something that you understand, but is a pain for others. Your idea about natural scrolling (dragging something, whereas that something is quite randomly either content or cursor, resulting in opposite scrolling direction of the content between these two cases) similarly just doesn't match the well-known interpretation of natural scrolling.
Sorry, I don't have any more time for this, I'm out of here. Goodbye! |
And again, you discussed my diff, my smileys and other dark sides of my nature but nothing about this bug ))))) I didn't meant I'll patch the sources, do you realize? I suppose I patched it wrong, moreover, I have almost no doubts I did. I might missed some places that have to be patched etc. I just wanted to show to the maintainers what is a problem and how I'd suggest to fix it, i.e. WHAT shall be patched. For example, for me including this "externl" in the lib/global.h is just a hack and cannot be populated in the production code, but I don't know the directories/modules structure. So, it was just a implementation SUGGESTION
Although I asked just two simple questions: |
Replying to vik:
Interestingly, you opened this bug showing how you'd fix – but not a word about what. No wonder I misunderstood initially. It took several back and forth comments to finally clarify what your actual problem was.
I have exactly told you a couple of times what my problem is with your approach. If you didn't understand it so far, I see no chance of making you understand it by phrasing it over and over again using different words. Please go back and carefully read my comments again.
Ditto.
I cannot tell it right now. mc is developed by volunteers in their free time. Currently it has about 500 open bugs. I hardly have any time to work on it nowadays, some other developers apparently have somewhat more.
Your best bet, if you really want this to get addressed, is to do it yourself, listening to the developers and doing the work along their guidelines, not stubbornly against them.
If you'd like someone other than you to implement it, here's my suggestion. This bug here has become way too long, and the chances of anyone ever going through it is almost 0. Close this bug and open a new one. In the initial report describe what is wrong currently in mc, mention a couple of example on its UI where the behavior is "upside down", but the opening bug should be this and this only. You could include a link to this bug. In a followup comment you may suggest your preferred way of solving it. Be aware that I am going to respond describing why I cast a veto on that approach, and what my preferred approach would be. We will just be stating our opinions and leave it there, and not start over this debate. Then it will be short enough for others to reasonably pick it up and work on it. |
1) You wrote: "I pointed out problems with your approach, which you keep ignoring" and "Again, I don't want to get rid of this in your proposed way because it has other problems, introduces other bugs. I do want to get rid of this in a way that doesn't introduce new problems."
2) You are not all developers, just a stubborn one who don't want to admit he was wrong. All is clear for me, so bye. |
No, I did not ignore the question, I answered it multiple times. In fact, I started straight away by pointing out the exact problem as soon as I realized it, rather than just casually waving the "it has bugs" flag. After a while I got fed up with repeating myself over and over again and told you to look back at my previous comments.
But since so far you've understood exactly 0 of what I wrote here, I don't expect you to realize this either.
We have pretty different views on who's trolling here.
Just as you are not all Mac users, and your idea about natural scrolling (which isn't backed up by any existing app you could refer to) is potentially not what others want to see. But I don't expect you to understand this either.
Ha-ha. I told you what's wrong with your proposal. You did not comment so far on my one, despite me having asked you to point out if you see any problems with that. So who's the stubborn here, again?
It was a pleasure talking to you. (No.) |
Important
This issue was migrated from Trac:
vik(vik@….net)egmont(@egmontkob)Please add the "natural scroll direction" feature to scroll with mouse using natural scroll direction as it is done in the macos.
It could be done in 10-15 minutes by adding new boolean parameter in the CONFIG_MISC_SECTION, for example "mouse_reverse_scroll", loading it in the setup.c, and then to change mouse.c by reversing the mouse scroll direction if it's set, like:
midnight/mc/lib/widget $ diff mouse.c mouse.c.original
104,107c104
< if (mouse_reverse_scroll)
< msg = MSG_MOUSE_SCROLL_DOWN;
< else
< msg = MSG_MOUSE_SCROLL_UP;
---
109,112c106
< if (mouse_reverse_scroll)
< msg = MSG_MOUSE_SCROLL_UP;
< else
< msg = MSG_MOUSE_SCROLL_DOWN;
---
All Mac users will say you big "thank you" for that ))
Note
Original attachments:
vik(vik@….net) onFeb 25, 2018 at 18:16 UTCvik(vik@….net) onFeb 25, 2018 at 18:41 UTCvik(vik@….net) onFeb 27, 2018 at 15:42 UTCvik(vik@….net) onFeb 27, 2018 at 16:27 UTCvik(vik@….net) onFeb 27, 2018 at 16:35 UTCThe text was updated successfully, but these errors were encountered: