Community
Participate
Working Groups
There are several places in the GUI where user create a "info pop-up" dialog. Unfortunately, as it is now, these dialogs are written from scratch and share little common code. A utility class for creating such dialogs would reduce code, and help to ensure a common look & feel. These are the characteristics I see as being common to these dialogs: + Background colour + Always on top + Does not appear in the window list + Deactivating the shell closes it + Resizable; remembers size There might be others as well.
There might also some default options for sizing and positioning. For example, it could "position at cursor" or "position on right-bottom edge of window".
+ can disable to remember resize + can be moved and the new position is remembered (if chosen to be) + lightweight look and feel + knows the command that triggered it The Text component has several kinds of info-popups: - hovers - content assist popup (list) - quick views (Outline, Hierarchy) These behave differently regarding focus and deactivation behavior.
Could you describe the ways in which they are different?
Sorry for taking so long. It somehow got lost in my bug pile. Hovers - do not get focus and cannot get it - cannot be resized - are only active/visible while mouse cursor is over help requesting/hot area (e.g. a type name). They go away if the mouse cursor leaves that area - look even more light-weight than quick views (thinner border) Content assist popup (list) - initial focus remains on text widget i.e. user can type to narrow down the proposed items. User can transfer focus to it (e.g. via mouse) - can be resized (and remember its size) - stays active no matter where the mouse cursor moves but goes away if mouse button pressed outside of content assist popup Quick views (Outline, Hierarchy) - gets focus when opened - can be resized (and remember its size and location if user desires so) - stays active no matter where the mouse cursor moves but goes away if mouse button pressed outside of quick view
I apologize, but my work on the RAD performance team is continuing longer than expected. This will have to wait until M4.
I have a question for you guys: how do you decide what size to make the text in the bottom right of the dialog?
Do you mean the field size or the font?. The font is hand-made: Font font= statusField.getFont(); FontData[] fontDatas= font.getFontData(); for (int i= 0; i < fontDatas.length; i++) fontDatas[i].setHeight(fontDatas[i].getHeight() * 9 / 10); fStatusTextFont= new Font(statusField.getDisplay(), fontDatas); statusField.setFont(fStatusTextFont);
Note: all dialogs that remember their previous size and position should do so with coordinates relative to their parent window. Dialogs that remember their size in display coordinates are currently causing mischief with multimonitor support. Dialogs are opening up on a different monitor from the rest of Eclipse because that is the monitor that Eclipse was on the last time it opened.
Bumped off my schedule for contributions work.
Is the Target Milestone for this supposed to be 3.1 M4?
Yes, this on my list of things to do for 3.1M4. Doug, could you update the Target Milestone to 3.1M4? It is not letting me update it. Thanks.
By looking primarily at the PopupInformationControl and KeyAssistDialog classes, here is a proposed draft for a generic PopupDialog implementation. I started writing a basic "PopupInformationDialog" in "org.eclipse.jface" that extends Dialog. Provides basic functionalities, such as: Public: - setParentShell(Shell parentShell) - setBlockOnOpen(boolean value) - setShellStyle(int shellStyle): Specify shell styles: SWT.NO_TRIM, SWT.RESIZE... - setSize(size); Specify the size of the shell - setLocation(location): Specify the location of the shell. The location will be converted to coordinates relative to the parent shell, or to the display if no parent is set. - setHasBottomComponent(Boolean value): If the value is set to true, it would create a dialog with top and bottom controls, separated by a separator. I noticed that a lot of the pop up dialogs have this top and bottom control pattern. It could be useful to be able to specify that behavior. - setCloseCondition(closeType): closeOnDeactivate: Will close the dialog when the shell becomes de-activated mouseExitParent: Will close the dialog when the mouse exits the parent shell - open(): Creates and opens the dialog. - close() and close(bool rememberState): On close, you can specify if you wish to remember the current colors, location, size and other properties of the dialog. - setBackGroundColor(int color) and setBorderColor(int color) - rememberDialogSettings(boolean value): Set whether the dialog should remember its properties on close. - clearDialogSettings(): Would provide a way to reset all the dialog properties to default values (background and border colors, size, location...) - createContents(Composite parent): Creates a simple dialog window, with a border around the shell if a border color has been specified. The dialog is comprised of a dialog area (top component) as well as button bar (bottom component if specified) controls. It also sets the background colors and layouts. - createTopControl(Composite parent): Fill in the top component of the dialog ("dialog area"). Current default implementation is blank. This method would be called from the "createContents" and would fill the top part of the dialog. - createBottomControl(Composite parent): Fill in the bottom component of the dialog ("button bar"), if the "has bottom flag" has been set to true. This method would be called from the "createContents" and would fill the bottom part of the dialog. - getInitialSize(): Overwrites the Window's "getInitialSize". This method is called in Window from the "createContent()" method, when the dialog is created on opened. Current implementation uses the Window's default implementation for computing the size. - "getInitialLocation()": Overwrites the Window's "getInitialLocation()". This method is called in Window from the "createContent()", when the dialog is created on opened. Current implementation uses the Window's default implementation for computing location. Notes: - The "getInitialSize()" and "getInitialLocation()" should be overwritten to provide specific location and size calculations. However, I am thinking of common "size" and "location" computations that could be set for this dialog. Any ideas? As Stefan pointed, the position should be set relative to the parent (as Doug mentioned, maybe provide settings such as "top right corner", "bottom left corner", "relative to mouse"...) - I currently have 2 closing scenarios for the dialog: on mouse exit (exit the parent) and on shell de-activate. Any other common ones that could be added to the generic pop up implementation? Maybe something based on a timer? Close after x milliseconds. - It would be nice to be able to say in the constructor "new PopupDialog(PopupDialog.Hover)" and have the dialog set all the required properties: along the lines of black border, info background color background, no trim, block on open(false), closes on de-activate… Hover would be one type of dialog. Maybe List could be another. - The current implementation provides no default implementation for the top and bottom (if specified) controls. It would be nice to be able to say myDialog.setTopContent(control) and myDialog.setBottomContent(control). That would make the "PopupInformationDialog" complete enough to not force the user to have to subclass to create a simple pop up dialog. I am not sure how feasible the latter solution is, as what I have mostly seen in other dialogs is the idea of "createContent" methods that need to be overwritten to provide specific contents. - The information that needs to be saved to remember the command that triggered the dialog. Since the dialog would be in jface, maybe a string representation of that command. Thanks for the feedback.
Re: closing the popups: * The debug popups perform an action and close in response to a command/key- binding. For example, the "display" popup is opened by invoking the "Display" command (Ctrl-Shift-D), and then we use the same command to close the dialog and persist the result into the Display view. Similarly, the "inspect" dialog (Ctrl-Shift-I) can be closed via the same key-binding, which moves the result from the pop-up to the expressions view for furture reference. Would it be possible to generalize this - i.e. add a "close" command. See org.eclipse.debug.internal.ui.views.expression.PopupInformationControl for implementation details.
I had noticed the "close" command support in PopupInformationControl. However, since this dialog will be in JFace, the most I can do with keys is string representations. The "close on de-activate" and "close on mouse exit" are choices of closing types you can set. If they do not fit your needs, you will be able to just call the dialog's "close" method as you deem appropriate.
>By looking primarily at the PopupInformationControl and KeyAssistDialog classes, >here is a proposed draft for a generic PopupDialog implementation. What (or who ;-) made you restrict to those, especially why were the quick views (Ctrl+O, Ctrl+T) left out? They provide additional interesting features like single-click navigation, resize, move and a view menu.
My fault, I found hover, content assist and key dialog implementations, but I omitted quick views :) Any particular class I should look at? Thanks for pointing that out!
I have added quick views (AbstractInformationControl) to my list of available implementations.
Created attachment 16180 [details] Initial support for the pop up dialog Initial support for the pop up dialog, inspired from: - AbstractInformationControl (org.eclipse.jdt.ui) - PopupInformationControl (org.eclipse.debug.ui) - KeyAssistDialog (org.eclipse.ui.workbench) The attached implementation is a pop up dialog that allows properties to be set. Here is a summary of some of the components: - Header and footer components - Override "createDialogContent(Composite)" to fill in the dialog's content - Override "createFooterContent(Composite)" and/or "createHeaderContent(Composite)" to fill in a header and/or footer components if they have been specified - Move and resize capabilities (through the pull down menu, as in the quick view dialogs) - Move and resize capabilities can also be set using the standard (setShellStyle(style)) if you do not want to use the pull down menu - Background and border color - Shell style - Size and location for the dialog (the location is internally stored relative to the parent widget if it's defined, or to the display if the parent is null). Default location and size computations are in place, as well as other location computations - Remember the bounds (size and location) - Remember the dialog properties - Set closing type (currently, only close on de-activate can be chosen as a type, or none) - Open and close methods Things to discuss/resolve: - Key bindings -> key binding support is in the workbench, which means that the PopupDialog should be appropriately sub classed (outside of JFace) to add the key component to it. - The dialog's properties can be remembered. Should they be remembered across sessions? If so, the PopupDialog should allow support for setting DialogSettings, or access to a PreferenceStore. Or maybe that part is too specific and should be left to the class that extends the dialog. - Is the PopupDialog too customizable? Some features could be removed to make it a more solid generic base and other features can be added if seen fit.
Created attachment 16181 [details] Sample main program that uses the pop up dialog SWT stand alone snippet that uses the pop up dialog. Primarily to demonstrate the different look and feels that can be achieved.
Reassigning to UI.
I'll try to provide feedback by the end of the week.
I first started to play with the dialog by using the provided Main.java: - I added myDialog.setCloseCondition(PopupDialog.closeDialogOnDeactivate); ==> results in NPE when moving the dialog via view menu. this is one of the problems we faced as well: the tracker gets started and this causes the dialog to be disposed and later the tracker to fail - it seems that it's not possible to create a simple hover i.e. a popup that doesn't take focus (SWT.NO_FOCUS). I guess this is because you use open() instead of setVisible(true). I then tried to use the dialog in DefaultInformationControl. Besides the above problem that the hover immediately takes focus I see the following items: - our programming model assumes control that we can access e.g. the shell and its children before it is visible (opened). This is needed e.g. to add listeners which can be added via public API of DefaultInformationControl. If we loose this functionality we have to add listener management to our DefaultInformationControl - we need API to show the view menu (show method is currently private). This is needed in order to open the view menu via keyboard - there seems to be some space between the top and the first widget (in our case the StyledText: the text doesn't show up directly at the top. I suggest you adapt the current DefaultInformationControl to use the PopupDialog instead of a custom shell and then adapt the PopupDialog to get the same result as with the current DefaultInformationControl. Once this is working the next challenge is to replace the custom shell in the AbstractInformationControl which introduces the following interesting wattles: - uses the resizing and position restoring - use key board to trigger actions like opening the view menu - opens a dialog out of the view menu (filter dialog) which was hard to achieve in the current implementation due to closeDialogOnDeactivate. I'd assume that the PopupDialog would also be closed as soon as the filter dialog comes up Attached find a patch for DefaultInformationControl.java which uses the PopupDialog (showing status line not yet implemented). To make this work I had to add a public create() method to PopupDialog: public void create() { createShell(); createContents(); initializeBounds(); } and control the visibility via its shell: open() and close() are not used at all.
Created attachment 16378 [details] Hacked DefaultInformationControl
Some additional comment: I don't like the smartness in open() i.e. close if dialog is already open and then reopening again.
The popup should also support more close conditions (currently just one specified through int constant) which can be combined. A simple constant as it is now won't be enough. Things which come to mind are: - cursor left area / Rectangle (an area is provided by the client) this is e.g. used for hovers: when the mouse leaves the word area it needs to close - parent deactivated for cases where the dialog has the SWT.ON_TOP - custom closer client plugs in a closer which handles the closing of the popup. This should also be combinable with the on of the other strategies - cursor left shape / Region (same as above but with a shape instead of a rectangle)
I did not get to this for M4.
Removing the milestone marking as Billy is now working on SWT. Billy if you get to this please feel free to take it.
Does this mean that this is no longer planned for 3.1?
It means we can't commit to it as the person working on it has left the team. If we can get time in the schedule we will try.
Tod, any change that something is happening here for M6 ? I would like to make use of a info pop up as well.
I think we will need to get someone assigned to this - let me negotiate some time with MVM.
Yes, I still have a few bugs about the consistency of the look&feel of the key assist dialog with other info pop-ups. I'd rather just use a generic info pop-up, rather than trying to fix these bugs independently.
*** Bug 27821 has been marked as a duplicate of this bug. ***
Adding myself and Shujie as we are looking into this issue currently as well. Darin and Dani can you please tell us where you have written any floating shells yourself - we want to be sure we have your features convered.
Comment 2 summarizes our needs quite well and the comments I provided about the prototype should clarify our needs. Do you plan to restart from scratch on this one?
We are going to start with what Ines did and have a look from there.
Debug's popup dialog is implemented in PopupInformationControl (org.eclipse.debug.internal.ui.views.expression) and its subclasses.
Some additional info: resizing is currently a problem i.e. does not work on all Platforms, see bug 12238 and its blocking bug 23980 for details.
Tod - how far did you and Shujie get on this one?
Shujie didn't manage to get anything done on this before she left.
I am looking at this one for 3.2 M3. Will start by reviewing what Ines did, taking into account Dani's review and the other examples mentioned by Dani and Darin. If anyone else has requirements, samples, or related bugs to add that aren't already covered here, please speak up. Remembering size and location will be done in a way that satisfies bug #33550 (generic size/location remembering for all dialogs with multi monitor support). If subclasses of the popup provide settings/section names for this, then the size and location will be remembered and used later.
>Remembering size and location will be done in a way that satisfies bug #33550 Just a reminder that most of our info popup dilags are not related to the Dialog class since they are not modal. Does above comment indicate that this PR will introduce a connection to the Dialog class?
I was working on a dialog extension (with no blocking) when I made that comment. However I've since refactored it to Window and am still deciding whether it belongs in there at all (based on problems you originally observed - initial focus taking, etc., and the amount of overrides necessary to make it behave properly). You can assume that it will use similar techniques as those now in Dialog to save size and location. btw, my plan is to adapt the known potential clients to use this popup as part of testing functionality and post everything here first.
Sounds good.
Created attachment 28073 [details] org.eclipse.jface.patch proposed PopupDialog support
Created attachment 28074 [details] org.eclipse.jdt.ui.patch AbstractInformationControl based on PopupDialog
Created attachment 28075 [details] org.eclipse.ui.workbench.patch KeyAssistDialog based on PopupDialog
Created attachment 28076 [details] org.eclipse.debug.ui.patch PopupInformationControl based on PopupDialog
Created attachment 28077 [details] org.eclipse.jface.text.patch DefaultInformationControl based on popup dialog
I've attached a first cut at support for a JFace PopupDialog and included hacks to the clients I used to test functionality. Feedback is encouraged. Doug, Dani,and Darin - Since I may not know the ins and outs of your popups, I'd like you to give them a spin and let me know of problems. In particular I barely tested the debug stuff as that was the last one I did ;-) I tried to minimize the API for this new class by making most of the configurable values settable in the constructor only. My thinking is that these are transient dialogs and not likely to have major reconfiguration. I provided API for anything that the information controls needed (such as status text, etc.) The biggest design issue in my mind is where/whether this dialog lives in the JFace window hierarchy. It doesn't have a button bar so I rejected putting it in the Dialog hierarchy. I ended up leaving it a subclass of Window so that it can inherit behavior for constraining bounds to the correct monitor, storing the shell, etc. This seems appropriate, but it means that subclasses from preexisting classes not in that hierarchy (such as the information controls) have new inherited API (create, close, open). I don't know if this is a big deal or not to Darin and Dani, since it doesn't affect IInformationControl. If this is a problem, then you could change my hacks to your classes so that your information controls simply use a PopupDialog rather than being one. This may make override of certain methods more awkward. I'll wait for comment. I did not convert ContextInformationPopup(2) or CompletionProposalPopup(2) in terms of this dialog yet, since I didn't want to continue on a path (inheriting from PopupDialog) that may be bogus. I'd like to get this in for M3 if possible, so prompt feedback would be much appreciated.
one more note: I did not add the suggested API for specifying how the popup might be positioned (top/center/bottom) or for automatically hiding the popup when the mouse exits a rectangle. If anyone feels strongly that we can eliminate a lot of redundancy by doing this, let me know...
Susan, I did not yet start to look at the stuff but have an initial question: did you test the stuff on all platforms? Those dialogs were always hard to get working the same way and correctly on all three major platforms.
No, I have not tested yet on non-Windows platforms. I don't (easily) have access to other platforms, but will be in Ottawa next week and was planning to do so at that time. If you try it on a non-windows platform and see obvious problems, let me know, and I'll follow up next week. Feedback on the API would still be useful even if you encounter platform-related problems.
I looked at the key assist and the content assist dialogs. Both seemed to work well and look good on GTK+. I also looked at the code itself, and it looked good too. I've included a few comments below: Design ------ + createMainContents should probably be called createDialogArea. It would be more consistent with its sibling, Dialog. + create[MainContents|DialogArea] should probably include a "Subclasses must override this method" in the javadoc (see Dialog). (Basically, any public/protected method should mention whether it can be overridden. If it absolutely cannot be overridden, then it should probably be marked "final".) Nitpicks -------- + Extraneous blank line added in org.eclipse.jface/messages.properties + Copyright date on PopupDialog should be 2005 not 2004,2005 ... I think + The javadoc on open and close is probably real javadoc, not (non-Javadoc)
Had no luck with the debug patch, but did some experimenting on my own. It would be really nice if we could tell the popup to position itself according to the current selection. I realize that may be asking a lot, but if we're going to build a wish list... Is it necessary for users to call create() before open()? I expected to be able to do something like new PopupDialog(...).open() the way I would with most dialogs. This approach gave me NPEs unless I called create() before open() though.
Kevin, I'll double check the debug patch against what I'm running. By "had no luck" do you mean it didn't apply correctly, or didn't work, or worked poorly? re: create() vs. open(). In general you should just be able to call open() like with most dialogs. However, the preexisting information control classes (DefaultInformationControl, AbstractInformationControl, PopupInformationControl) created their widgets in the constructor, and all of their public API was implemented with this assumption. So when listeners were added, they were just directly added to the widgets. (See Dani's remarks in third paragraph of comment #22). Rather than recode the information controls to keep their own listener lists, check for null widgets, etc., I simply added the create() call to their constructor, so that the widget life cycle would be similar to the original implementation. It's really up to the information control implementers (debug and text) whether this model is kept or not. The KeyAssistDialog, for example, follows the normal dialog open model. Doug, thanks for comments and trying on GTK. I agree with your comments and will fix accordingly.
It just didn't work. It NPE'd when I executed the Inspect action. If I remember correctly, ExpressionInformationControl's createControl method no longer got called so a lot of setup never happened. I played around a bit and got a popup dialog to appear, but it was only a few pixels tall so wasn't much good. Ultimately debug would like to get away from using IInformationControl in favour of simply creating a PopupDialog. Our hope is that our code will be much simpler. I've started refactoring our display action with this approach. I'll let you know how that goes. I've been testing on a mac using an Integration build that was less than perfect. That may be the source of some of my problems.
It's possible I attached the wrong patch or otherwise goofed. I've since made changes in both PopupDialog and the clients. Is it helpful to your refactoring for me to repost a working PopupInformationControl or are you well along your other path at this point? You can look at the KeyAssistDialog patch for a more traditional dialog approach. It doesn't do the early widget create, yet does support multiple open() calls.
I've got my popup dialog working already. I'm just fiddling with the location, size, and our custom close operations at this point. Overall I'm happy with the PopupDialog class. I'm still getting the NPE in open() if I don't call create() early. The first line of open() calls get shell, this returns null, create gets called, then later shell.open() is called, but shell is still null because its a local variable and its value was never set after the create() call. If I replace shell.open() with getShell().open(), I'm happy again. I haven't looked at the KeyAssistDialog patch closely, I'll give it a closer look.
oops...my bad. Add this line underneath the create() call in PopupDialog.open() shell = getShell(); KeyAssistDialog doesn't have the problem because it forces a create in its override of open(). I hadn't noticed that before.
thanks Susan! New problem now. I applied the KeyAssistDialog patch and brought up the KeyAssistDialog, but it only appear briefly for me. Looks like I immediately get an SWT.Deactivate from the parent shell and the KeyAssistDialog is closed on me.
It's probably the Mac sending a parent shell deactivate after the shell activate (My code was assuming the windows order). A quick hack you could try (I'm basically guessing on what the problem is) is remove the marked line below from the PopupDialog.configureShell method. If this works, I'll verify on all the platforms next week while in Ottawa. If the below hack doesn't get around it, you can remove the SWT.ON_TOP style bit from the constant PopupDialog.INFOPOPUP_SHELLSTYLE, and I'll get the real fix in next week when I have all the platforms at my disposal. from PopupDialog.configureShell ... shell.setLayoutData(gd); shell.addListener(SWT.Deactivate, new Listener() { public void handleEvent(Event event) { if (listenToDeactivate) { close(); } } }); shell.addListener(SWT.Activate, new Listener() { public void handleEvent(Event event) { listenToDeactivate = true; >>>>REMOVE THIS LINE listenToParentDeactivate = true; } }); if ((getShellStyle() & SWT.ON_TOP) != 0 && shell.getParent() != null) { shell.getParent().addListener(SWT.Deactivate, new Listener() {
You're probably right about the event ordering. Removing that line does make the problem go away.
Comment on attachment 28076 [details] org.eclipse.debug.ui.patch marking obsolete since Kevin is using new dialog now
Created attachment 28414 [details] jface.dialogs.patch - revised PopupDialog
Created attachment 28415 [details] jface.dialogs.images.patch menu images for PopupDialog
Created attachment 28416 [details] jface.text.patch - revised DefaultInformationControl
Created attachment 28417 [details] jdt.ui.patch - revised AbstractInformationControl, HierarchyInformationControl
Created attachment 28418 [details] revised KeyAssistDialog
Attached are the latest patches for the popup. Hoping that Doug and Kim will give these a spin on Linux and Mac. Doug and Kim - could you load all of the non-obsolete patches and try KeyAssistDialog, Content Assist, and the JDT popups (Ctrl-O, Ctrl-T) and compare the behavior before and after? I'll take a look if there's anything weird. Kevin - here's the latest for your new popup. If this all looks good on Mac and GTK then I will commit the jface changes, and let there be popups everywhere...
Created attachment 28439 [details] unified jface patches cleaned up patch and included missing message.properties
Created attachment 28447 [details] popup menu gif for org.eclipse.jface.dialogs.images
Created attachment 28449 [details] disabled menu image
The updated patch looks good to me. Thanks Susan!
Since I will not be able to provide feedback for M3 (out of office) I've asked Tom to look into this.
Dani & Tom - I opened bug #113104 and attached the jdt and platform text patches so that I can commit/verify this bug independently and you'll have a bug assigned to you to track it. The API is marked experimental so if you have issues we can discuss changes.
On the mac, the key assist popup doesn't stay up. It disappears as soon as it appears. Other than that things look good.
I quickly tested the key assist dialog on Linux GTK+, and it looks okay.
Created attachment 28518 [details] working around recent mac SWT bug
That patch doesn't appear to fix the problem on the Mac. The shell still flashes and disappears.
The flash/disappear is due to SWT bug #109952 (an extra shell deactivate event), which was fixed just after the integration build. I just tried it on the Mac with the nightly build, and it works. I'm going to go ahead and release the popup so that Kevin and Doug can start using it. Up to you guys if you want to wait for an integration build that fixes the Mac problem or not...otherwise you're likely to get popup closing bug reports.
Released >20051020
Anybody have a screenshot of this in action for the most common configurations?
Ed, as far as a screen snap goes, it's not much excitement to look at (most popups should look the same, the KeyAssist Dialog will look more like other popups)...this is more of a code reorg issue, providing a standard popup so everyone doesn't have to build their own.
Looking at the API, shouldn't Dialog and PopupDialog share some common base class which would have their common methods in it, such as createDialogArea()? You could do this without breaking the binary compatability of Dialog. Also, that 8-argument constructor is a bit of a monster. I could easily see you wanting to add more parameters later, ending up with many variations that are hard to tell apart. I think it would be much better to follow way Dialog does it with a simple constructor and setters. This would fit nicely with the idea of using a common base class. If these ideas don't make sense then maybe the new class shouldn't have 'Dialog' in the name, which implies it's a kind of dialog.
FYI: http://www.eclipsezone.com/eclipse/forums/t53457.html .
verified by checking KeyAssistDialog on windows and mac on I20051101-1204. Will rely on verification of bug #77345 on Linux to validate on Linux. The text use of this dialog is delayed to M4 and is being tracked in bug #113104.
Re: common superclass. I felt like this could go either way, and in the end decided it didn't buy much in the implementation yet. There's not much code to share apart from creating an empty dialog area and saving the bounds (and then I considered whether saving bounds should be promoted to window...). This refactoring could occur later if need be, but I don't find it compelling now. The constructor is a beast. Most of the options must be set before widget creation so I forced the issue by only providing setters for options that will be honored after widget creation. I can consider changing this, but the down side is documenting a bunch of API as "not supported after widget creation"...the constructor was a way to enforce it.
One way of avoiding massive constructors would be a factory class e.g. public class PopupDialogFactory { .... various setters and getters ..... // return this to support chaining of calls public PopupDialogFactory setXXX() ... public PopupDialog create() { return new PopupDialog(this) } } And create a constructor on PopupDialog that takes a PopupDialogFactory as argument. This simplifies construction and makes it possible to extend&enhance both PopupDialog and the factory class.
