GSoC Idea: better multi-head support

Aaron J. Seigo aseigo at kde.org
Sun Mar 23 18:48:54 CET 2008


On Sunday 23 March 2008, Aike J Sommer wrote:
> > well, of course we don't create views for screens that don't exist. the
> > view should be created on demand when the screen comes into being. the
> > containment may pre-exist that, of course.
>
> Where should the View be created? I could look into whats going on there...

in workspace/plasma/plasma/rootwidget.cpp in screenOwnerChanged or in 
workspace/plasma/plasma/plasmaapp.cpp in createView. 

the RootWidget method is called with Corona::screenOwnerChanged is emitted, 
which happens when the screen of a containment changes. that's not happening 
here, because the containment already exists an is associated with that 
screen.

the PlasmaApp method is called with Corona::containmentAdded is emitted, which 
isn't happening here because the containment already exists.

so there is no View created listening to the one signal that matters here: 
geometryChanged.

what would probably be best is if Containment::screenChanged was called when a 
physical screen actually appears, even if the containment already exists for 
it. that problably needs to happen in Corona::screenResized(). what probably 
needs to happen is to keep track of the last value of 
QApplication::desktop()->numScreens() in Corona::screenResized(int) and if 
that number changes then emit some screenAdded signals or some such.

Corona also needs to have all it's QApplication::desktop() using code wrapped 
so it can be turned off for apps like Amarok that don't care. either that or 
it should be removed and a subclass of Corona be put into plasma itself that 
does that... 

*thinks* the latter is probably the best, design wise?

ok, so i just committed the above to svn. the desktop related stuff is now 
separated out into workspace/plasma/plasma/desktopcontainment.*. you should 
be able to concentrate your efforts on those two files now. =)

maybe you could svn up and test again to see if anything changes for you..

> > so Applet::setGeometry should be getting called.
>
> Well... But its called with the previous position, so it will not see any
> change if the size did not change... Or am i missing something here?

ah, neither position or size is changing? then yes, nothing will be emitted. 
nore should it, really.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080323/b2ef4ed3/attachment.pgp 


More information about the Panel-devel mailing list