Community
Participate
Working Groups
Build ID: I20070921-0919 Steps To Reproduce: 1. scroll wheel is navigated left or right in editor 2. the editor does not navigate left or right as expected. More information: SWT. Horizontal scroll wheel navigation is very useful when browsing in firefox; I catch myself trying to use it when coding in eclipse for long lines instead. How about we add this for those of us that hate word wrapping. I know not everyone has a horizontal scroll wheel but I'm guessing it should be trivial to add and the benefits would be worthwhile.
It works for me in the JavaEditor on windows xp with logitech mx evolution on windows vista with ms natural wireless laser mouse 6000 can you please try this again ?
I'm still not able to scroll horizontally (on Vista w/ Logitech G5).
The editor view will still not scroll horizontally with the mouse wheel. However this functionality is available with most views. I'm guessing allowing horizontal scrolling in views but not in the editor is done for a specific reason. Or was this just overlooked?
*** Bug 217564 has been marked as a duplicate of this bug. ***
>I'm guessing allowing horizontal scrolling in views but not in the editor is >done for a specific reason. It should work for you. It works for me, I tried different mouses. I don't know know to procede here. Would you by change have another mouse with a h-wheel that you could test with ?
(In reply to comment #5) > >I'm guessing allowing horizontal scrolling in views but not in the editor is > >done for a specific reason. > It should work for you. It works for me, I tried different mouses. > I don't know know to procede here. Would you by change have another mouse with > a h-wheel that you could test with ? > I don't. But it's certainly not the mouse I'm using. The horizontal scrolling works just fine in the views as mentioned (and other apps like firefox), just not in the eclipse editor.
What is your mouse (hardware and driver) ?
The mouse is a Logitech G5 using the default Vista drivers (mouclass.sys & mouhid.sys).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Scrollable on win32 does not implement WM_MOUSEHWHEEL, it does implement WM_MOUSEWHEEL. As a result, only widgets that support native scrolling support scrolling by horizontal mouse wheel. For instance, a tree (without columns See Bug 562499) does support scrolling by horizontal mouse wheel.
*** Bug 298978 has been marked as a duplicate of this bug. ***
*** Bug 444851 has been marked as a duplicate of this bug. ***
*** Bug 517311 has been marked as a duplicate of this bug. ***
I can confirm that this is still an issue, apparently after roughly 14 years. Today not many people are going to be using mouse wheels, but lots and lots of people are going to be using 2-finger scrolling on their trackpad and while this works fine vertically it does NOT work horizontally in the eclipse code editor.
Adding Laurent. Laurent, IIRC, you made something like this?
Hi Wim I've added a "Mouse Navigator" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=542777) that mimics the behaviour of Firefox or Chrome when you click on the wheel button. It does not concern the "horizontal" mouse wheel button
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176263
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176263 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=129a23713801a007bc805104cc17ed8a0784d713
(In reply to Eclipse Genie from comment #18) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176263 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=129a23713801a007bc805104cc17ed8a0784d713 Thanks Nikita for the fix, resolving for 4.19 M3.
(In reply to Niraj Modi from comment #19) > (In reply to Eclipse Genie from comment #18) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176263 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=129a23713801a007bc805104cc17ed8a0784d713 > > Thanks Nikita for the fix, resolving for 4.19 M3. Thanks, Nikita!! Well done. The person fixing the oldest bug in a milestone gets free cake from the project lead :)
Thanks Nikita, can you add this to the N&N?
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176313
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176313 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=67b621751358aa50cc6006b7f3b887b3518bb5f8
Reopening, Horizontal scroll works but the direction seems to be opposite as compared to other applications. Will fix shortly.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176387
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176387 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=af4be3eb04934002f29e7e40fb7e9f9dd42710d5
(In reply to Eclipse Genie from comment #26) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176387 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=af4be3eb04934002f29e7e40fb7e9f9dd42710d5 Resolving now, will verify in the next IBuild.
(In reply to Niraj Modi from comment #27) > (In reply to Eclipse Genie from comment #26) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176387 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=af4be3eb04934002f29e7e40fb7e9f9dd42710d5 > > Resolving now, will verify in the next IBuild. Niraj, -1*wParam is not a good fix, it messes up control button flags. I'm working on a better fix.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176412
I've posted an improved patch. It fixes some logical errors, better replicates modern browser scrolling behavior and reverts some unnecessary changes from Bug 565426 (preserving the behavior).
(In reply to Nikita Nemkin from comment #30) > I've posted an improved patch. It fixes some logical errors, better > replicates modern browser scrolling behavior and reverts some unnecessary > changes from Bug 565426 (preserving the behavior). Sure, lets finalize on this by 4.19 RC1
The last patch caused me to be pretty confused about what to do next. I spent reasonable time to get through old code and understand what does it do, then laid it in easier to read code, also removing duplication. Nikita now reverted my work without need. Here, by need I understand that it wasn't blocking his work. Nikita explained, quote, "I had to understand the code to add horizontal scrolling and it was easier to understand without the unnecessary factoring that you did". Reverting my work is clearly a destructive act (because my work is destroyed), and I would also call it aggressive. I understand that either this action needs to be balanced by good reasons, or it's simply evil. Now, the reason given is that old code was more readable. I understand that when saying "more readable", there's a lot of different things that people tend to mix together here: 1) Readable, as in "proof-read". That is, for some code, does it take less time to achieve very good confidence that said code is correct and does not have bugs? 2) Readable, as in "easy to parse". Surprisingly, this is sometimes opposite to (1), for example code like "if ((1 < x) && (x < 5))" is less intuitive to read, but is more robust and easier to proof-read once you get the idea of "x is written between 1 and 5". 3) Readable, as in "easy to hack". That is, one can quickly spot a location for a quick hack without paying attention to anything else. One example here is copy&pasting all code always. This way, it's easy to hack one copy without worrying about another. 4) Readable, as in "I can see it on same screen". This is often seen as opposite to formatting code with empty lines, comments, etc. This is usually opposite to (1)(2). 5) Readable, as in "I'm used to that". Some people are used to "if (1 == x)", others to "if (x == 1)", and each would call the other variant less readable. 6) Readable, as in "read aloud". That is, reading mechanically, without trying to understand code. For example, having shorter variable names and less code overall, so that one can literally read it aloud in shorter time. ---- It's easy to see that there is a number of contradicting definitions of what is readable. One programmer could argue that X is more readable under one definition, whereas the other will argue that Y is more readable under the other definition. I believe that this is the most helpful definition of "readable" is (1), the "proof-read" definition. If under any other definition code Y is "more readable" but is harder to proof-read, then it's more likely to have bugs, and bugs tend to beat any other benefit. Now, Nikita, under which definition you liked the old code better? Was it important enough to justify destroying work of other team member?
(In reply to Alexandr Miloslavskiy from comment #32) > The last patch caused me to be pretty confused about what to do next. > > I spent reasonable time to get through old code and understand what does it > do, then laid it in easier to read code, also removing duplication. > > Nikita now reverted my work without need. Here, by need I understand that it > wasn't blocking his work. Nikita explained, quote, "I had to understand the > code to add horizontal scrolling and it was easier to understand without the > unnecessary factoring that you did". > > Reverting my work is clearly a destructive act (because my work is > destroyed), and I would also call it aggressive. I understand that either > this action needs to be balanced by good reasons, or it's simply evil. Your refactored something that didn't need refactoring, which made fixing this issue harder. So I based the fix on the previous, original version of the code. (I did incorporate good changes from your patch). Claiming that I'm evil is next level bullshit. When you merged some really terrible code, I kept silent, because it fixed bugs. I suggest you do the same. > Now, Nikita, under which definition you liked the old code better? Was it > important enough to justify destroying work of other team member? I _restored_ the work of original SWT team members, for which you seem to have no respect whatsoever.
Everybody, please remain friendly and respectful. We are all in the same boat and are trying to improve SWT and Eclipse. If concerns with code exists they should be raised via code review. And if committers have different styles of readability in code they can ask other activate SWT committers to give an opinion or the project lead for SWT.
I need to say that I like Alexander's clear code. What is the code that was reverted? Where can I find it? Nikita, are you sure about keeping the fixes from Bug 565426 - AKA were you able to reproduce the old buggy behavior and can confirm it remains solved with your recent changes? I came here because the -1 * wParam change jumped to my eyes when looking at the recent master commits. Wouldn't -wParam be more readable? Would a comment for this minus make it more understandable for the reader?
(In reply to Lars Vogel from comment #34) > Everybody, please remain friendly and respectful. We are all in the same > boat and are trying to improve SWT and Eclipse. > > If concerns with code exists they should be raised via code review. And if > committers have different styles of readability in code they can ask other > activate SWT committers to give an opinion or the project lead for SWT. Some general guidelines from Eclipse/SWT perspective: 1. Just to re-iterate on above: Even for any dis-agreements lets remain on the technical side only. 2. Gerrit reviews are there to discuss merits and demerits of the code. 3. Bugzilla is anyways there for requirement analysis, evaluating possible design-approaches, use-cases related and other discussions in general. Please be respectful for other committers and create a win-win situation for all. Thanks!
(In reply to Eclipse Genie from comment #29) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176412 Above patch is still under review/discussion, hence closing current bug for 4.19. Raised bug 571464 for further improvements which are under discussion in 4.20
Would be nice to have the same horizontal scroll support for Table. Do we already have a bug for this?
(In reply to Lars Vogel from comment #38) > Would be nice to have the same horizontal scroll support for Table. Do we > already have a bug for this? For Tree with columns there is Bug 562499, I don't recall that there is bug for Table.
