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

[Anthony Petrov]

Hi Oleg,

On 08/26/2009 06:44 AM, Oleg Sukhodolsky wrote:
>>>>> 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.
>>> 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
>> required).
> 
> 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 [1] 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();

wf.setUndecorated(true);
wf.setModal(true);
wf.setAlwaysOnTop(true);
wf.setUnfocusable(true);

Window w = wf.getInstance();

Wow :)

But... wait a minute, what if one would insert the following call:

wf.setExtendedState(MAXIMIZED_BOTH);

just before calling the getInstance()?

Throwing an exception? Ignoring the option? Is that really easier to 
understand and maintain?

[1] 
http://jroller.com/santhosh/date/20050625#are_you_missing_maximize_button

--
best regards,
Anthony


> approach has its own problems.
> 
> Oleg.