On Tue, Aug 25, 2009 at 6:57 PM, Anthony Petrov<[email protected]> wrote: > On 08/25/2009 06:32 PM, Oleg Sukhodolsky wrote: >> >> you will need to specify all possible issues carefully, and, as far as >> I remember, >> writing such specification is a pain. > > ... >> >> you need to specify correct behavior at least for JCK (but I suspect, >> that users would like to have good specification too ;) >> >> Also "more specification" == "harder to use". > > Agreed. OTOH, no or little specification usually results in unsatisfied > over-optimistic expectations. :) > > Regarding technical details, it is obvious that the set of "restricted" > calls depends on the style in question. So we could specify that the > behavior of UTILITY windows is undefined if a developer invokes any > focus-related methods on that window, and then list a few methods of that > kind to give examples (e.g. setWindowFocusableState()). This seems to be > quite enough to make both the JCK and the developers happy. We'll review the > specification proposal on this mailing list in a little while. > > >>>> 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 ;) 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 approach has its own problems. Oleg.
