(original) (raw)

Hello, Vladimir.
Testcase will be welcome, since the issue was not found by our regression tests.

On 23.04.2013 12:50, Anthony Petrov wrote:

Thanks Vladimir. The fix looks fine to me. We need to get at least one more review, after which I'll be able to push it to the repository. Could anyone review this please? Here's a link to the webrev:

http://vkravets.github.io/awt-fixes/8012586/webrev.00/index.html

Regarding other WMs and the DIALOG type - yes, I agree with you. I don't known of any WMs that would do something strange for DIALOG windows, so as I said this is just a theoretical concern. The fix should work fine now for most WMs. If we encounter a problem with a particular WM in the future, we'll see how to deal with it.

\--
best regards,
Anthony

On 04/22/2013 06:33 PM, Vladimir Kravets wrote:

Done. You can look at the same link. BTW the full listing webrev
directory you can find on the
https://github.com/vkravets/awt-fixes/tree/master/8012586 link.

> I assume you have tested this fix and it works as expected for your
use cases?
Of course =)

>Although I'm a little concerned about other window managers that may
present DIALOG windows somehow completely differently (as some Mac-style
sheets for example). In this case the fix may fail since it marks
regular owned windows as DIALOGs, too. This is purely a theoretical
concern, but still something to think about. Shouldn't we check the
window type instead of just checking whether the window has an owner or not?

Since this is is not ICCCM-compliant atom, thus I guess that all another
WM's should compliant by this spec from freedesktop.
http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#idp1333344

In this section very clearly specified how should react WM's on
different wndow type. BTW before fix AWT was not fully compliant with
this spec =(

Best Regards,
Vladimir

\--
Best regards, Sergey.