Version: (using KDE KDE 3.1.4) Installed from: RedHat RPMs I would be highly appreciated if all KDE applications had smooth scrolling, as in internet explorer or Mozilla with the SmoothWheel plugin.If the scrolling is smooth, it makes it much easier to follow what you are looking at while scrolling, and it's also more efficient.(When scrolling a small amount, it would go slowly, and when scrolling more it would go more quickly). This is a feature I have wanted for a long time. Thanks ...(I don't know if this was the correct KDE app to place this under, so sorry if it's wrong)
reassigning to kdelibs.. but perhaps more specific bug report would be better.
Smooth scrolling can be in any application that has a scroll bar. It's great because the screen moves up or down in one continuous, animated motion instead of the jerky, three lines at a time. It's also now an option in Mozilla Firebird/Firefox. How does smooth scrolling work? Well, if you click on the up or down arrow of the scroll bar, or use the arrows on the keyboard, the screen will scroll smoothly instead of fixed amounts that shift the screen immediately. It also works with the scroll wheel on your mouse.
..this would really be very ..smooth
I think this would be a nice touch.
Added my votes. Although I would rather have the ability to scroll a page or even half-page instead of the tiny 12 lines maximum (see Bug 50109).
I saw this idea on slashdot, and thought I should copy it here: Make it so when the user hits the Page Down key, a horizontal line appears for a few seconds where the old bottom of the page was, then fades away. So when you're reading long sections of text and hit Page Down, your eye can quickly scan to where you left off.
> Make it so when the user hits the Page Down key, a horizontal line appears for a few seconds where the old bottom of the page was, then fades away. So when you're reading long sections of text and hit Page Down, your eye can quickly scan to where you left off. I like it, I like it a lot!!!
>>I like it, I like it a lot!!! same here ;)
cool idea (the horizontal marker line). Smooth scrolling by default would also be a neat feature - but can this be hacked in kdelibs or will it have to be implemented specifically for each application ?
As a work-around, there is an already existing feature to smooth-scroll at least in konqueror by using Shift+Cursor up/down. This start a smooth scroll and another keystroke to a cursor up/down stops it again.
I would also want to see this wish implemented. As said by the reporter, smooth scrolling isn't just a toy, it's also about usability: eyes can have point(s) to attach the looking and see where it goes, smoothly, and didn't loss it. The line is also a very good idea to enhance usability. You have my vote :-)
In followup to comment 6, I have filed a new Bug 93196 to address the idea described. These bugs really address the same issue though: keeping track of one's position on a page while scrolling. Please comment in the other bug.
Smooth scrolling would make for much better usability. Would this be something KDE could implement, or would this be more related to Qt?
Smooth scrolling reduces the work the human brain must do to track the movement. With smooth scrolling the perception is more accurate and faster. The brain simply has been built to get a continuous feed of visual information - not jerky. There are actual scientific studies about the matter.. Made by university researchers and instances like the USAF. (Did you know that for instance the accuracy of perception of object movement improves in computer simulations even when they go to 350fps from 300fps? Human eye/brain actually can distinguish a lot more than people usually believe.) Even common sense should tell the fact to anyone. Note that 1) Smooth scrolling does not necessarily mean the same as slow scrolling. The speed of scrolling is supposed to be controllable (ie. with mouse wheel or keyboard) and comparable to that of the non-smooth version. 2) The modern computers can handle the overhead of showing the greater amount of states with no sweat. Practically no computer made in the last 5 years should start even sweating under the stress. 3) The feature is not hard to implement. We are not talking about quantum mechanics here. 4) Usability consists usually of a large amount of small details making the human-computer interaction intuitive (also natural) and efficient. Smooth scrolling can contribute a great value to the overall usability. 5) Smooth scrolling is not required everywhere. Things like small drop down menus would get no gain from the feature. It's the large text/content fields that need the feature.
I'd like to add yet something. 6) The feature doesn't have to be forced on. Take a notice how many times the feature has been requested. It's more than just "Votes: 1807" (shows that at this moment). Count them all together and you notice surprisingly many people like it. It was funny (and quite sad at the same time) to see some replies ca. 2000 to the requests.. Like "no, because *I* hate it we will *NEVER* implement it". Uh. Sad, so sad.
In relation to this bug report, I just noticed from comment 12 that Bug 93196 is marked invalid. Is this true, is this an impossible feature to implement (not talking about the smooth scrolling)? I am rather confident Bug 93196 would very populair if not marked 'invalid'.
Nothing is impossible. It's just a matter how laborious the feature is. And what's the developers' personal view on the importance of the feature. It's a common devastating problem among the open source "bazars". There isn't a client that would have the negotiating power (if they don't like the features they won't simply pay) and therefore the developers are calling the shots. They are a special type of people with their own distinct views that many times are very different from what the average user (of KDE for instance) has. To put it simply, engineers (an alike) are their own race quite different from humans. As for what comes to that feature most likely what was said was correct. It would be a lot of work to implement - perhaps too much. The development should be done in small increments.. First some sane way to scroll then perhaps later something more...
If you want it you are welcome to implement it. I don't anyone would object to a patch. As for possibility. Please read the comments to this bug before commenting. Try for instance the already mentioned shift+up, shift+down feature in konqueror.
>If you want it you are welcome to implement it. I want, I can't, and there are many the same. The reason a bug reporting service is here, is to report bugs, not to suggest if you want to go ahead and implement it yourself. I understand the technical issues and I understand some of the reasoning behind saying "engineers (an alike) are their own race quite different from humans". The truth is, all we have here is a wish. How can the wish be implemented, or can it? One weakness I perceive is calling a bug invalid and thereby overruling a likely popular wish. If a wish cannot be implemented, it can't. If it somehow can, why cannot the wish remain open? Labour time, perhaps, is the real problem? Invalid seems invalid unless obviously impossible to implement.
yeah....that's just the way this project works. The people who can won't, and the people who can't take the shit for it. Power corrupts, extreme power corrupts extremeley.
With the previous comments in mind, I'm still amazed that coolo is working on kde at all, since kde's mission is to attract the desktop market to linux. Somehow I find myself amazed with someone who uses the number of votes on some bugs to avoid working on them, and yet those with overwhelmingly high numbers of votes also get ignored, but this time with insults to the reporter, or irrational foolishness about how feasable the idea is or some mumbel jumbel like that. (usually just a vain coverup to make his decisions look justified) If you want to know who I think should be leading the project, I would suggest someone who isn't a coder, but who a little bit of management ability, and vision, like anlar who commented earlier. I think it's time to abandon this project and start a new desktop, possibly using kde code, but certainly excluding coolo. And to all you who were impressed by anlar's well reasoned comments, congrats! You can think reasonably, and I admire you for seeing that what he says is true and reasonable. I would highly suggest forking the project, or finding someone like him who can keep lazy asses like coolo working.
Oi folks, can everyone please stop name-calling and become reasonable? I don't think the KDE bug db is a good place for that (and really, I don't think there's a better pace so better start stopping that)... brrrr folk, calm down.. rgrds
I agree that this isn't the best place to discuss the quality of service this free portal provides. I would wonder, though; at the very least, I think Konqueror needs smooth scrolling, and the backend is there already. I mean, all someone would have to do is call the function that's called by SHIFT+UP/DOWN, passing it the number of pixels in ~3 lines of text (or whatever the user sets the scroll rate to). I guess you'd also have to pass how fast you want the scrolling to go, and possibly the khtml object... I dunno, I've never programmed for KDE before (much less much of anything). Really, I doubt if there's a technical reason why this would take more than a day, or possibly just 20 minutes, to implement. It can't possibly be labor intensive. So my questions, for anyone who can answer, are... Is there a single, specific function where the already-in-place scrolling takes place? Is it in Konqueror, KHTML, KDE-base/libs or Qt? How flexible is the function?
People, please do not confuse things! The problem here was with Bug 93196, not this bug! For Bug 93196 it's simply a matter of, can it really not be implemented? If it somehow can, calling the bug invalid seems to make no sence. That's pretty much all what my point was. No use discussing this here, but when bugs are called 'invalid' for not too obvious reasons, people have to complain about that somewhere, they will, it's an open system after all.
The point in taking out bug 93196 is that it can't be implemented in kdelibs, which is the product reported to have the problem. It's not a kdelibs issue, though; that's like trying to say that icon spacing on the desktop is messy, so kword should fix it (not that it's that obvious, but you get the idea). Anyway, smoothscrolling is already implemented in Konqueror. Whether the code is in Konqueror, khtml or another place (and I'm thinking it's in khtml), that's what we need to find out. Then, we need to close this bug and open a NEW one that references the correct product (notice this one still references kdelibs. This does us no good). The new wish should simply be for a setting to use the already-in-place smooth scrolling code to emulate smooth scrolling as it works in other browsers (IE, Mozilla Firefox, etc). But first things first; where is that code really located? Then, past that, if we want smooth scrolling in other apps beside konq (or possibly any khtml product), we'll have to find another place to ask for it. Maybe all the textBox, khtml, etc. widgets can be made to inherit a whole new class that replaces its scrolling code, but that most certainly *is* a lot of work.
Nice to see you talking about forking the project. No-one of you is able to code this feature - everyone claims to be a two liner? But you want to fork? Go ahead! And beside that, I for one will ignore this bug as long as over half the votes are fakes.
Coolo, you arrogant bastard!!! Someone ought to put you out of your misery.
(at the risk of feeding a troll) No one's forking anything. The closest thing to that is my comment about moving code so that more widgets can benefeit. If REAL developers (which I'm not) don't like the idea, they wont do it. Where'd you get the idea of forking? And how can people fake votes? I think a new wish should be opened referencing the appropriate product. Then, someone should post a link to it to this bug, and this one should be closed.
I removed 43 dummy accounts that were only setup to increase the vote number of this bug.
I guess that explains the thousands of Jack's... :-) Sorry you've had to deal with a lot of trolls here, coolo. I'd get pretty frustrated, too. Can't blame ya! I take it then you're a sort of moderator. Could you please find out where this sort of wish belongs so we can start a new thread, hopefully without as much trolling?
Indeed, take it easy guys. Kulow, are you sure that they actually were dummy accounts? Some people might have created their account honestly just to vote for a feature. Did those users have same IPs or something like that? Doing such thing is lame >( As for what comes to the technical things, I read that most of the QT widget areas can be panned creating a "smooth scrolling". (That was a very quick googling session just out of curiosity.) The QT or KDELIBs neither support such features directly but there are hacks and tweaks... Someone who has worked with KDE for a longer time probably knows what it would take rather well. At least my intention was not to start any sort of trolling, flooding or calling some developers names. Why I just had to comment on the original bug report was that - I am rather busy (I got a job and I am studying) so I can't code myself. It would require non-interrupted time. - Learning the specific areas of libraries etc would be quite non-productive work since there are people who can simply do the stuff better and faster. - I have been pondering about usability issues for years on my own. It has been also nice having a personnel oriented work. They really can amaze you every time when you think you've seen it all. - One thing I am studying at the uni is usability issues, cognitive sciences and such. Fascinating stuff though I have just started. - I would have lots to say about KDE and how it works but the most screwed up feature that just bugs me constantly is the scrolling. It's just plain wrong. Ah well.
> Did those users have same IPs or something like that? All "users" had email addresses of the same uncommon free email provider.
I guess it is best that I admit that I was the person that added all of those false votes. Looking back at me I see it was a stupid, immature thing to do, completely defeating the whole system. I hope you accept my apology. I can't believe I was such an idiot to do this, I feel much remorse. I seriously don't know what I was smoking while doing that. Someday I hope I can make up to the KDE project for doing this, maybe when I get old enough to obtain a credit card I will donate some money. As a side note, I hope you've disallowed the use of that domain as an email address, so this can't happen again.
Well (assuming you really did do it), I'm impressed that you'd admit it. If every troublemaker spoke up and took responsibility like that, the world would be a MUCH better place!
> ------- Additional Comments From z19ar unb ca 2004-12-20 03:36 ------- > With the previous comments in mind, I'm still amazed that coolo is working on kde at all, since kde's mission is to attract the desktop market to linux. Somehow I find myself amazed with someone who uses the number of votes on some bugs to avoid working on them, and yet those with overwhelmingly high numbers of votes also get ignored, but this time with insults to the reporter, or irrational foolishness about how feasable the idea is or some mumbel jumbel like that. (usually just a vain coverup to make his decisions look justified) > If you want to know who I think should be leading the project, I would suggest someone who isn't a coder, but who a little bit of management ability, and vision, like anlar who commented earlier. I think it's time to abandon this project and start a new desktop, possibly using kde code, but certainly excluding coolo. > And to all you who were impressed by anlar's well reasoned comments, congrats! You can think reasonably, and I admire you for seeing that what he says is true and reasonable. I would highly suggest forking the project, or finding someone like him who can keep lazy asses like coolo working. wooooow, what you posted (just noticed it) is so neglectant and unfair, _you_ should be the one excluded from KDE (you're lucky off being ignored only..). Coolo and Mr Binner have brought KDE all the way to where it is now by investing a great lot of sweat time and money in it. They made many right decisions, they are eager bugfixers and feature-implementers, and you should be ashamed of yourself writing such crap. Imagine being in their position, how would you react to people complaining in a tone, without having contributed ANYTHING ever, insulting your work and not recognizing the facts? Next time first second third THINK before you troll and piss off people who don't deserve it.
Marcel! You broke the wall of silence.. ;) Seriously. I would like to add a few comments on a possible implementation if some newbies want to help out. First I think the page-down problem is the most serious, so I assume an implementation would start there. First: There is _no_ such thing as smooth scrolling. It is an illusion. What you do is split the scroll in smaller time-delayed steps. Second: Because the "smooth" scrolling is time delayed it will _always_ be slower than normal scrolling. So first you have to decide how fast you want the scrolling to be, and second you would need a way to speed up the scrolling if the user hits the down/page-dn key faster than you are already scrolling. Page down case: Lets say a page-down scroll should take 100ms as default. Catch the page-down key and then register a timer for an event every 20ms or so, and for each timer event scroll one fifth of a page. If the repaint/scroll takes more than the allocated time, multiple timer events will be cued. In this case the computer is too slow, and we should scroll in bigger steps.
Allan Sandfeld wrote: >Page down case: Lets say a page-down scroll should take 100ms as default. >Catch the page-down key and then register a timer for an event every 20ms or so, and for each timer event scroll one fifth of a page. If the repaint/scroll takes more than the allocated time, multiple timer events will be cued. In this case the computer is too slow, and we should scroll in bigger steps. > > I'm curious about the timer slice that you suggested: AFAIR, 20ms is a very small step - most times you'd get called after much more then 20ms have passed. now, for smooth scrolling, I would figure that scrolling fifth of the screen at a time won't give anything close to the required "smooth" effect - I would suggest something like 1/10th of the screen or even smaller steps. for the suggested 100ms scroll (which is really really fast, I wouls say something like 250ms) a timer as small as 10ms or smaller is needed and I doubt you can get that high resolution on the current crop of PCs running Linux (and other free OSs).
The timer was selected to give 50fps, 25fps is minimum to make to it look animated and 50fps is minimum to make it look smooth. The 100ms total is chosen to be as fast as possible and still smooth; but without an implementation to experiment with, it is just a guess. The reason to choose something this fast is because I want to avoid adding another option, and 250ms is noticeable slow and sometimes used for fast hover effects. I am afraid if scrolling appears sluggish that people will require an option to disable it.
Allan Sandfeld wrote: > ------- Additional Comments From kde carewolf com 2005-01-05 22:06 ------- > The timer was selected to give 50fps, 25fps is minimum to make to it look animated and 50fps is minimum to make it look smooth. The 100ms total is chosen to be as fast as possible and still smooth; but without an implementation to experiment with, it is just a guess. The reason to choose something this fast is because I want to avoid adding another option, and 250ms is noticeable slow and sometimes used for fast hover effects. I am afraid if scrolling appears sluggish that people will require an option to disable it. I still think an option to disable is a very good idea. Adding a "scroll speed" option shouldn't be too hard either. When there is discussion/argument over what the value of a constant should be, maybe it shouldn't be a constant after all. After all, that is what opensource is all about, right? One value does not satisfy everyone, so if people can choose, the developer only needs to pick a relatively popular default value.
Take a look at this bug: http://bugs.kde.org/show_bug.cgi?id=26998 "Makes everything feel slow" ? I read the above comments about how smooth scrolling is always slower. However that's talking about milliseconds. That time should be easily more than earned back with the advantages that comes from the smoothness. The amount of time it should take to get to ie. spot x on text from the starting spot y should be pretty much constant with and without smooth scrolling. (The difference is quite small.) It is the showing the states in between line hops that matters and brings the usability advantage. There are ready acceleration algorithms with a certain curve for interpreting for instance the mouse wheel. Mozilla project might have some examples on how to handle the issues? When implemented properly they perhaps make some situations feel more intuitive. When implemented bad they can really ruin pretty much everything. I think I have somewhere saved a scientific study about the matter but I can't seem to find it right now.. I don't quite get how the feature could in the end make anyone feel slow (when implemented properly). Ancient hardware? Bad implementations? Perhaps there are too many bad implementations around.. It's a pretty sensitive feature to implement. Things being tuneable is not a bad idea. That's why there is the control center. (The other bug that I linked to, eww.. Look at how HARSH against the end user that other developer was. How can the voting system work if people are practically shot for their thoughts?)
Am Thursday 06 January 2005 15:30 schrieb anlar: > However that's talking about milliseconds I think you underestimate the time it takes to shift large pixmaps on X. But yes, we're always talking milliseconds - just the number of them varies ;) Greetings, Stephan
I know it can be slow to handle pixmaps on X, painfully well. With my hardware I can't get hardware accelerated pivot (CCW rotation of the screen for my tft panel). The software version that is available to me due ancient architectures (X is from early medieval ages atm) etc is so bad that redrawing the whole screen (ie. when I press pgdown with a document) takes 2-3 SECONDS. Silly how Windows XP does the same with software like 50 times faster... But that's a different issue. My point being: Although a perfect implementation is not realistic it's just about how well it is implemented... At least the smooth gtk applications I have seem to behave in timely manner so there should not be horrible general level problems around. But you know the implementation side a lot better...
On Friday January 7 2005 05:48, Stephan Kulow wrote: > I think you underestimate the time it takes to shift large pixmaps on X. It's at least feasible in that order of time since Firefox does it. > But yes, we're always talking milliseconds - just the number of them varies > ;) Right, you people should try and implement it before arguing about the values of the constants.
Created attachment 9700 [details] Patch for smooth scrolling This patch adds a KScrollView to kdeui, and makes khtml use it. It is very few lines of code and works very well. Beware however that it interferes slightly with the existing smooth-scrolling features like shift+up/down, which should just use regular scrolling now.
Created attachment 9741 [details] Updated patch I've updated the patch to also animate mouse-wheel scrolling.
*** Bug 61915 has been marked as a duplicate of this bug. ***
I like it. It's true that it behaves a bit strange together with autoscroll, but it's nice and even consistent with autoscoll, so I don't see a reason not to add it the way it's now (even though I have no wheel mouse, but I assume it's just working as nicely)
When messing with anti-aliasing settings and sub-pixel rendering, I noticed the text-rendering became heavy enough that smooth scrolling maxed 100% cpu (in the X-server). So I still need a way to collapse multiple timer-events. I just don't know how to do that in Qt. Basically I need to ask if any more events from this timer has been posted to QApplication.
CVS commit by carewolf: Experimentally activate smooth scrolling generally to see if any real issues pop up, and if we need configuration, and of what kind. CCBUG: 76082 M +23 -23 khtmlview.cpp 1.693 M +7 -7 khtmlview.h 1.219 --- kdelibs/khtml/khtmlview.cpp #1.692:1.693 @@ -457,5 +457,5 @@ void KHTMLToolTip::maybeTip(const QPoint KHTMLView::KHTMLView( KHTMLPart *part, QWidget *parent, const char *name) - : QScrollView( parent, name, WResizeNoErase | WRepaintNoErase ) + : KScrollView( parent, name, WResizeNoErase | WRepaintNoErase ) { m_medium = "screen"; @@ -2798,5 +2798,5 @@ void KHTMLView::viewportWheelEvent(QWhee { d->scrollBarMoved = true; - QScrollView::viewportWheelEvent( e ); + KScrollView::viewportWheelEvent( e ); QMouseEvent *tempEvent = new QMouseEvent( QEvent::MouseMove, QPoint(-1,-1), QPoint(-1,-1), Qt::NoButton, e->state() ); --- kdelibs/khtml/khtmlview.h #1.218:1.219 @@ -27,5 +27,5 @@ // qt includes and classes -#include <qscrollview.h> +#include <kscrollview.h> #include <kdelibs_export.h> @@ -75,5 +75,5 @@ class KHTMLViewPrivate; * Suitable for use as an application's main view. **/ -class KHTML_EXPORT KHTMLView : public QScrollView +class KHTML_EXPORT KHTMLView : public KScrollView { Q_OBJECT
Could there possibly be some sort of SLOT/SIGNAL type thing added for smooth scrolling? At the least, an application could have a way to signal that it has support for smooth scrolling, and the scrollbar would take care of some of the logic.
How is it realized in Firefox? Because the scrolling works perfectly, also with the mousewheel klick - and bwt the scrollcross in this mode should be redesigned (I love it the way it is in Firefox and also the speed of scrolling is very nice)
Still looking at unusually high CPU usage while scrolling in Konq and watching remote emerges in Konsole. Has this patch been applied on a global scale, or am I completely out to lunch?
Created attachment 10361 [details] The current diff from CVS I wrote a smooth wheel scroll hack for KHTMLView a long time ago, and posted it to kfm-devel back in 2002. Nothing became of it (it's an ugly hack anyway), though I've been using it since. I don't even remember exactly how it works now, nor have I looked at KScrollView yet, but the code I had seems to fairly light on CPU usage. I'm posting the patch here in case anyone cares to compare it to the KScrollView stuff.
OK, I just compared KScrollView with the "scrolling hack" (see my previous note), and the behaviour is rather different. It would be much better if KScrollView could increase the scrolling speed as the wheel continues to be turned, and then gradually decrease as the timer fires. In other words, smooth acceleration and deceleration. It definitely feels more natural and makes scrolling large pages easier than a fixed rate (please test the scrolling hack to see what I mean). However, my attempts at modifying KScrollView::scrollBy() to get this to work breaks keyboard scrolling. Someone, please find a way to merge the two implementations.
Hmm ... I switched from SuSE 9.2 to 9.3 this weekend. This has added smooth scrolling. And ... I don't like it. So where do I deactivate it? You don't tell me that I have to recompile, or? Thanks in advance
i wish a x-y scroll, like mid button in ie or firefox, but for all the virtual desktop, instead of the scroll of display borders.
KDE 3.5 is quickly appraching. Are there any news?
Yes: smooth scrolling will not be present in KDE 3.5.x.
This sounds like a good idea for a feature, although if it is implemented it should be selectable in the KDE Control Centre or Konqueror's options as some users may personally dislike it and it would be a performance killer on slower machines.
> would be a performance killer on slower machines Do you mean 486DX PCs? E.g., Mozilla Firefox with smooth scrolling turned on works nice even on Pentium 166.
Smooth scrolling should definately be an option which can be disabled. I, for example, hate it. In MSIE, I always turn it off - that's the first thing that I do before I can work with it. Regardless of performance issues, I find it highly distracting. But performance issues are also there, and I don't believe they can be eliminated. I'm currently using Mandriva Cooker and with the latest kdelibs (kdelibs-common-3.5.0-6mdk), I've got the dreaded smooth scroll. I can testify, that the smooth scrolling: 1) indeed _slows down_ scrolling, not only makes it smooth, which leads to a waste of productivity for me 2) puts more stress on my hardware. I don't accept about Firefox smooth scrolling working even on Pentium 166 - I work on a 1 GHz Celeron with 1 GB RAM, and when I have some active tasks in the background, smooth scrolling becomes REALLY slow, and it also steals precious CPU cycles from my background jobs. Maybe in comment #60 Artem meant a usage scenario where a user only works with a single interactive application and there's nothing more running on his PC, but power users tend to launch a lot of background jobs and smooth scrolling is just a parasite functionality for them. BTW, I'm not alone, see this post http://www.kde-forum.org/post/41240/lastpost.html#post41240
It really shouldn't impose such a high load on a system. I mean, isn't middle clicking in konqueror and moving the mouse up or down also smooth scrolling? It looks pretty smooth to me, anyway.
Well, in my case it does impose load, especially when I browse more than 20 sites in one konqueror window (in tabs). Besides, the main problem is that smooth scrolling distracts me, makes my eyes feel uncomfortable, up to the point when I'm considering switching desktop environments. Even though Gnome is much less usable (IMO) and others like XFce have very limited functionality, if KDE receives such a detriment to comfort of usage, I'll have switch away from KDE, since I just cannot work with smooth scrolling for long periods of time :(
Hehe, why switch desktop environments, when you can just use Firefox inside KDE ;) ( That is, if you really feel you can't live with konqueror )
If that change affects widgets in other favourite apps (like kate, krusader, kword, kspread) this would make my work significantly harder...
On Monday 19 December 2005 17:50, aleksander.adamowski.kde@altkom.pl wrote: > 2005-12-19 16:50 ------- If that change affects widgets in other favourite > apps (like kate, krusader, kword, kspread) this would make my work > significantly harder... Gee, I can't believe how some of you guys can be so much of a cry-baby. If there's smoothscrolling in widget-level it'll be optional don't you worry -- *sigh*. OS community is so resistive against new things.
I'm not resistive against new things (e.g. I intensively use krusader, which is yet quite far from being included in main KDE). Smooth scrolling is an old thing (in MSIE, it has been around since the previuos century), which in my case is a usability nightmare. I simply don't tolerate it, it's like with Tabasco sauce - some people love it, and some people have instant stomach problems when they receive a few drops of it with their food...
On Monday 19 December 2005 18:26, aleksander.adamowski.kde@altkom.pl wrote: > Smooth scrolling is an old thing (in MSIE, it has been around since the > previuos century), I haven't seen any OS ( any MS Windows, nor Mac OS X) with a decent smooth scrolling. For my taste, only decent smooth scrolling available today is the one I've wrote for kopete ;) > which in my case is a usability nightmare. Turn-it-off. AFAIK official KDE doesn't enable any kind of smooth scrolling by default anyway (except for kopete). And there is no reason to whine about a distro patch in kde mailing lists, is there. > I simply don't tolerate it, it's like with Tabasco sauce - some people love it, and > some people have instant stomach problems when they receive a few drops of > it with their food... Interesting ;)
Well, some like transparancy, other don't. That's probably the main reason KDE included it as an option. How exactly does an option like this bother you? It wouldn't be too hard to make it optional, right? So I don't really see what all the fuss is about.
I'd like to bump in here, because I would like to believe in progress. Reading so many things about KDE4 and here are people just grinding my toes when it comes to smooth scrolling (. Would people against smooth scrolling have any reason to completely block this from entering KDE at all? Because all this is about is rather shamefull whining. I really am ashamed at reading some posts here. Yes, if it is optional and your ideal world of non smooth scrolling would remain in tact. Rest assured for whatever it is that makes this none-smooth scrolling desire being embedded so deep. Let's just focus on wether it should be a default or not. If it is not a default, it looks like KDE is rescued from certain demise to some. I'm sorry, I am not the right person to talk very constructive about these things, but for good sakes, stop the very silly "progress" being made here. This is a popular voted bug, it seems people want it, how and if the default seem to be the most sane issues to tackle here.
I'd like to bump in and out of here, because I would like to believe in progress. Reading so many things about KDE4 and here are people just grinding my toes when it comes to smooth scrolling (opened 2004-02-25 !). Would people against smooth scrolling have any reason to completely block this from entering KDE at all? Because all this is about is rather shamefull whining in my current view of the world and humanity for Pete's sake. I really am ashamed at reading some posts here. Just for a moment imagine a world in where smooth scrolling is _optional_, then for some the ideal world order of non smooth scrolling desktop environments would remain perfectly in tact. I would greatly enjoy to see a focus on wether it should be a default or not. I'm sorry, I am not the right person to talk very constructive about these things, but for good sakes, stop the very silly "progress" being made here. This is a popular voted bug, it seems people want it, how and if the default seem to be the most sane issues to tackle here. I need my pills.
Apologies for the double post, my mouse is beginning to have a life of it's own lately.
I think it's enough now of noticing that some people are whining here. Let's just implement it and make it the default with an easy-to-find option to turn it off, and if many people complain at bugs.kde.org, turn it off by default. I'm sorry that I only am able to produce PHP applications; if I could, I'd try to help here.
Much better IMO is to add it to the Desktop Settings Wizard. It would belong, of course, somewhere under the Fast Processor profile set. Otherwise, default to disabled. This way we don't follow Windows and make new features default for the sake of letting consumers know they exist, and if a user trying KDE wants to see the full feature set, he is going to choose to enable all effects anyway.
Yes, this is a good idea, I think.
Sorry, all this is a result of misunderstanding. I'm currently running a KDE installation that has smooth scrolling turned on, WITHOUT an option to turn it off. This is what I'm protesting - I want to be able to turn it off, I don't object to it being implemented. This is just probably a Mandriva - specific patch that I've received by autoupdating to their latest development RPMs. I thought it is in the current KDE source tree, as a non-optional feature for KDE4... I just don't want to be forced to accept some non-modifiable defaults, like we have in Gnome currently...
I've read on the Mandriva Cooker ML that it's possible to turn off, but there's no GUI for it yet. Add this lines on your $HOME/.kde/share/config/kdeglobals: [KDE] SmoothScrolling=false
since there is nothing like negative points for wishes, what else could you expect? its a actually a bug since khtml screw widgets and position:fixed so experience from smoothness of scrolling is more like headacke or turnbased strategy, this should be turned off by default. i would appreciated something for managing it by other way than editing ~/.kde/share/config/kdeglobals like "configure: Konqueror" perhaps
It's a really fantastic idea, and the line is an awesome idea!!! It should be a big touch :O
The suggested patches no longer apply cleanly onto KDE 3.5.6. Does anyone have any workaround?
About the idea of the horizontal marker line, I've done a mockup here: http://www.kde-look.org/content/show.php/Scrollbar+marker+line?content=61517 I always have to select some lines of text while scrolling page with a lot of text in order to know where I am, so it looks like a really nice and convenient concept while not adding unnecessary GUI (all can be done with a right clic on the slidebar) (don't know if this is technically possible however)
I'd also like to see this. I already use Firefox with the "SmoothWheel" plugin and "can't live without it".
Is there any chance to see "Smoothwheel" feature (optional) in KDE4? (I meant like does the Firefox plugin, but for all applications). The line is also a great idea.
Just another 'negative' vote, asking to make this optional. Dunno why, but I don't like smooth scrolling. Maybe because it always feels sluggish, to me.
Richard, now I am puzzled. I thought that this report is about smooth scrolling, which means (for me) scrolling as moving for example paper. When you move paper page by top, the bottom follows -- the opposite is wavy way, you move top of something rubber, and after a while the bottom follows (current implementation).
I'd also like to cast a negative vote. This functionality should definately be optional if it's implemented. Smooth scrollin not only feels sluggish for me, it actually IS sluggish except for very high performance hardware (CPU/video card) in a system without resource congestion. I use my workstation very intensively and everything that slows down visible results (which smooth scrolling is all about when you think carefully about it!) is unacceptable for me. When I scroll a document I want its viewport to reposition in split second, instantly, I don't tolerate even 200 milliseconds delays. I looked at all possible smooth scrolling implementations, they always irritate me as I wait until they stop moving at last. I prefer the jumpy movement as it's instant.
SVN commit 796960 by ggarand: Mousewheel-driven smooth scrolling support. This is based on nice experimental logic once made by Allan, that was later dubiously integrated by various vendors. The timings where revisited to enhance responsiveness, aiming for a feeling close to FireFox's. We support two main enabling modes : unconditional (Enabled), and energy-conscious (WhenEfficient) - that will avoid smooth scrolling pages with static elements. Improvements to scrolling efficiency for static elements will make the worst-case in Enabled mode quite rare, but still not unlikely. WhenEfficient is thus the recommended mode. CCBUG: 76082 M +18 -0 khtml_part.cpp M +17 -0 khtml_settings.cc M +7 -0 khtml_settings.h M +144 -6 khtmlview.cpp M +29 -0 khtmlview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=796960
Is there a way to turn it off this globally? I have found an option to turn smooth scrolling off in konqueror... but the khtml part in kmail still slow-scrolls...
is this going to be in kde4 anytime?
Going through this bug, I am disappointed at the behaviour I see people treating each other here. Really, is all the name-calling necessary? I see that there are a few (but not many) voters who vote for this bug _only_ so I suppose those are dummy accounts. Should I list them so that they could be closed? I would like to see this feature implemented as one cannot even read the 90+ comments due to the bickering.
Single voters are not worse or better then regular voters. KDE bugzilla is not a beauty contest. Besides -- it is pure logic, how are you going to vote for the second time if you are not allowed to vote for the first time? (rhetorical question)
Thomas Schildknecht (comment #81): What you want is bug #93196
And? is there any progress on this? For me, it's one of the most wanted features just after KAuth.
A response to some of the points raised here: * "All computers built within the last X years should be able to do Y" -- What about computers built before that? And highly mobile laptops with literally no graphics power? My main machine is a Thinkpad X31 and KDE 4 is slow enough as it is. Also, KDE is supposed to run on smaller and smaller devices (which admittedly have more and more GFX power). * While smooth scrolling is something most people prefer, I actually like the instant scrolling which all shell programs have. So the old fast & hacked-up scrolling is something I actually prefer. Might be weird, but FLOSS is all about choice :) PS: I use the space bar to scroll in Konqueror which scrolls a full page. I would be even happier if that had no scrolling animation at all. Just look at stuff, hit space *bam* new stuff.
Of course this feature should be configurable and disablable. At the moment there is a configuration option in the advanced mouse configuration module which allow to change the amount of lines scrolled by the mouse wheel. I think this option should be part of the smooth scrolling configuration and this should propose scrolling by number of lines or number of pixel or % of view height. I think this would satisfy anyone ...
Cedric: Sounds good to me.
Wow, it's now year 2010 and this feature was implemented for all controls in 1997 in Windows 98. Wonders.
As long as you can disable it, why not. I hate this "smooth" (lagging, delayed) scrolling.
Hi. I have to notice that scroll works fine when I've run few applications (firefox, amarok, kmail, kopete and ktorrent). After a while (5-10 min) scrolling becomes very slow. CPU usage in this time is a small, but when I starting scrolling my music collection in amarok or folder in dolphin, or web-page on firefox I have 100% CPU (60% xorg and 40% kwin). When I close one of those applications that I have running (kmail for example) scrolling again works fine (for 5-10 min), not quite perfect, but CPU usage is approximately two times less. I use proprietary nvidia driver and already seen — http://techbase.kde.org/User:Lemma/KDE4-NVIDIA but this not help for me.
This applies not only to scrolling the entire interface is retarded
I want this feature too. Is this the right place to add something to the requested feature? smooth scrolling + kinetic (momentum ) scrolling (the type you can get with a touch pad) for a mouse wheel, would be great. of course it should be toggleable.
Kinetic scrolling is probably worth a new feature request. Creating cross-links between both requests would make sense, though. And yes, optional, optional, optional ;)
Plasma itself does have smooth scrolling as far as I can see. Would it be hard to add this ability to the rest of the KDE SC (or whatever it is called nowadays :-P)?
This is a reply to all commenters complaining about performance issues related to smooth scrolling. My computer is ten years old and the smooth scrolling doesn't impact performance at all. Either even a ten year old computer is fast enough, or the ScrollWindowEx somehow offloads some of its work to the video card. (The existence of ScrollWindowEx also means that activating this feature can't be hard, at least on Windows. And I can't imagine that X doesn't have something equivalent.) Of course, there is the trivial performance penalty that if you set a third second smooth scroll, scrolling will take a third second longer. However, the added fluidity easily compensates for that and all people I know (no, I don't know a single exception) prefer smooth scrolling. I really don't know where the anti-smooth-scrolling crowd in online discussions comes from.
If experience has shown anything, it's that some thing work better for some and worse for others. This is part of the reason why an actual blacklist of effect/gfx card combinations is being implemented atm. The second half of your post seems to boil down to "I like it and so do people I know" which is irrelevant to the argument of "there are people who like it (for whatever reasons) and people who don't like it (for whatever reasons) so it's best to please both sides by making it optional". In any case, I am not sure if "I like it" and "I don't like it" are suitable for a bug tracker. If you want to discuss this further, the mailing lists or IRC seem like the best place to do so.
Richard Hartmann, you're wilfully missing the point.
In response to comment #105: Shinobu, maybe the set of all people you know is not very representative? For me personally, a delay of 1/3 second (or, for that matter, even 1/10th of second) is very noticeable and irritating. This may depend on many factors; some people also don't see a difference between 25 fps and 29,97 fps video while others notice; some people don't feel any discomfort when watching a CRT monitor with 60 Hz refresh rate, others get immediate eye strain and headache and only tolerate >= 80 Hz. Some people notice the difference between 90 Hz and 100 Hz refresh rate. Also, the delay introduced by smooth scrolling noticeably slows down the interaction with the UI (I'm a person that tends to interact really fast with the UI, and all delays on the order > 1/15 sec are an impediment). If I scoll down with smooth scroll with intent of placing the caret in the needed location, I cannot type immediately, I must _wait_ a full 1/3 second before I see the final effect and can start typing. Maybe all the people you know simply have slow vision or lag in interaction with the UI?
Or maybe smooth doesn't have to mean slow and the brandishing of this kind of false dichotomy as justification is why people are leaving KDE in droves. :(
(In reply to comment #108) Ok, you are right, all people have their own preferences. But be consistent and judge for yourself, why now counts only preferences those people, who do not like the smooth scrolling? And what about me, who likes it? What about those people, who have slow vision and interaction lag? Where we all can put this big, fat tick "enable smooth scrolling"?
Plasma has kinetic scrolling. QT fully supports it nowadays. This bug is extremely old and it undoubtedly provides a usability boost to kde. The plasma guys have implemented smooth scrolling already, I don't see why it should be so hard to implement on KDE. I really think this should be a priority. We're talking about a major usability improvement.
But if smooth scrolling in normal KDE apps is as HORRIBLE as scrolling Plasma widgets/lists, then I would really NOT WANT IT.
Smooth scrolling drives me crazy. I always turn it off no matter where I find it turned on, even if the computer is not mine.
(In reply to comment #113) > Smooth scrolling drives me crazy. I always turn it off no matter where I find > it turned on, even if the computer is not mine. Funnily it's implemented in _all_ controls in Windows since 1997 and I have yet to find a single person who doesn't like it. The whole world is happily using this feature (it's implemented even on Android) and Linux/OSS guys still argue if it's needed or not. OMFG.
I am well aware of the irony of answering in this thread calling for people not to answer in this thread, but: Arguing back and forth does not lead anywhere. It's obvious that there are extremely strong emotions in both directions. It's also well established that the only way to avoid any more arguments when implementing this is to make it optional. I am sure we can all appreciate how hard it can be not to knee-jerk and start the whole thing anew. But it's not leading anywhere and just sends email to all the people who have no interest in Yet Another Iteration.
Richard is right, people who do not want this feature should not be sent more messages that won't interest them. My apologies guys like Felix, KaiUweBroulik2, an all the others who really don't want to hear about it. We honestly understand and respect your views. We won't bother you with the threat of unwanted defaults anymore. As Richard said, it's clear that there have been misunderstandings and heated debates in the past but now it's high time the ancient animosities went away. Those who dislike smooth scrolling have the right not to be bothered by an unwonted feature; but please do recognize that many others want it big time, and give us the right to work on something we care about without being told how much you dislike our idea. We won't make it default, we just want to have an option that would make us so happy. Now I suggest that everyone who is interested in this project should get together and work on a patch for KDE 4.6. Maybe we should start another bug, and avoid irritating those who don't want to be bothered by this feature. This bug could be closed since is leading nowhere. I'm no KDE veteran, so please suggest a better place where we could have a fresh start if you can think of any. Those who don't want to be involved should not be bothered, those who want it, please join this new effort and let's get this thing moving alright? Thank you.
(In reply to comment #116) > My apologies guys like Felix, KaiUweBroulik2, an all the others who really > don't want to hear about it. We honestly understand and respect your views. We > won't bother you with the threat of unwanted defaults anymore. > > As Richard said, it's clear that there have been misunderstandings and heated > debates in the past but now it's high time the ancient animosities went away. > > Those who dislike smooth scrolling have the right not to be bothered by an > unwonted feature; but please do recognize that many others want it big time, > and give us the right to work on something we care about without being told how > much you dislike our idea. We won't make it default, we just want to have an > option that would make us so happy. forgive me for being blunt, but this sounds like an appeal to emotion rather than reason. if, as others have pointed out, most modern platforms have this feature turned on by default, then don't you think there is a good reason for it? my guess is that some credible studies have shown that the majority of users experience an improvement in usability when smooth scrolling is on (and well implemented, of course). i further surmise--call it an intuitive guess--that the improvement is more drastic on touchscreen devices. sorry that i can't provide any citations--i'm not the usability expert here. rather, i'm calling for someone to take on this role--don't you think that this should be researched as a basis for deciding which option should be the default? the existence of a vocal minority of users who objects to one option or the other is no reason at all for deciding in their favor. if KDE is a desktop environment for audience X, then its defaults should match those settings that the majority of X prefers, and it should provide complementary options for significant minorities in X. so please, as part of this bug or as a follow-up to it, do the appropriate research to determine defaults instead of making arbitrary decisions based on a few people's heated objections. of course, this is a secondary issue. poorly chosen defaults are still better than not having the feature at all. thanks to anyone who is working on implementing it one way or the other.
Ivan, that's a good point, but I wanted to move the debate from whether it should be a default to how to implement it. First we need a patch that works then we can start evaluating if it is good or not for most of the users. By all means I agree that a usability study would be welcome, but that shouldn't distract us from working on the actual problem. So I suggest we move on and stop arguing about defaults until this thing is 100% working (it wont be tomorrow ;) ). Has anyone tried to use the patch from comment #87 in kde 4.6? It seems not exactly trivial with about 200 lines of code. But I'm sure it could be a good starting point.
I have to withdraw my initial comment, I noticed that rekonq uses smooth scrolling and I really like it compared to the jerky scrolling behavior in other KDE apps. Go for it :) And since this is KDE, there definitly will be an option to turn it off^^
Would be great to have smooth scrolling in all widgets (but not so ugly like it is in plasma now). It should be smooth but fast, kinetic a little (but not so excessive how it is in plasma). Should be smart enough to understand when it could accelerate and when it should slow down and when it should stop, because scrolling in plasma is so "kinetic" so it doesn't know such things, perhaps devs think it's funny... I don't think so, it is not usable when content flying hither and thither before my eyes. I am against of that "smooth" scrolling in KDE like it is in plasma, because it is not so smooth like wild. In my opinion it is good realized in Firefox, also Kopete uses smooth scrolling too and it looks great (not perfect, but good enough). Scrolling should know how fast it should be focusing on the widget attributes like client height and scroll height, on mouse wheel intensity, items attributes, etc. But, perhaps it should be a QT wish, instead of KDE. Regards.
They better fix all the laggy and ugly resizing issues and redrawing issues and lags before adding new features …
Oops, see that QT already supports it, so this is only KDE issue.
Well the naysayers have to just use this feature in a macbook pro and then say no. Coz it's the best implemented platform for this feature and it just is WOW. it's enabled system wide and it's not jerky, nor does it lag performance even during intense photography related work. This is one feature that will "add" to the smoothness of the platform. Nothing much but smoothness and refinement. Well I just came to know windows implemented this feature from 1997 coz I've never experienced it :) maybe such is the implementation. But if you want to set a standard to work on this feature, then it's got to be from the mac platform. Maybe like the blur plugin, disable it when it cannot be handled by the hardware.
Why is a 7 year old bug 'NEW', and why do 2622 votes make it 'NOR' priority? It's puzzling that in so many years no one did anything about it (last patch in 2005), not even out of pity, or just for the sake of it. Nothing. And as for usability studies, just use a macbook in a shop. I wonder who would then say it's better to have the jerky scroll instead, probably someone who would also prefer using Motif over Oxygen.
> Why is a 7 year old bug 'NEW' It can be 70 years, and "NEW" would still mean "acknowledged". The wording is unfortunate, you could post a bug report about it, or better fix it yourself, because as usually nobody would care.
This feature cannot be implemented in kdelibs so that existing applications automatically get smooth scrolling, because kdelibs does not handle the scrolling. It would have to be implemented in QScrollArea, or at least in QScrollBar. Note that rekonq uses QWebKit, which does not use a QScrollArea, but handles all scrolling itself. As for the Plasma/QML components already handling smooth scrolling, it will be a lot of work to port applications to QML.
(In reply to comment #126) The Qt component is outside the scope of this bugzilla, so effectively this bug status must be WONTFIX. If anyone is still genuinely interested this bug can (and probably should) be reinstated here: http://bugreports.qt.nokia.com/
shouldn’t it rather be “UPSTREAM”?
You are correct, it would be UPSTREAM. But I didn't want to risk over 2600 voters killing me for marking that bug as RESOLVED ;)
> But I didn't want to risk over 2600 voters In fact here just 154 voters, > killing me for marking that bug as RESOLVED ;) but there still the risk of unrest.
Hang on, wasn't there a patch to KdeLibs, kscrollview posted in 2005 that actually implemented the feature in 3.5(.4)? What's wrong with that approach if it works (at least as a proof of concept)?
There is nothing wrong with the patch. But it should be in Qt, not in kdelibs, because KDE has no "scroll area" classes anymore.
XI 2.1 now supports smooth scrolling. http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html Now that the proper framework is in place, it should be possible to implement this function in all apps, just like it is possible to use inertial (or momentum) scrolling on many touchpads.
What happened to this feature request? This should be doable in Qt5. Will we see smooth scrolling in Frameworks 5?
Qt 5.3 does support XInput 2 smooth scrolling, confirmed working with apps ported to (such as KInfoCenter) - from what I can see it only affects touchpad scrolling (ie. two finger scrolling gives you a smooth mobile like experience). I did not test if it affects mousewheel scrolling too.
Well, that's very nice to know. If anyone ever tests mousewheel scrolling too, could you report the experience here? I'm most curious :)
In theory it works with mouse wheels too. Though most mouse drivers does not activate high resolution mode (I think only the Apple magic mouse does it by default). If the mouse driver in the kernel is updated and it detects the high wheel resolution feature activates it and reports the scroll events as high resolution, it should get passed through the stack of mouse driver -> evdev -> xinput2 -> Qt and work. I haven't had my hands on a mouse where it does though.
I can confirm that KInfoCenter has smooth scrolling in the docs display area, but not in the topics list area on the left side, I don't know if it's intended. My current KDE version is 4.12.2.
I was of course talking about smooth scrolling using mouse wheel. My mouses are Logitech Cordless Desktop MX and MSI ES130.
Hi, it does work for me as well. The mouse is steel series fnatic edition.
Thanks all. Good to know this works for some hardware. It's not working for mine (an MS Sculpt Comfort bluetooth mouse and trackpad on Acer Aspire S3-391) on KDE 4.12.3 (kernel 3.14) in KInfoCenter. Why does smooth scrolling only work in some apps (Dolphin, KDE Help Center) and not others? Why not use the same method across the board, such as the one that is not driver/hardware dependent?
Smooth scrolling does not work with mouse wheel on Wayland in Graphical info > Wayland section of Kinfocenter. Operating System: Arch Linux KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1
We already have smooth scroll for all Kirigami/QtQuick-based apps in KDE Plasma 6. (still no smooth scroll for most qt widget apps) https://invent.kde.org/frameworks/kirigami/-/merge_requests/1318 https://invent.kde.org/frameworks/kirigami/-/merge_requests/1321 https://invent.kde.org/frameworks/kirigami/-/merge_requests/1439 for kf5, please build this fork git clone --depth=1 --branch=kf5 https://invent.kde.org/kde--yyds/kirigami cd kirigami mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX=/usr make -j16 sudo make install
Unfortunately also no smooth scrolling here (except in Firefox) with: Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-21-generic (64-bit) Graphics Platform: X11
(In reply to ThomasvonderElbe from comment #144) > Unfortunately also no smooth scrolling here (except in Firefox) with: > > Operating System: Kubuntu 23.10 > KDE Plasma Version: 5.27.8 > KDE Frameworks Version: 5.110.0 > Qt Version: 5.15.10 > Kernel Version: 6.5.0-21-generic (64-bit) > Graphics Platform: X11 you can wait for kde plasma 6 or build the kf5 backport with the following commands git clone --depth=1 --branch=kf5 https://invent.kde.org/kde--yyds/kirigami cd kirigami mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX=/usr make -j16 sudo make install