Dialogs in JavaFX
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). [1] http://fxexperience.com/2014/06/bringing-dialogs-to-javafx/ Thanks! -- -- Jonathan
Re: Dialogs in JavaFX
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 cases. Steve 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). [1] http://fxexperience.com/2014/06/bringing-dialogs-to-javafx/ Thanks!
Re: Dialogs in JavaFX
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
you.");
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
214.513.1636
On Jun 20, 2014, at 7:05 AM, Stephen F Northover
wrote:
> 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 cases.
>
> Steve
>
> 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).
>>
>> [1] http://fxexperience.com/2014/06/bringing-dialogs-to-javafx/
>>
>> Thanks!
>>
>
Re: Dialogs in JavaFX
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.
Steve
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
you.");
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
214.513.1636
On Jun 20, 2014, at 7:05 AM, Stephen F Northover
wrote:
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
cases.
Steve
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).
[1] http://fxexperience.com/2014/06/bringing-dialogs-to-javafx/
Thanks!
Re: Dialogs in JavaFX
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
saying...");
dbox.showMessageDialog(focusedNode);
// Type Confirm: Boolean response
DialogBox dbox = new DialogBox("Sanity Check");
dbox.setMessage("Really???");
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 want:");
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");
dbox.setContent(myColorChooserPane);
if(dbox.showConfirmPanel(focusedNode))
setColor(myColorChooserPane.getSelectedColor());
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.
>
> Steve
>
> 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
>> you.");
>> 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
>> 214.513.1636
>>
>>
>> On Jun 20, 2014, at 7:05 AM, Stephen
Re: Dialogs in JavaFX
Jeff, could you please post your comments in Jira so that we don't lose
them?
Thanks!
-- 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
saying...");
dbox.showMessageDialog(focusedNode);
// Type Confirm: Boolean response
DialogBox dbox = new DialogBox("Sanity Check");
dbox.setMessage("Really???");
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
want:");
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");
dbox.setContent(myColorChooserPane);
if(dbox.showConfirmPanel(focusedNode))
setColor(myColorChooserPane.getSelectedColor());
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.
Steve
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
you.");
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
214.513.1636
On Jun 20,
Dialogs in JavaFX 8u40
Hi, I tested Java 8u40 b12 dialogs. Are there any plans to improve the design of the dialogs? Are there any plans for additional design development? BR, Peter
Re: Dialogs in JavaFX 8u40
Other than bug fixes, there is no additional work planned. If there are things you would like to see supported, please file requests in Jira. If there are design bugs, please report them! -- Jonathan Sent from a touch device. Please excuse my brevity. On 2 November 2014 07:05:10 GMT+13:00, Peter Penzov wrote: >Hi, > I tested Java 8u40 b12 dialogs. Are there any plans to improve the >design of the dialogs? Are there any plans for additional design >development? > >BR, >Peter
Re: Dialogs in JavaFX 8u40
There are no more design improvements planned for 8u40, and b12 has all of the latest changes. If there is something specific that you had in mind you could either discuss on this thread or file a JIRA, but it will be post-8u40. As for fixing bugs, we have about one more month -- M4 is on Dec 1, by which time all planned bug fixing work for 8u40 needs to be done (only critical bugs will be considered after that). -- Kevin Peter Penzov wrote: Hi, I tested Java 8u40 b12 dialogs. Are there any plans to improve the design of the dialogs? Are there any plans for additional design development? BR, Peter
