Anthony Petrov wrote:
Hi Mike,
On 08/25/2009 07:58 PM, Mike Swingler wrote:
Java on Mac OS X already implements similar functionality with a Swing
client property "Window.style" -> "small", so we welcome this addition
to the formal Java API specification.
I'm glad to hear that!
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 ..
-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