Bug 183463 - File operation dialog (moved to Desktop) can't be closed ( or automatically removed ) if widgets are locked
Summary: File operation dialog (moved to Desktop) can't be closed ( or automatically r...
Status: RESOLVED DUPLICATE of bug 182098
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Unspecified
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-06 18:18 UTC by Dotan Cohen
Modified: 2009-08-27 22:17 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot showing dots after removing move dialogs (309.49 KB, image/png)
2009-02-11 14:11 UTC, Dotan Cohen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2009-02-06 18:18:54 UTC
Version:            (using KDE 4.2.0)
Installed from:    Ubuntu Packages

If a copy / move dialog is dragged off the panel and then the panel is locked, the dialog never disappears. The panel must be unlocked to remove the dialog.
Comment 1 Dario Andres 2009-02-06 22:47:01 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
Comment 2 Dotan Cohen 2009-02-07 13:48:12 UTC
> 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.
Comment 3 Dario Andres 2009-02-07 14:14:24 UTC
(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
Comment 4 Dotan Cohen 2009-02-07 21:32:08 UTC
> 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.
Comment 5 Dotan Cohen 2009-02-11 14:11:07 UTC
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.
Comment 6 Dario Andres 2009-02-11 23:28:21 UTC
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.
Comment 7 Rob Scheepmaker 2009-04-30 03:05:27 UTC
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.
Comment 8 Dotan Cohen 2009-04-30 13:08:01 UTC
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.
Comment 9 Dotan Cohen 2009-08-27 22:17:29 UTC

*** This bug has been marked as a duplicate of bug 182098 ***