KWindowSystem

[Martin Gräßlin]

On Monday 03 March 2014 09:56:11 Aaron J. Seigo wrote:
> On Monday, March 3, 2014 08:35:16 you wrote:
> > The reason to remove the default ctor was that if one used it, KWindowInfo
> > would crash on first usage as it was completely broken. It was documented
> > to be there for usages in container classes but lxr doesn't show any
> > usage and
> kde-workspace/plasma/generic/runners/windows/windowsrunner.h:68
> 
> 	QHash<WId, KWindowInfo> m_windows;
> 
> the copyright on the file is yours, actually :)

It's an incorrect usage caused by XLib not being thread safe. We just couldn't 
use KWindowInfo in the runner thread. With the switch to xcb that's no longer 
the case and it would be better to have just a QList<WId> and fetch the data 
in the thread when it's needed (and have it up to date).

> 
> > IMHO there cannot be a useful usage of KWindowInfo in container classes as
> > KWindowInfo doesn't update the information.
> 
> use of containers is not always about long-term storage. they can be used to
> conveniently sort sets of objects, to populate a set of objects in one part
> of the code and then process them in another, etc.

Right, but I think that use case just doesn't apply to KWindowInfo given that 
it doesn't reflect the current state.

> 
> it is fine to put in the apidox that a default-constructed KWindowInfo
> object is invalid and will not provide useful information.

It's wasn't just invalid, it was crashing.

> > If you have a valid use cases for container classes please bring it to
> > frameworks mailing list for discussion whether we should restore SC.
> 
> done :)

Thanks, but as said I don't think that this is a valid use-case for 
KWindowInfo due to the nature of this class. Putting it into container classes 
means that we encourage incorrect usage as KWindowInfo is only a snapshot of 
the current state and doesn't update. So any usage in containers means the 
information is already potentially outdated.
> 
> and yes, the preservation of source compatibility is important, especially
> as there is no compelling reason to break it in this case. see:

Yes it's an important case, but it's still better to break SC than have code 
which just crashes or encourages incorrect usage of the API.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140303/61d3e920/attachment.sig>