Jeff, could you please post your comments in Jira so that we don't lose them?


-- Jonathan

On 21/06/2014 3:59 a.m., Jeff Martin wrote:
I agree that the four showXXX() methods are a slight complexity, but I think they are 
simpler than the alternative. They quickly communicate the implied "Type" of 
the DialogBox and response:

        // Type Message: No response
        DialogBox dbox = new DialogBox("FYI"); dbox.setMessage("Just 

        // Type Confirm: Boolean response
        DialogBox dbox = new DialogBox("Sanity Check"); 
        boolean response = dbox.showConfirmDialog(focusedNode);

        // Type Option: Integer response
        DialogBox dbox = new DialogBox("Which One"); dbox.setMessage("Select 
One"); dbox.setOptions(myOptions);
        int response = dbox.showOptionDialog(focusedNode, defaultOption);

        // Type Input: String response
        DialogBox dbox = new DialogBox("Tell Me"); dbox.setMessage("Tell me what you 
        String response = xbox.showOptionDialog(focusedNode, default);

The only alternative I see would be to explicitly set a DialogBox type and 
return a DialogBoxResponse, which could embody any of the above. That seems 
cumbersome to me. I also think it would be over-engineering to try to support 
any kind of response (say like a Color or a Font). In these cases, I think it's 
better to have your ColorChooserPane or FontChooserPane act as content:

        // Type ColorChooser: Boolean response plus Color
        DialogBox dbox = new DialogBox("Please Pick a Color"); 

In fact, your ColorChooserPane could have a showColorDialog() method that would 
just be the above code.

Jeff Martin

On Jun 20, 2014, at 10:15 AM, Stephen F Northover 
<> wrote:

This essentially matches my current thinking, however, I would have DialogBox 
as an abstract superclass of Alert.  Further, I would not have many different 
types of show() methods.

Want to take the discussion further in the JIRA?  That way, is will track 
everyone's thinking on the various issues.  The downside is that JIRA does not 
provide threaded conversations and it can be hard to follow.


On 2014-06-20, 9:41 AM, Jeff Martin wrote:
That is a great post. I think the big problem with dialogs in Swing was the 
permutations problem. There were four basic types of dialogs (Message, Confirm, 
Option, Input) with six different parameters (Title, Message, Icon, Content, 
MessageType, Options) - so JOptionPane ended up with a sea of static methods 
that were confusing to navigate.

I don't think you could go wrong with a simple DialogBox class like this (I 
love simple):

        // Constructor
        public DialogBox(String aTitle);

        // Options
        public String getTitle();
        public void setTitle(String aTitle);
        public String getMessage();
        public void setMessage(String aMessage);
        public MessageType getMessageType();
        public void setMessageType(MessageType aMessageType);
        public Node getContent();
        public void setContent(Node aNode);
        public Node getGraphic();
        public void setGraphic(Node aNode);
        public String[] getOptions();
        public void setOptions(String ... theOptions);

        // Convenience methods to set Message + MessageType
        public void setErrorMessage(String aMessage);
        public void setWarningMessage(String aMessage);
        public void setQuestionMessage(String aMessage);

        // Show methods
        public void showMessageDialog(T aComp);
        public boolean showConfirmDialog(T aComp);
        public int showOptionDialog(T aComp, String aDefault);
        public String showInputDialog(T aComp, String aDefault);

        // Programatic dismissal
        public void confirm();
        public void cancel();

Then most common invocations would look something like this:

        // Get user confirmation
        DialogBox dbox = new DialogBox("Sanity Check");
        dbox.setWarningMessage("Are you sure you want to do this? It could kill 
        if(!dbox.showConfirmationDialog(focusedNode)) return;

Using instance methods instead of static methods gives opportunity to subclass 
and override various methods. And notice the Content attribute - for the 
standard case when no Content is provided, it is built programmatically based 
on the parameters (essentially just the message and either an Option combo, an 
input textfield or nothing).

I've been using this in my JavaFX app for a while and it is working great and 
makes porting from Swing easy. I even built it on a convenient FormBuilder 
class that makes building a simple stack of form controls easy, and can also be 
used for advanced DialogBoxes.

Jeff Martin

On Jun 20, 2014, at 7:05 AM, Stephen F Northover <> 

Great post Jonathan.  The summary is that whatever direction we take, we'll 
have a plan for the future.  So if we run out of time and provide only a very 
scaled back API, we'll have prototyped how it can evolve to handle more complex 


On 2014-06-20, 12:37 AM, Jonathan Giles wrote:
Hi all,

Dialogs are something everyone wants, and also something most people seem to 
have an opinion on! JavaFX 8u40 will have dialogs, but what form they take 
(API-wise) is not yet defined. I've posted a relatively long discussion on this 
over at FX Experience [1] and your feedback is highly welcome. As I note in the 
blog post, the Jira issue for this feature is RT-12643. If you have any 
thoughts, please do post them there (rather than spam the many good people 
subscribed to openjfx-dev).



Reply via email to