Bug 183087 - Locked panels and Internal Extender Container are mutually exclusive
Summary: Locked panels and Internal Extender Container are mutually exclusive
Status: RESOLVED DUPLICATE of bug 182098
Alias: None
Product: plasma4
Classification: Plasma
Component: containment-panel (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-04 00:27 UTC by Stephan Sokolow
Modified: 2009-04-30 02:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Sokolow 2009-02-04 00:27:43 UTC
Version:           unknown (using 4.2.00 (KDE 4.2.0), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.25-gentoo-r7-20080501

Currently I have to choose between having my panels locked (eg. so I can slam my mouse into the top-right corner and have the plasmoid get the click rather than the cashew) and being able to use Internal Extender Container to detach pop-ups.

Could I please have the ability to lock/unlock the panels and the desktop separately so I can do both?
Comment 1 George 2009-02-09 16:59:51 UTC
You mean: "Make possible to detach extender items when widgets are locked" ?
Comment 2 Stephan Sokolow 2009-02-09 19:27:30 UTC
I don't see how that would be possible without changing the nature of extender items. As it is, they produce apparently normal desktop plasmoids and those get locked just like anything else.

However, if you're willing, that would be another nice option. (Being able to lock my permanent desktop widgets but still having the option to detach and move temporary, extender-provided ones)
Comment 3 Rob Scheepmaker 2009-02-12 01:27:02 UTC
Stephan: If you have a suggestion on how this would work... I would be very interested. We could make an exception for the host extender applet so it can get created and show the item. The problem is, that depending on the containment, this action might move other applets (the default desktop moves colliding applets, and in the panel room is created in the layout for this item so existing applets move to the side. I think this inherently violets any lock, because if stuff can get moved around, what function does the lock have at all?

I agree that it would be nice to still be able to interact with extender while having a locked desktop, but I don't see an nice way in which that could be achieved.
Comment 4 Stephan Sokolow 2009-02-12 02:21:02 UTC
I'll need at least a day or two to think on that for the best solution, but the first thing that comes to mind as a temporary fix is to keep the collision avoidance, but move the extender (the lock-exempt widget) while keeping the locked widget stationary.
Comment 5 Stephan Sokolow 2009-02-12 03:39:26 UTC
Another idea I had which I thought I'd just throw out for brainstorming potential proper solutions. (I haven't really thought this through. I just thought it might get you thinking)

Given how extenders are usually generated from things which are always on top when visible and not detached, what about something like this:

1. Torn-off things default to being always-on-top and, because they behave more like windows than plasmoids, can overlap desktop stuff and ignore plasmoid locking.

2. Add a pushpin toggle on the frames which, when active, makes them behave as regular plasmoids, complete with locking, collision prevention, and "always beneath". (In the event that clicking it causes a plasmoid collision, seniority wins as in my original suggestion)
Comment 6 Stephan Sokolow 2009-02-13 09:28:38 UTC
I'll have to get back to you later on any better ideas. My productivity is going down the tubes and I need to eliminate as many distractions as possible.
Comment 7 Rob Scheepmaker 2009-04-30 02:52:37 UTC

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