Registered Member
|
Dolphin becomes unresponsive after I navigate to a file (e.g. a document or text file) and click on it to open in an application. The file opens in the application as it should and the application window becomes focused. But if I then refocus Dolphin in order to find another file or open another directory, it is unresponsive. The previously selected file is still highlighted, but it is impossible to select any other file or directory. The only solution I have found so far is to close Dolphin and restart it. Basically, I can only select and open a file once after each start of Dolphin.
My current OS is Antergos (rolling release updated a few days ago) with Plasma 5.8.2. and Linux kernel 4.8.4-1-ARCH, but I have found the same problem on Kubuntu16.10 and the latest version of KaOS.
Last edited by dcbuist on Wed Apr 12, 2017 12:56 am, edited 1 time in total.
|
Registered Member
|
Does dolphin get responsive again if you close the external application?
Does this happen with *all* external applications or only with certain ones? What might happen is that dolphin (or kio) waits for a response that the application started successfully, but the application doesn't send one. |
Registered Member
|
Thanks for the reply.
So far, I have confirmed that it happens with four different file types and applications: text files in Kate, doc files in WPS Writer, pdf files in Okular, and jpg files in Gwenview. The problem is not always reproducible. Dolphin is unresponsive about 9 times out of 10 when I refocus it after opening another application. Closing the external application seems to make no difference to the frequency of the problem. I should clarify what I mean by "unresponsive" -- it is the lower panes of the Dolphin window (list of places and files) that don't function. The menu bar still works normally -- including the search box and backwards and forwards buttons. |
Registered Member
|
I was asking whether dolphin gets responsive again after you close the application, nothing about the frequency of the problem. If that's not the case (and it shouldn't anyway unless you modified the application's .desktop files yourself maybe), I have no idea, sorry. Doesn't happen here. |
Registered Member
|
The answer to your question is No. Once Dolphin becomes unresponsive, closing the external application does not make it become responsive again.
The only configuration change that I have made is to add an xprofile to /etc in order to use fcitx as the default input method. I cannot understand how that could have affected Dolphin. On the other hand, I have to admit that I never noticed the problem with Dolphin before I added the xprofile. |
Registered Member
|
Hello there!
Same problem here, all of the sudden. When I open any file, dolphin won't work anymore. It is pretty annoying. Any help would be appreciated. |
Registered Member
|
Still no resolution to the problem. It's intermittent but very annoying. I've been using konqueror for file management instead.
|
Registered Member
|
I too experience the same problem as described by dcbuist:
I open Dolphin and open any file. From this point on the problem has occurred. Dolphin is fully responsive except any panel which relates to folders and files, this includes: * Places (F9) * Folders (F7) * The main folder content area (which shows the folders and files within the current folder) Panels that seem unaffected: * Information * Console All menus and address bars are unaffected too. When in split view mode, the "main folder content area" of the second panel acts the same (unresponsive) and the address bar is also fully functional. Navigating to other directories works perfectly when using the address bar or the back and next buttons. The panels also change when in focus or out of focus. Basically, all seems to work with the exception that... hey just found something new.. the keyboard still works! ..so, basically, all seems to work perfectly with the exception of mouse events not being processed by these 3 specific panels. ..aaaaand I found something new while typing this post.. It seems mouse events ARE processed When I move my mouse all the way to the bottom of the "main folder content area", the panel seems to think I am hovering over the column headers "Name", "Size", "Date". When I click in this seemingly empty space at the bottom, I can sort the file listing in the "main folder content area" by Name, Size or Date. ..so, it seems that, after opening any file/document (which what ever starts a new program), the mouse coordinates seem to be processed with an offset. This is the information of my system: Ubuntu 16.04 xenial (KDE Neon), KDE 5.8.6 (KWin), Kernel x86_64 Linux 4.4.0-71-generic Resolution: 2560x2520 I also have an external monitor attached which is "Full HD" (1080p). I'm remembering that Windows has very poor handling of very high resolutions, and I am very glad KDE is surprisingly good at handling more 'extreme'(?) resolutions. I'm able to set interface size "2x" and all looks normal size and responds normal too. But, remembering the KDE team is still working hard on moving fully to Wayland, still using some X11 functions and with it having some problems with multiple screens, I just jerked my external monitor out of my notebook. Tadaaa!! Solved! Sorry for not getting to the solution right away guys. I was just trying to write down my experiences, hoping anyone would have an insight.. Didn't expect to solve the problem I was experiencing.. Anyway.. this solved it for me at least.. if anyone has experiences to share about this problem (if you can confirm this 'solution' also worked for you.. or not..), please share with the rest of us.. Thank you! Semi off topic: I got the idea of 'multiple monitors' to be the potential cause because on my desktop computer (this is another computer; not the computer which has the dolphin problem) always presents my login screen at a normal size on the beamer, and on my flat panel (which I actually use to login) at the size of 1 pixel. There does not seem to be a minimum size specified for the login screen if Wayland can't detect the screen's DPI (at least, this is what I think is the problem I have on my desktop computer). Only when loggin in and out does the login screen show normal size fields and buttons on both screens. This got me to read this article about KDE, KWin, Wayland and X11, which got me a better understanding of what was happening under the hood.
Listening to The Skeptics' Guide to the Galaxy podcast is like learning how to ride a bike, but for thinking.
|
Registered Member
|
Before I had seen BoonHead's reply, I had already solved the problem. It is indeed related to display settings and hdpi. I was noticing some similar problems in other applications, where menu bars were becoming intermittently unresponsive, but dragging the application window to a different display (e.g. from an external display to the inbuilt laptop display) consistently caused the problem to go away. I tried doing the same with Dolphin after it had become unresponsive and, yes, it does become responsive again after dragging to a different display. Different applications seem to be affected in different ways. With Dolphin it is the file list that becomes unresponsive (the menus are OK) but for other applications (like Kate, Konqueror, etc) it is the menus that stop working until they are moved from the external display to the laptop display.
I was also having another apparently unrelated problem with font rendering in certain applications (Qupzilla, Okular, qpdfview and lyx). While researching this issue, I saw bug reports about the "scale displays" setting in Plasma. Since I am using a hdpi display, I had the displays scaled to 1.5 so that the application interface widgets were not too small. After returning the scale back to the default value of 1, the font rendering issues went away. I also discovered that the problem of Dolphin becoming unresponsive no longer happened. In the other applications, I no longer have any problems of menus becoming unresponsive either. Simply scaling the displays back to 1 solved all these issues. (On the downside, however, application interfaces become a little too small, although forcing font dpi to 144 has largely solved that issue also). Since the problem was intermittent, I waited a while to see if it recurred. I have been using my computer with scale displays at 1 for over a week now, and the problem has not recurred. Information on graphics used:
|
Registered users: Bing [Bot], Google [Bot], rockscient, Yahoo [Bot]