<AWT Dev> Thoughts about 6402325 (Swing toolbars vs native toolbars on Windows)
Anthony.Petrov at Sun.COM
Wed Aug 26 03:54:07 PDT 2009
On 08/26/2009 06:44 AM, Oleg Sukhodolsky wrote:
>>>>> As possible resolution for the first issue we could use some factory
>>>> 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
>>> It is really abstract question, but factory class is supposed to
>>> minimize number of factory methods and ctors ;)
>> This is no different than specifying that a method may only be invoked when
>> the window is hidden (setUndecorated() comes to mind), or has not yet been
>> shown - like the pack() that is only meaningful before first showing, etc.
>> But adding simple methods creates less syntactic garbage at least, and also
>> enables to change some properties on the fly (even if hiding the window is
> From the other hand adding one more property to Window creates a lot
> of possible combinations
> you need to consider (e.g. how
> always-on-top+unfocusable+undecorated+modal dialog will behave,
> and do you really wants to allow such monster to exist ;)
Speaking philosophically, I can imagine one would want to create such a
window. It seems that giving as many options as possible is a good
choice. And we've almost never specified the behavior of all
combinations of different options, just because it's practically impossible.
Let me give you an example. People want to have modal dialogs with the
Maximize button in the title bar, but they can't because Java dialogs do
not display the button. Could you imagine with what they end up? Take a
look at  and be surprised. This is weird, this is 'wrong', this is
going to be broken once we change our internals... But it does work now,
and people are happy with that.
If I could, I would only leave the Window class in Java AWT. That class
would be able to enable/disable decorations, to show modally or
non-modally, etc. In other words, I really don't see any strong
difference between the Window, Frame, and Dialog. But unfortunately
that's just a dream, an unimplementable dream.
So my point is: we should not enforce artificial constraints on our
APIs. To me, creating an always-on-top+unfocusable+undecorated+modal
dialog might look insane, but still needed in some awkward rare cases.
And forcing people to access private class members via reflection to get
this done seems to bring more pain, than allowing to do this via public
APIs from the start.
Later we can encounter a problem with some combination. Then we'll fix
the bug, or document the misbehavior, or simply restrict such usage. But
doing so preliminarily looks sort of wrong to me.
> I'm just trying to say that, perhaps, adding new class/interface for
> specific toplevel would be
> easier to understand (and maintain). Though I agree that such
I've just imagined a WindowFactory class that would be like:
WindowFactory wf = WF.getInstance();
Window w = wf.getInstance();
But... wait a minute, what if one would insert the following call:
just before calling the getInstance()?
Throwing an exception? Ignoring the option? Is that really easier to
understand and maintain?
> approach has its own problems.
More information about the awt-dev