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
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, Pete
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 impli
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
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 issu
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 s
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:
