<AWT Dev> Thoughts about 6402325 (Swing toolbars vs native toolbars on Windows)

[Anthony Petrov]

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