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.
