Version: unspecified (using Devel) OS: Linux When you open up the new activity manager and clone an activity, on the new activity all plasmoids are piled on top of each other instead of in the same place they are on the base activity. Reproducible: Always Steps to Reproduce: Click on cashew -> activity, clone an activity. Actual Results: Plasmoids are piled on top of each other. Expected Results: Plasmoids should be exactly in the same space they are on the activity that was cloned.
weird, I never had such problems. what version are you using? (beta1, beta2 or revision #)
(In reply to comment #1) > weird, I never had such problems. > what version are you using? (beta1, beta2 or revision #) I use beta 2.
And for some reason it works now, but earlier today I experienced this problem and a few days ago too, maybe it depends on the position of plasmoids?
*shrug* if you find a reliable way to reproduce it, tell us. maybe test whether it has anything to do with how much time elapses between moving widgets and cloning the activity?
(In reply to comment #4) > *shrug* > if you find a reliable way to reproduce it, tell us. > maybe test whether it has anything to do with how much time elapses between > moving widgets and cloning the activity? Well it is not about moving widgets, I didnt change them. I just thought it might be related to the picture frame plasmoid, it is in the lower right corner of my desktop and it resizes depending of the picture size.
can't reproduce here as well. it sounds like the new created desktop has a very small size for a moment, the layout of the desktop messes up everything, then is enlarged at the size of the screen, but with the layout ruined
i'm closing this. nobody can reproduce it and there is no way to reproduce.. please reopen if you find a way!
(In reply to comment #7) > i'm closing this. nobody can reproduce it and there is no way to reproduce.. > please reopen if you find a way! I believe I am closer to reproducing now, it doesnt occur to me when the widgets are unlocked, if locked, I get a pile.
hey, I wonder if this could be a dup of bug 241341? jakob: are you able to try out trunk, see if it's fixed there?
(In reply to comment #9) > hey, I wonder if this could be a dup of bug 241341? > jakob: are you able to try out trunk, see if it's fixed there? From the description it does not look like a duplicate. Sorry, I wont try trunk, rc1 is only 11 days to go.
1) i think really shouldn't be possible to clone an activity with desktop locked, since the locking is at corona level 2) of course it happens, locked applets completely refuse any movement (as it should happen btw) so i think the add activity button (or even the whole activity manager) should be hidden when widgets are locked
oh dear, it doesn't hide itself when locked. I thought it did. the Correct behaviour would be to just disable all functions except switching between running activities. making it hide the whole thing is a shortcut, one I'd *prefer* to avoid, but we may not have that luxury atm. erg.. and I just realised there's another problem: anything that switches activities may switch to a closed activity, which would open it, which would break when locked. crrrap. the activity-bar plasmoid, the mouse action, *and* the keyboard shortcut are all affected by that. .. the cleanest way to solve that would be for the Activity API to offer a list of only the open ones... but someone'd have to make it understand those concepts... erg... :/
actually, after some thought, I realised that loading a containment while locked needs to work. the most compelling use case: you plug in a new screen while plasma is locked. there's no question that that screen *needs* a containment. in fact, it should have the containment that belongs to it for the current activity. right now, if that containment exists it'll have been running already, but at some point I'm going to have those saved out when the screen is detached (it's silly to have them running all the time). so, when the screen is plugged back in its containment needs to be loaded again - *even if the desktop is locked*.
Chani: yeah, you're right for the multiscreen case. so, this should work ( maaybe i have an idea how to make it work) then, it should still be impossible to do this from the user, in a not automatic way. so the add button should be hidden from the activity manager... about starting/stopping activities.. it could make sense to have it permitted in a locked desktop, even if i would be more confortable having it forbidden again -for the user- to do it... another thing that should be forbidden i think, is to change the activity type
SVN commit 1139463 by mart: permit moving plasmoids before startupcompletedcontraint arrives so doesn't interfere with restoring and activity cloning BUG:241496 M +1 -1 applet.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1139463
now the plasmoids are no more stacked. however i would still hide the new activity button :)
thanks for fixing that :) adding activities should be disabled, yes... opening activities would just be too much of a pain to try and restrict, and switching should certainly be allowed. people usually lock their desktop just to avoid messing up their widgets, that's all. :)