Summary: | File operation dialog (moved to Desktop) can't be closed ( or automatically removed ) if widgets are locked | ||
---|---|---|---|
Product: | [Plasma] plasma4 | Reporter: | Dotan Cohen <kde-2011.08> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | andresbajotierra, rob |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Screenshot showing dots after removing move dialogs |
Description
Dotan Cohen
2009-02-06 18:18:54 UTC
What is the difference between this an bug 182098 ? What do you mean by "remove" ? You can click in the "i" button to hide all the notifications and you can click icon in the title of the operation (ex. "Copying") to toggle it. There is no "remove" action > What is the difference between this and > bug 182098? What do you mean by "remove"? When the dialog is dragged away from the system tray, it seems that it gets placed on the desktop. There it remains, even after the action is complete, until I reboot the computer or unlock the panels and click the X button. > You can click in the "i" button to hide all > the notifications and you can click icon in > the title of the operation (ex. "Copying") to > toggle it. There is no "remove" action By "remove" I mean to close the dialog. There shouldn't have to be a remove action: the dialogs should close themselves just like they do when they are attached to the system tray. (In reply to comment #2) > > What is the difference between this and > > bug 182098? What do you mean by "remove"? > > When the dialog is dragged away from the system tray, it seems that it gets > placed on the desktop. There it remains, even after the action is complete, > until I reboot the computer or unlock the panels and click the X button. > How did you moved the file-operation-dialog from the SystemTray/panel to the desktop if Plasma(panels+desktop) widgets were locked in the first place? > > You can click in the "i" button to hide all > > the notifications and you can click icon in > > the title of the operation (ex. "Copying") to > > toggle it. There is no "remove" action > > By "remove" I mean to close the dialog. There shouldn't have to be a remove > action: the dialogs should close themselves just like they do when they are > attached to the system tray. > You have a point here > How did you moved the file-operation-dialog > from the SystemTray/panel to the desktop if ? Plasma(panels+desktop) widgets were locked > in the first place? It was unlocked when I moved it. Created attachment 31223 [details]
Screenshot showing dots after removing move dialogs
After unlocking the panels and removing the "move" dialogs, black dots remain on the desktop where the move dialogs were. They are marked with arrows in this screenshot, and on one of them you can see it's context menu.
Yes, these are the Extender Container Plasmoids (as the Copy Dialog is a "Extender"), those special plasmoids contain them. However, as the Plasma Widgets are locked, this special plasmoids can't be removed (or be automatically removed) Anyway, I agree that this is not a good behaviour and it needs to be improved. In current trunk detached job progress widgets also destroy themselves when detached. The extender container plasmoid still remains if the widgets are locked though. Really destroying them could cause other widgets to move, depending on the containment, which kind of defeats the purpose of having a locked desktop. That is the same reason why you can't detach extenders while your desktop is locked. I'm open to good suggestions though. Now that bug 182098 has been clarified as a request for having system tray notification items turn into windows, not desktop plasmoids, this bug may be a dupe. However, I am hesitant to close it before seeing the behaviour of the windows. I have this bug marked for triage as soon as I can run Trunk or 4.3, and at that time I will either close the bug or add comments. Thanks. *** This bug has been marked as a duplicate of bug 182098 *** |