KWindowSystem

[Aaron J. Seigo]

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
-------------- 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/8a5c0df6/attachment.sig>