----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4451/#review6253 -----------------------------------------------------------
thanks for tackling this :) there are other situations where the screen # may already be set - when you import a containment, either by starting a stopped activity or some other way. there are a couple of functions for that in libplasma (Corona iirc -load/importLayout?) that would need patching. you'd also have to apply the same logic to anywhere a *desktop* number could remain set, because PDV has the same problem (turn it on, remove a VD, add a VD, no view). however, I'm thinking that this isn't the best way to solve it - you'd always be looking over your shoulder wondering if you'd missed a way for the screen or desktop # to get set. It might be better to do it the way that (iirc) panel views do it: when desktopcorona checks the screens, it fakes a containmentAdded, and that leads to plasmaapp putting the containment in the view-creation queue. ...or hell, maybe it would make more sense for plasmaapp to just ensure that the views exist as soon as the screen/desktop does, and trust the view and containment to find each other? take a step back and think about what would be most reliable and simple. The codebase for multiscreen/desktop has grown rather organically, and needs a bit of review now :) - Chani On 2010-06-24 01:37:15, Anthony Bryant wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/4451/ > ----------------------------------------------------------- > > (Updated 2010-06-24 01:37:15) > > > Review request for Plasma. > > > Summary > ------- > > This patch fixes a few problems that occur when hotplugging screens: > 1. On startup, existing containments are associated with a screen even if > that screen does not exist. > This causes a bug when a screen is added: since the containment already > thinks it is associated with the new screen, > it doesn't emit screenChanged() with the new screen, and doesn't get a > view created for it. > To fix this, I've made Containment::setScreen() set the new screen to -1 > if it doesn't exist. > 2. When a screen is removed, a containment will remain associated with the > screen that it is on, causing the same bug > as in 1 when the screen is added again. > To fix this, I've made sure a containment's screen is set to -1 when its > view is removed by PlasmaApp. > 3. PlasmaApp tries to connect to a nonexistent signal in Kephal: > screenAdded(int), the real one is screenAdded(Kephal::Screen*) > > I'm not completely sure that this is the best way of fixing these problems, > please correct me if it isn't. > > > Diffs > ----- > > /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.h 1141983 > /trunk/KDE/kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp 1141983 > /trunk/KDE/kdelibs/plasma/containment.cpp 1141983 > > Diff: http://reviewboard.kde.org/r/4451/diff > > > Testing > ------- > > Started plasma with and without an external screen and tried adding and > removing it a few times. > > > Thanks, > > Anthony > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
