On Monday, March 3, 2014 10:34:40 Martin Gräßlin wrote: > 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).
that would be another way to do it in this case, yes. not as efficient, however, particularly as the terms being matched against are entirely unlikely to change during query. > > 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. that can not be hard to fix, though? a quick glance at kwindowinfo_x11.cpp suggests that having an invalid WId and short-circuting the constructor in that case would resolve that. > 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. this is true even with the usage you see as being proper. in the time it takes to get the window info and then do whatever processing is relevant, the window information may also have changed. that’s just the nature of such async data. it also means that, e.g., sorting a list of window information would now mean: * create a collection mapping the window ID to the property to sort on (e.g. name) * iterate over all windows, fetching window IDs, populating the collection * sort * iterate the collection in order fetching the window info again * use previously, the way to do this would be: * create a collection of KWindowInfo objects * sort * use given the “it crashes” fix should be trivial, why should the above be disallowed? API should not try and force developers to do the “right” thing, as that implies we know what that is in all cases. > > 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. crashes should be easily resolved; we disagree on the definition of ‘proper usage’ in this case. -- Aaron J. Seigo
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