Even if all we can add (to what is already proposed) is
"whether an icon for a window is displayable in the task bar is
dependent on all of window type, platform, and implementation"
then I think that clearer than the current words which could be
misinterpreted as meaning something like addressing that
if you call hide() then of course it disappears ..

-phil.

On 3/15/17, 10:02 AM, Sergey Bylokhov wrote:
It is not necessary, if the frame has utility type.

So can we say this with that qualification ?

This is also implementation detail, that such windows are not visible in taskbar. This is not specified anywhere and can be changed in the future.

If this is consistent in our current implementation on all platforms then
there is no problem making this part of the spec and changing the spec in
the future if that changes.

It was not implemented on systems other than windows, so if we change the signature we will not be able implement/change this on linux/osx.


We have to say something. I can't agree the current words are enough.

What is wrong in the current wording? If the element is not visible in taskbar we cannot show something on top of it. We never specified when something is visible/non-visible in taskbar. We can update the words, but it will be good to use current methods signatures.


-phil.




- Dialogs are always visible if they have no owner

This is implementation details on windows. I am not sure why it was implemented this way, is it really intended behavior or not.

So we'd have to say its platform and implementation dependent
and add an implNote for audiences other than JCK.

Not sure that we can describe all the cases when it works.

To me the description like «Has no effect if this window is not visible in the task area.» is enough because it also covered the case when the window is invisible.


- All other cases (eg Window) are platform dependent ?
 Or can we say for the latter, other descendants of Window (including
  Window itself) are never visible ?

What about the last point ?

It depends from the implementation.



Reply via email to