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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
