On 8/25/2009 8:50 PM Phil Race wrote:
To on Mac OS X, the underlying AppKit framework does not support
changing the NSWindow style mask on the fly. Could the specification
be written to require the type to be set prior to the native peer
becoming realized?
Since some platforms may allow changing the property on the fly,
others may require hiding and subsequent showing the window w/o
recreating the peer, and third require recreating the peer, it would
be great to provide the highest level of support to Java applications
when running on a given platform.
What about
Throwing an exception in case the Java implementation is unable to
change the style when the peer is realized?
Without telling you what to do, here are some things to consider :
* Exceptions are for exceptional conditions. Not something that's normal
and expected on a configuration.
* It is best to recognise platform behaviours early on and think about
how to handle it from the beginning. I recall that it was a bit of
a nightmare with Desktop.isTraySupported not distinguishing between that
not being supported at all by the platform/WM vs not being visible at the
moment the Java API was first called. The hard part was retrofitting
recognising this behaviour without breaking apps.
See http://bugs.sun.com/view_bug.do?bug_id=6438179
* Baking in to the spec allowing platform specific behaviours are
annoying in that it forces (good) developers to find platforms
with each of the possible behaviours and test under those conditions.
As I said, these are thing to consider, not recommendations.
For example it might be best to use an Exception even at the cost of
making it less simple to use for developers if otherwise lazy developers
would find it easy to write code that could ignore the condition they
never saw except on Windows ..
Yes, all these are excellent points. Thanks, Phil.
I've also been thinking over, and just realized that apparently the
'type' is quite a fundamental property of a window. Keeping in mind that
the easier the API - the better, I now tend to agree with Mike. The call
(if any) should occur before realizing the peer (just like the spec for
the setUndecorated() states, for example). Otherwise the
IllegalComponentStateException must be thrown.
The only kind of applications that would want to change the type
dynamically might be some IDEs with GUI designers, but I doubt whether
they would suffer much from the necessity to recreate the peer. At
least, we'll be able to improve the API in the future by removing the
restriction (if we get some good justification for that, and, of course,
proper level of support from native systems.)
--
best regards,
Anthony
-phil.
-OR-
Providing a sort of getWindowTypeChangeSupportLevel() method, and
having the setType() method to silently store the passed argument for
future needs?
Although both options are not as nice as we would want. Perhaps you
could suggest something else?
--
best regards,
Anthony
