4.2 feature targets

[Guillaume Pothier]

2008/10/19 Aaron J. Seigo <aseigo at kde.org>:
> i think there are some places that we use QDesktopWidget there that aren't
> probably strictly necessary ... before we go the kephal-in-kdelibs route (i
> don't think it's really ready for that yet; give it a release or two), i'd
> rather:
>
> a) review where we use QDesktopWidget there
> b) determine if we really need Kephal in those situations (e.g. we're actually
> getting bugs due to its usage there

Ok, here comes the review.
* Containment::setScreen: used to change the geometry of the
containment when the screen is changed. We could avoid that if we say
the views are in charge of resizing the containments.
* ContainmentPrivate::positionToolbox, used to correctly position the
toolbox. It seems that here we could rely on the geometry of the
containment itself, as it is supposed to be the same size as the
screen, and the toolbox is positioned relative to the containment.
* ContainmentPrivate::positionContainment. Used to find the maximum
width/height of all screens. Maybe we could use instead the max
width/height of all containments, for the same reason as above.
* Containment::effectiveScreenPos. There it seems we cannot use the
containment's geometry as we need the actual screen position.
* Containment::destroy. Only the number of screens is used.

* popupPosition in plasma.cpp: Needs the actual screen position

* PopupAppletPrivate::updateDialogPosition. Needs the actual screen position.

That would be all it seems.
So one nice thing is that QDW is never used for receiving signals
(because QDW has this "one train late" problem when it sends signals).
But it seems at least some of the usages of QDW cannot be eliminated.
So if we are going to have a mix of kephal (in plasma) and QDW (in
plasmalibs), there must be a guarantee that kephal and QDW screen ids
are the same. Currently on my system they are, but I don't know if it
is always the case.

Cheers,
g