Sorry, but the exact version number was not available in the selection above. I'm using konqueror 4.14.0 installed as part of the kde-baseapps package through a modified homebrew formula based on the one from the gbaty/kde tap (that one is for 4.13.0, but the same issue occurred with that one). this is installed with kde-runtime (and dependencies) from the adymo/kde tap. I'm using MacOS X 10.6.8, and have Qt 4.8.6 installed from homebrew as well. The issue is that the scrolling is unresponsive/laggy in any file view in konqueror. I saw some bugs mentioned online for a similar issue with the web browsing function in konqueror, but those appear to have been fixed. the issue there was that apple trackpad scroll events seemed to arrive too quickly for the application to handle, so the solution was to collect the events and pass them on to the application at a set interval. i don't know if what i installed includes those fixes, but it appears to be so, because scrolling is flawless in the web view. it's just in the file browser that it's at issue. other than this issue, everything is great! konqueror is so much better than the Finder. Reproducible: Always Steps to Reproduce: 1. install homebrew on MacOS X 10.6.8 2. $ brew tap adymo/kde 3. $ brew install kde-runtime 4. jump through a few hoops to get all the dependencies to build 5. manually add kde-baseapps formula (see additional info below for the formula) 6. $ brew install path/to/kde-baseapps 7. run konqueror, observe the scrolling behavior in the file browser veiws Actual Results: scrolling behavior in the file browser is laggy/unresponsive Expected Results: scrolling behavior should be as smooth and flawless as in the web browser view ######################################################## require File.join(File.dirname(__FILE__), 'base_kde_formula') class KdeBaseapps < BaseKdeFormula homepage 'http://www.kde.org/' url 'http://download.kde.org/stable/4.14.0/src/kde-baseapps-4.14.0.tar.xz' sha1 '9f0c7cda0ec0ca6fbe41696a753679f3e158fec2' depends_on 'kdelibs' depends_on 'kde-runtime' kde_build_deps end ########################################################
Hi, Does it make any difference if you change graphics system? QT_GRAPHICSSYSTEM=raster konqueror QT_GRAPHICSSYSTEM=native konqueror
(In reply to Tommi Tervo from comment #1) > Hi, > > Does it make any difference if you change graphics system? > > QT_GRAPHICSSYSTEM=raster konqueror > QT_GRAPHICSSYSTEM=native konqueror I can check, but...how do I set that? is it just an environment var i can set in my .bashrc? or is that a build option?
actually, google helped me with that. i tried this: $ konqueror --graphicssystem raster & but it did not change the scrolling behavior. this makes sense, though because the scrolling behaves well in other qt/kde apps and in the web view in konqueror.
also, it seems like it may be unrelated to the too-many-scroll-events bug i mentioned in the OP. the problem seems consistently to be that any slow scrolling does not register. only scrolling at a swipe gesture speed has any effect. so...kind of the opposite.
UPDATE: i just upgraded my OS to Mavericks 10.9.5, and reinstalled my whole homebrew prefix. fresh install of konqueror included. The issue persists, and the --graphicssystem option still does not have any effect. is anyone able to help? thanks for reading!
UPDATE #2: i have since discovered that the issue is not actually as I originally thought. If I hover the cursor over the scroll bar, then the two-finger scroll gesture works smoothly and beautifully. hovering the cursor over any other part of the file view gives the choppy/unresponsive scroll behavior that I described originally. Does anyone have any insight into this new development?
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!