Hi,

I wanted to ask about right clicking on folders in Dolphin. When I right click on a file, the context menu appear almost instantaneously. However, a right click on a folder will make the menu appear at least half to a whole second later, which is rather annoying. Is this supposed to happen? Are there any services I can disable to improve this behaviour? This is on version 15.12.1.

askembris wrote:However, a right click on a folder will make the menu appear at least half to a whole second later, which is rather annoying. Is this supposed to happen?

No.

askembris wrote:Are there any services I can disable to improve this behaviour? This is on version 15.12.1.

The best way to find out if any of the context menu services is responsible for this delay is to disable the services one by one ("Services" section in the settings dialog) and check if that helps. Can you identify a service that causes a delay?

freininghaus wrote:

askembris wrote:However, a right click on a folder will make the menu appear at least half to a whole second later, which is rather annoying. Is this supposed to happen?

No.

askembris wrote:Are there any services I can disable to improve this behaviour? This is on version 15.12.1.

The best way to find out if any of the context menu services is responsible for this delay is to disable the services one by one ("Services" section in the settings dialog) and check if that helps. Can you identify a service that causes a delay?

Hi and thanks for the reply.

I have a desktop with Leap and a laptop with Tumbleweed. The phenomenon seems to occur only on the laptop, which has Intel graphics (HD 4000). The desktop has an ATI 4870, otherwise they are both on the same versions (I update through openSUSE's KDE repo, but I do not update every single build). They are both on 15.12.1, though.

I will try to disable the services and enable them one by one to see if it's a service causing the delay. I will update on Monday, as I have the laptop at work.

Hi Frank,

I tried disabling all the services but the same behaviour persists - right clicking on folders makes the menu appear with a delay. It is strange that this occurs only on one machine (the laptop with intel graphics and tumbleweed) and not the other (desktop with ATI and Leap).

So, anything else I can try to get to the bottom of this?

Some extra information which may (or may not) be useful:

a) I have mounted a few Samba folders on local directories using CIFS. However, right clicking those folders yields the same behaviour as right-clicking local folders.
b) A right click on "blank space" in dolphin (i.e. not a folder or a file) gives the delayed menu. However, right clicking on a file (not a folder) will make the menu appear instantaneously.

I appreciate your help in this.

I can actually confirm this, stracing dolphin shows massive I/O on the entire udev tree when calling for a directory contextmenu - what will be the cause of the lag, but I've no idea why it happens (some solid re-init?)

Do you want me to file a bug report? Not sure what to report, if you can guide me how to obtain the trace, I can do it and attach it to the report (I assume simply saying "right-clicking folders is slow" will not be of much help).

Let's first see whether Frank knows an answer to my findings

luebking wrote:I can actually confirm this, stracing dolphin shows massive I/O on the entire udev tree when calling for a directory contextmenu - what will be the cause of the lag, but I've no idea why it happens (some solid re-init?)

Thanks for the investigation. This is because the context menu has an "Add to Places" entry, but only if the clicked folder (or the current folder, if you click the white space in the view) is not in the "Places" yet. Therefore, when you click a folder, it must be checked if the current folder is one of the "Places" or not. This has always been done in a quite ugly way, namely, by constructing an instance of the class which handles the "Places". Unfortunately, this class is also responsible for the devices which are shown in the Places Panel, and asks Solid which devices are present on the system. This is why you see these udev calls.

The solution would be to separate the access to the Places and the devices, I think. A class (maybe in KIO) that encapsulates access to the Places might also have some other benefits (make the code simpler everywhere where the Places are accessed, not only in Dolphin). I have been thinking about investigating this for some time, but found no time to actually do it. But in any case, I think that another change should be made first: There is agreement that it does not make sense that Dolphin, Konqueror and Folder View each have their own context menu implementation. A shared context menu could be implemented in the KIO library, see http://marc.info/?t=140826370800003&r=1&w=2 for some discussion on this. No work has been done on that so far though. Maybe I will try to look at it at some point, but I cannot make any promises.

freininghaus wrote:

luebking wrote:I can actually confirm this, stracing dolphin shows massive I/O on the entire udev tree when calling for a directory contextmenu - what will be the cause of the lag, but I've no idea why it happens (some solid re-init?)

Thanks for the investigation. This is because the context menu has an "Add to Places" entry, but only if the clicked folder (or the current folder, if you click the white space in the view) is not in the "Places" yet. Therefore, when you click a folder, it must be checked if the current folder is one of the "Places" or not. This has always been done in a quite ugly way, namely, by constructing an instance of the class which handles the "Places". Unfortunately, this class is also responsible for the devices which are shown in the Places Panel, and asks Solid which devices are present on the system. This is why you see these udev calls.

OK, so why is the delay much less evident in my desktop? The laptop is a core i5 with 16gb of RAM and the desktop is an AMD Phenom II X4 with 8gb of RAM. They also run different kernels, the laptop is on 4.4 and the desktop is on 4.1.3 (the current Leap kernel). I do not think performance-wise they differ so much as to justify the delay of the context menu appearing. If I hadn't encountered it on the laptop, I would not have been aware of it at all.

I am just asking so that maybe we can find a way to mitigate the issue. Adding something to "Places" from right-click is not something I do everyday (or ever, honestly, I simply drag and drop), is there a way to disable this check?

Come to think of it, when I drag and drop a place from the main window to "Places", if the place already exists, then a duplicate entry is created, there is no checking if it already exists. So why have such a check on the right click menu instead of foregoing the check and simply allowing the user to have duplicate entries, as with dragging and dropping?

Sorry for the pestering!

Reg. I/O all your CPU and RAM power is completely worthless - it simply relies on how fast some devices respond/can be opened.
@Frank, as a qnd solution one could possibly off-thread the query and activate the action delayed? (or really just show it unconditionally)

askembris wrote:Adding something to "Places" from right-click is not something I do everyday (or ever, honestly, I simply drag and drop), is there a way to disable this check?

No, this is currently not possible.

askembris wrote:Come to think of it, when I drag and drop a place from the main window to "Places", if the place already exists, then a duplicate entry is created, there is no checking if it already exists. So why have such a check on the right click menu instead of foregoing the check and simply allowing the user to have duplicate entries, as with dragging and dropping?

I don't know - as far as I know, it has always been that way.

luebking wrote:@Frank, as a qnd solution one could possibly off-thread the query and activate the action delayed? (or really just show it unconditionally)

Dealing with threads requires great care. I'm afraid a quick-and-dirty solution might introduce new problems OTOH, as askembris said, no duplicate checking is being done when dragging a URL to the Places, so I think that removing that check in the context menu is a good short-term solution:

https://git.reviewboard.kde.org/r/126904/

I've pushed the change that removes the check if a "Place" exists to the master branch now. In Dolphin 16.04, the "Add to Places" entry will always be shown in the context menu, without the (apparently sometimes time-consuming) check if it is a "Place" already or not. Thanks for bringing up this issue and for the analysis!

freininghaus wrote:I've pushed the change that removes the check if a "Place" exists to the master branch now. In Dolphin 16.04, the "Add to Places" entry will always be shown in the context menu, without the (apparently sometimes time-consuming) check if it is a "Place" already or not. Thanks for bringing up this issue and for the analysis!

Thanks for the update and your hard work, Frank. I am looking forward to using the - even more responsive - new Dolphin version!