Topics

Package for swing code

danielb987
 

In LogixNG, I have a lot of classes that has a parallel swing class, the same way that many classes has a parallel xml class. Examples:

jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml

jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml

LogixNG is designed



These swing classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is responsible to configure,

danielb987
 

I apologize, I sent the mail too fast.

In LogixNG, I have a lot of classes that has a parallel swing class, the same way that many classes has a parallel xml class. Examples:

jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml

jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml

LogixNG is designed to be flexible and extendable. These swing classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is responsible to configure the main classes so that editors doesn't need to know about the classes in advance. For example, the LogixNG editor doesn't need to know how to configure ActionTurnout, since it can load the class configureswing.ActionTurnoutSwing that handle it for the editor.

But this breaks the idea that all swing code should be in the packages "swing". In LogixNG, swing classes that stands on their own, like editors, are in the packages "swing". Swing classes that exists to configure a single class are in the packages "configureswing". Is this acceptable, or should I rename all the "configureswing" packages to "swing" and follow the current pattern?

Daniel

Bob Jacobsen
 

Not sure what you’re asking.

If you have jmri.jmrit.logixng.digital.actions.ActionTurnout then you should have jmri.jmrit.logixng.digital.actions.swing.ActionTurnoutConfigPane or something like that. The convention for the sub-package is “swing”, and to name things with e.g. Pane if they’re a pane, so ActionTurnoutConfigPane is the Pane that Config’s the ActionTurnout.

java/src/jmri/jmrix/loconet/LNCPSignalMast.java
java/src/jmri/jmrix/loconet/swing/LNCPSignalMastAddPane.java

Is there something different about ’swing’ and ‘configureswing’ here?

Bob


On Jan 2, 2020, at 3:19 PM, danielb987 <db123@...> wrote:

I apologize, I sent the mail too fast.

In LogixNG, I have a lot of classes that has a parallel swing class, the same way that many classes has a parallel xml class. Examples:

jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml

jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml

LogixNG is designed to be flexible and extendable. These swing classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is responsible to configure the main classes so that editors doesn't need to know about the classes in advance. For example, the LogixNG editor doesn't need to know how to configure ActionTurnout, since it can load the class configureswing.ActionTurnoutSwing that handle it for the editor.

But this breaks the idea that all swing code should be in the packages "swing". In LogixNG, swing classes that stands on their own, like editors, are in the packages "swing". Swing classes that exists to configure a single class are in the packages "configureswing". Is this acceptable, or should I rename all the "configureswing" packages to "swing" and follow the current pattern?

Daniel


--
Bob Jacobsen
@BobJacobsen

danielb987
 

I have an interface, SwingConfiguratorInterface, which all classes in configureswing implements:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/swing/SwingConfiguratorInterface.java

All the managers in LogixNG has a method that returns a list of all classes that manager support. For example, the DigitalActionManager supports ActionTurnout, ActionSensor, ActionLight, and so on.

The editor can ask the manager which classes is available, show that list to the user which select the class to create, and the editor then loads the swing class to configure that class. For example, if the user choose to create a new ActionTurnout, the editor loads the ActionTurnoutSwing class, and calls the method ActionTurnoutSwing.getConfigPanel() which returns a JPanel.

See for example:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/digital/actions/configureswing/ActionTurnoutSwing.java

But maybe it's better to leave this question until I have a PR what you can test, so you get the big picture? I hope to do a PR in a couple of weeks.

Daniel

2020-01-03 00:59 skrev Bob Jacobsen:

Not sure what you’re asking.
If you have jmri.jmrit.logixng.digital.actions.ActionTurnout then you
should have
jmri.jmrit.logixng.digital.actions.swing.ActionTurnoutConfigPane or
something like that. The convention for the sub-package is “swing”,
and to name things with e.g. Pane if they’re a pane, so
ActionTurnoutConfigPane is the Pane that Config’s the ActionTurnout.
java/src/jmri/jmrix/loconet/LNCPSignalMast.java
java/src/jmri/jmrix/loconet/swing/LNCPSignalMastAddPane.java
Is there something different about ’swing’ and ‘configureswing’ here?
Bob

On Jan 2, 2020, at 3:19 PM, danielb987 <db123@...> wrote:
I apologize, I sent the mail too fast.
In LogixNG, I have a lot of classes that has a parallel swing class, the same way that many classes has a parallel xml class. Examples:
jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml
jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml
LogixNG is designed to be flexible and extendable. These swing classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is responsible to configure the main classes so that editors doesn't need to know about the classes in advance. For example, the LogixNG editor doesn't need to know how to configure ActionTurnout, since it can load the class configureswing.ActionTurnoutSwing that handle it for the editor.
But this breaks the idea that all swing code should be in the packages "swing". In LogixNG, swing classes that stands on their own, like editors, are in the packages "swing". Swing classes that exists to configure a single class are in the packages "configureswing". Is this acceptable, or should I rename all the "configureswing" packages to "swing" and follow the current pattern?
Daniel
--
Bob Jacobsen
@BobJacobsen

Randall Wood <rhwood@...>
 

As far as user interaction with your new Logix goes, there is no meaningful difference between between configuration and other display of the Logix, so I’d simply put all display in a “swing” package instead of attempting to have a “swing" package for non-configuration display and a “configureswing” for display that allows configuration.

Put another way, a “json” package beside every “configurexml” package could be created and have meaningful differences (the json package classes read/write JSON, while the configurexml package classes read/write XML). Since Swing *is* the UI paradigm for the Java SE, all UI goes in the “swing” package, since multiple swing libraries would only force what could otherwise be package private implementation details to become public UI.

(If we were to decide to support JMRI on Android using JetPack Compose (the Android equivalent of Java SE Swing), we would wind up with “jetpack” packages beside every “swing" package. Alternately, if we were to use a curses implementation for running in an SSH session, we would have a “curses” package beside the “swing” packages.)

So I’d just use “swing” as the package where all Swing-based UI elements belong.

On 02-Jan-2020, at 19:14, danielb987 <db123@...> wrote:

I have an interface, SwingConfiguratorInterface, which all classes in configureswing implements:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/swing/SwingConfiguratorInterface.java

All the managers in LogixNG has a method that returns a list of all classes that manager support. For example, the DigitalActionManager supports ActionTurnout, ActionSensor, ActionLight, and so on.

The editor can ask the manager which classes is available, show that list to the user which select the class to create, and the editor then loads the swing class to configure that class. For example, if the user choose to create a new ActionTurnout, the editor loads the ActionTurnoutSwing class, and calls the method ActionTurnoutSwing.getConfigPanel() which returns a JPanel.

See for example:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/digital/actions/configureswing/ActionTurnoutSwing.java

But maybe it's better to leave this question until I have a PR what you can test, so you get the big picture? I hope to do a PR in a couple of weeks.

Daniel

2020-01-03 00:59 skrev Bob Jacobsen:
Not sure what you’re asking.
If you have jmri.jmrit.logixng.digital.actions.ActionTurnout then you
should have
jmri.jmrit.logixng.digital.actions.swing.ActionTurnoutConfigPane or
something like that.  The convention for the sub-package is “swing”,
and to name things with e.g. Pane  if they’re a pane, so
ActionTurnoutConfigPane is the Pane that Config’s the ActionTurnout.
java/src/jmri/jmrix/loconet/LNCPSignalMast.java
java/src/jmri/jmrix/loconet/swing/LNCPSignalMastAddPane.java
Is there something different about ’swing’ and ‘configureswing’ here?
Bob
On Jan 2, 2020, at 3:19 PM, danielb987 <db123@...> wrote:
I apologize, I sent the mail too fast.
In LogixNG, I have a lot of classes that has a parallel swing class, the same way that many classes has a parallel xml class. Examples:
jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml
jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml
LogixNG is designed to be flexible and extendable. These swing classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is responsible to configure the main classes so that editors doesn't need to know about the classes in advance. For example, the LogixNG editor doesn't need to know how to configure ActionTurnout, since it can load the class configureswing.ActionTurnoutSwing that handle it for the editor.
But this breaks the idea that all swing code should be in the packages "swing". In LogixNG, swing classes that stands on their own, like editors, are in the packages "swing". Swing classes that exists to configure a single class are in the packages "configureswing". Is this acceptable, or should I rename all the "configureswing" packages to "swing" and follow the current pattern?
Daniel
--
Bob Jacobsen
rgj1927@...


Bob Jacobsen
 

I agree with Randall: it would be better to just put it in a “.swing” sub-package.

The panes for configuring signal masts use a similar pattern. A loconet.LNCPSignalMast object is created and edited by a loconet.swing.LNCPSignalMastAddPane, etc.

Bob

On Jan 2, 2020, at 4:14 PM, danielb987 <db123@...> wrote:

I have an interface, SwingConfiguratorInterface, which all classes in configureswing implements:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/swing/SwingConfiguratorInterface.java

All the managers in LogixNG has a method that returns a list of all classes that manager support. For example, the DigitalActionManager supports ActionTurnout, ActionSensor, ActionLight, and so on.

The editor can ask the manager which classes is available, show that list to the user which select the class to create, and the editor then loads the swing class to configure that class. For example, if the user choose to create a new ActionTurnout, the editor loads the ActionTurnoutSwing class, and calls the method ActionTurnoutSwing.getConfigPanel() which returns a JPanel.

See for example:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/digital/actions/configureswing/ActionTurnoutSwing.java

But maybe it's better to leave this question until I have a PR what you can test, so you get the big picture? I hope to do a PR in a couple of weeks.

Daniel

2020-01-03 00:59 skrev Bob Jacobsen:
Not sure what you’re asking.
If you have jmri.jmrit.logixng.digital.actions.ActionTurnout then you
should have
jmri.jmrit.logixng.digital.actions.swing.ActionTurnoutConfigPane or
something like that. The convention for the sub-package is “swing”,
and to name things with e.g. Pane if they’re a pane, so
ActionTurnoutConfigPane is the Pane that Config’s the ActionTurnout.
java/src/jmri/jmrix/loconet/LNCPSignalMast.java
java/src/jmri/jmrix/loconet/swing/LNCPSignalMastAddPane.java
Is there something different about ’swing’ and ‘configureswing’ here?
Bob
On Jan 2, 2020, at 3:19 PM, danielb987 <db123@...> wrote:
I apologize, I sent the mail too fast.
In LogixNG, I have a lot of classes that has a parallel swing class, the same way that many classes has a parallel xml class. Examples:
jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml
jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml
LogixNG is designed to be flexible and extendable. These swing classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is responsible to configure the main classes so that editors doesn't need to know about the classes in advance. For example, the LogixNG editor doesn't need to know how to configure ActionTurnout, since it can load the class configureswing.ActionTurnoutSwing that handle it for the editor.
But this breaks the idea that all swing code should be in the packages "swing". In LogixNG, swing classes that stands on their own, like editors, are in the packages "swing". Swing classes that exists to configure a single class are in the packages "configureswing". Is this acceptable, or should I rename all the "configureswing" packages to "swing" and follow the current pattern?
Daniel
--
Bob Jacobsen
@BobJacobsen

--
Bob Jacobsen
@BobJacobsen

danielb987
 

Thanks. I will change configureswing to swing.

Daniel

2020-01-03 14:18 skrev Randall Wood via Groups.Io:

As far as user interaction with your new Logix goes, there is no
meaningful difference between between configuration and other display
of the Logix, so I’d simply put all display in a “swing” package
instead of attempting to have a “swing" package for
non-configuration display and a “configureswing” for display that
allows configuration.
Put another way, a “json” package beside every “configurexml”
package could be created and have meaningful differences (the json
package classes read/write JSON, while the configurexml package
classes read/write XML). Since Swing *is* the UI paradigm for the Java
SE, all UI goes in the “swing” package, since multiple swing
libraries would only force what could otherwise be package private
implementation details to become public UI.
(If we were to decide to support JMRI on Android using JetPack Compose
(the Android equivalent of Java SE Swing), we would wind up with
“jetpack” packages beside every “swing" package. Alternately, if
we were to use a curses implementation for running in an SSH session,
we would have a “curses” package beside the “swing” packages.)
So I’d just use “swing” as the package where all Swing-based UI
elements belong.

On 02-Jan-2020, at 19:14, danielb987 <db123@...> wrote:
I have an interface, SwingConfiguratorInterface, which all classes
in configureswing implements:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/swing/SwingConfiguratorInterface.java
All the managers in LogixNG has a method that returns a list of all
classes that manager support. For example, the DigitalActionManager
supports ActionTurnout, ActionSensor, ActionLight, and so on.
The editor can ask the manager which classes is available, show that
list to the user which select the class to create, and the editor
then loads the swing class to configure that class. For example, if
the user choose to create a new ActionTurnout, the editor loads the
ActionTurnoutSwing class, and calls the method
ActionTurnoutSwing.getConfigPanel() which returns a JPanel.
See for example:
https://github.com/danielb987/JMRI/blob/LogixNG_new_15/java/src/jmri/jmrit/logixng/digital/actions/configureswing/ActionTurnoutSwing.java
But maybe it's better to leave this question until I have a PR what
you can test, so you get the big picture? I hope to do a PR in a
couple of weeks.
Daniel
2020-01-03 00:59 skrev Bob Jacobsen:
Not sure what you’re asking.
If you have jmri.jmrit.logixng.digital.actions.ActionTurnout then
you
should have
jmri.jmrit.logixng.digital.actions.swing.ActionTurnoutConfigPane or
something like that. The convention for the sub-package is
“swing”,
and to name things with e.g. Pane if they’re a pane, so
ActionTurnoutConfigPane is the Pane that Config’s the
ActionTurnout.
java/src/jmri/jmrix/loconet/LNCPSignalMast.java
java/src/jmri/jmrix/loconet/swing/LNCPSignalMastAddPane.java
Is there something different about ’swing’ and
‘configureswing’ here?
Bob
On Jan 2, 2020, at 3:19 PM, danielb987 <db123@...> wrote:
I apologize, I sent the mail too fast.
In LogixNG, I have a lot of classes that has a parallel swing class,
the same way that many classes has a parallel xml class. Examples:
jmri.jmrit.logixng.digital.actions.ActionTurnout
jmri.jmrit.logixng.digital.actions.configureswing.ActionTurnoutSwing
jmri.jmrit.logixng.digital.actions.configurexml.ActionTurnoutXml
jmri.jmrit.logixng.digital.expressions.ResetOnTrue
jmri.jmrit.logixng.digital.expressions.configureswing.ResetOnTrueSwing
jmri.jmrit.logixng.digital.expressions.configurexml.ResetOnTrueXml
LogixNG is designed to be flexible and extendable. These swing
classes, ActionTurnoutSwing, ResetOnTrueSwing, and others, is
responsible to configure the main classes so that editors doesn't
need to know about the classes in advance. For example, the LogixNG
editor doesn't need to know how to configure ActionTurnout, since it
can load the class configureswing.ActionTurnoutSwing that handle it
for the editor.
But this breaks the idea that all swing code should be in the
packages "swing". In LogixNG, swing classes that stands on their
own, like editors, are in the packages "swing". Swing classes that
exists to configure a single class are in the packages
"configureswing". Is this acceptable, or should I rename all the
"configureswing" packages to "swing" and follow the current pattern?
Daniel
--
Bob Jacobsen
@BobJacobsen
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/2495
[2] https://groups.io/mt/69389469/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged