<AWT Dev> [8] Review request for 7078460: JDialog is shown as separate icon on the taskbar

Denis S. Fokin denis.fokin at oracle.com
Mon Jan 23 08:16:23 PST 2012


Anthony, Artem,

please look at this iteration

http://cr.openjdk.java.net/~denis/7117011/webrev.02

Thank you,
    Denis.

On 1/23/2012 6:34 PM, Denis S. Fokin wrote:
> Anthony, Artem, thank you for your input.
>
> Could you take another look at the fix.
>
> http://cr.openjdk.java.net/~denis/7078460/webrev.01/
>
> I have run Window, Dialog, Frame JTreg tests. I have not found any new
> failures.
>
> Thank you,
> Denis.
>
> On 1/20/2012 6:57 PM, Anthony Petrov wrote:
>> +1 as long as the fix doesn't cause any regressions. The simple window
>> case needs to be fixed, obviously.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 1/20/2012 6:54 PM, Artem Ananiev wrote:
>>> Hi, Anthony,
>>>
>>> I personally find the current code quite complicated because of:
>>>
>>> 1. SKIP_TASKBAR should only be set (or not set) once, because it
>>> depends on the window's owner, that cannot be changed on the fly.
>>> Having SKIP_TASKBAR code in setBounds() doesn't make any sense to me.
>>>
>>> 2. XDecoratedPeer.setBounds() not calling super.setBounds() is not a
>>> typical pattern, so it's not trivial to understand that SKIP_TASKBAR
>>> is not really set for dialogs. This is yet another reason to move this
>>> code to postInit().
>>>
>>> So I like the proposed change. The only missed part is that we should
>>> set SKIP_TASKBAR on simple windows (not frames/dialogs) regardless of
>>> their owner.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 1/20/2012 4:03 PM, Anthony Petrov wrote:
>>>> Hi Denis,
>>>>
>>>> The bug you're fixing is about a JDialog which is a Dialog descendant,
>>>> and as such uses the XDecoratedPeer. Therefore, the
>>>> XWindowPeer.setBounds() is never really invoked for JDialogs.
>>>>
>>>> Also, the lines 482-489 which you're removing from this method come
>>>> from
>>>> JDK6. This piece of code resets the SKIP_TASKBAR state on every
>>>> setBounds() call, and please note that it's unconditional (i.e. there's
>>>> no if (owner!=null) check).
>>>>
>>>> I'd suggest to not remove the lines 482-489 unless this is strictly
>>>> necessary and doesn't introduce any regressions.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 1/19/2012 7:57 PM, Denis S. Fokin wrote:
>>>>> Hi AWT team,
>>>>>
>>>>> Please review a fix for the CR 7078460 at
>>>>>
>>>>> http://cr.openjdk.java.net/~denis/7078460/webrev/
>>>>>
>>>>> CR URL:
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078460
>>>>>
>>>>> Thank you,
>>>>> Denis.
>




More information about the awt-dev mailing list