Red Hat Bugzilla – Bug 1459120
[DELL 7.4 BUG] progress bar missing during file copy to desktop
Last modified: 2018-01-31 05:44:56 EST
Created attachment 1285343 [details]
screenshot for progress bar missing
Description of problem:
After installing RHEL 7.4 with GUI , if we try to copy a file (may be a ISO file ) to Desktop by click-dragging the progress bar is not shown for the progress of copying the file
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.install RHEL 7.4 snapshot 1 on X86_64 system in gui mode
2.login to the system and try to copy a file to the desktop
3.observe for the missing progress bar
missing progress bar during copy of file
shows progress bar during copy of file
1.There is no functionality loss as copy happens
2. Issue not seen in RHEL 7.3 GA version
issue is seen in RHEL 7.4 snapshot2 also. please help to understand why this behaviour is seen, also this was not seen in rhel 7.3
7.4 rebased Gnome Desktop.
In the new Gnome Desktop, Nautilus (the file browser) has a new "per window" notification system. If you copy a file from one window to the other you'll see a progress bar in both the source and destination window.
Unfortunately when you copy/move a file to the Desktop, Nautilus hands off to nautilus-desktop which appears to not give any progress/status.
(In reply to Karl Hastings from comment #4)
> 7.4 rebased Gnome Desktop.
> In the new Gnome Desktop, Nautilus (the file browser) has a new "per window"
> notification system. If you copy a file from one window to the other you'll
> see a progress bar in both the source and destination window.
> Unfortunately when you copy/move a file to the Desktop, Nautilus hands off
> to nautilus-desktop which appears to not give any progress/status.
That is correct.
This is only when source\destination is Desktop (not Desktop through nautilus).
There's no indication on whether the copy/move operation is complete or in-progress, which is not good.
What Karl mentions is correct, the problem is that the operation is handled by the desktop, which doesn't have UI for operations.
This requires some though design wise, the clearest options seems to be to display in the source window the operation.
That requires some communication between the programs, and is definitely not a trivial amount of work.
However, I'm actually working on a new desktop<->nautilus interaction for the next version, but this work is not backportable.
I will take a look how much work would it be to do another solution for 3.22.
Just a smaller clarification more, since comment 2 ask for know the reason behind it.
The difference between RHEL 7.3 and RHEL 7.4 is that the desktop is a different binary and process than Nautilus, given that we wanted to make them independent and avoid crashes of Nautilus if the desktop crashes, so we avoid work loss in those situations.
I'm going to move the issue to RHEL 7.5 where is more plausible to come up with a proper fix rather than risking a fix for RHEL 7.4 that could have more impact.
Unfortunately, I will have to - devel ack on this. It requires a considerable amount of work if we keep using desktop icons as we have been using until now instead of the future solution we are working on, and a solution on this would be detrimental for all the other operation code reliability of Nautilus.
A more technical explanation: nautilus-desktop even if being a different binary uses the lower layers of Nautilus code for operations. If we want the desktop to communicate with the other instance of Nautilus we would need to create vfuncs and split the code in a way that all those operations handled by default in the generic files-view are handled now in a fork of those.
At that point, actually forking nautilus desktop into a different project would be even a simpler and shorter solution, but it's not something I think we should be doing because 1- Will introduce a code path that is not tested upstream in a quite sensible part like operations, 2- this work will be useless for upstream and RHEL 8 or further versions, 3- We would need to maintain that new code.
The new solution we are working on is to have the desktop code in the compositor as GNOME Shell extension, and a DBus API to communicate for operations, so not shared code is used for the actual desktop view except for the shared API for the low level operations.
Considering this, how much of an impact is this for our customers?
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.