Review Request 121459: Fixed data type for _KDE_NET_WM_BLUR_BEHIND_REGION

[Thomas Lübking]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121459/#review71877
-----------------------------------------------------------

Ship it!


using long should have been wrong itfp, since it's only 32bit on i32 and LLP64 (<- what MS calls an OS ;-), but not on ILP64 or LP64 (<- typical unixoid), ie. the length of "long" may easily vary between client and server (or two clients)

See http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

- Thomas Lübking


On Dez. 12, 2014, 10:22 vorm., Hugo Pereira Da Costa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121459/
> -----------------------------------------------------------
> 
> (Updated Dez. 12, 2014, 10:22 vorm.)
> 
> 
> Review request for KDE Frameworks and kwin.
> 
> 
> Repository: kwin
> 
> 
> Description
> -------
> 
> Somehow (although I do not know the details), the change from X calls to xcb (or similarily XA_CARDINAL to XCB_ATOM_CARDINAL) involves a conversion from unsigned int to uint32_t.
> As a consequence one must change the data type and cast accordingly, so that 'valid' blur regions passed from Qt4/KDE4 applications and that where properly honored by kwin at kde4 are still working for kwin at kf5
> 
> thanks
> 
> 
> Diffs
> -----
> 
>   effects/blur/blur.cpp 29852de 
> 
> Diff: https://git.reviewboard.kde.org/r/121459/diff/
> 
> 
> Testing
> -------
> 
> yes
> 
> BLUR_BEHIND_REGIONS that were honored with kde4 and not any more with kf5, are again ...
> 
> I have no clue whether this impacts plasma at kf5
> (it could well be that there the property was fixed 'the other way around', by casting from unsigned long to uint_32 when setting the property, via XCB. This however would break when running against kwin at kde4)
> 
> 
> Thanks,
> 
> Hugo Pereira Da Costa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20141212/911d0e6c/attachment.html>