<AWT Dev> Thoughts about 6402325 (Swing toolbars vs native toolbars on Windows)
Anthony Petrov
Anthony.Petrov at Sun.COM
Tue Aug 25 07:08:47 PDT 2009
Hi Oleg,
Thank you for the comments.
On 08/25/2009 05:47 PM, Oleg Sukhodolsky wrote:
>> public void java.awt.Window.setType(Type type);
>> public Type java.awt.Window.getType();
>>
>> **************************************************
>
> - providing a setter for this property you open door for number of
> questions such as "when this methods can be called" or "when user will
> see result of the call"
The EWMH specification states that the hint should be set prior to
mapping the window. I haven't tested it yet, but I guess MS Windows is
able to apply the style on the fly,
In both cases we can say that the effect is guaranteed to be applied
upon subsequent showing the window, or we may even enforce it applying
the style ONLY upon showing - but I don't think we should. So it doesn't
seem to be a serious problem.
> - adding this property to Windows you create situation when some
> methods of Window will not work (should not be called) in certain
> situations, e.g.
> setUndecorated(), setWindowFocusableState() etc.
I don't actually see why the methods (or some other) should be
prohibited. For instance, a toolbar may not have a system title bar but
still set the needed style in order to employ the toolbar-style focus
behavior, etc. Of course, we need to pay attention to correctly document
that certain calls can change the default behavior enforced by a
particular style. After all, it's going to be user's responsibility, but
at least, AFAIK, it's not prohibited by the native system.
> As possible resolution for the first issue we could use some factory
> methods/classes.
That looks like a really bad idea to me. Just recall the number of
constructors the JDialog currently has... So I would like to avoid both
adding new parameters to constructors, and creating any factory
methods/classes.
--
best regards,
Anthony
More information about the awt-dev
mailing list