Topics

Routes only use system names!

Ken Cameron
 

I was surprised to see that the routes only retain the system names for
turnouts. A user had changed turnouts from one connection to another and
used the 'move' option for the username. Everything else picked up just
fine. Myself, I've seldom used routes and hadn't noticed this. I suspect it
is only an artifact of the selection list. Or does anyone know why it
would/should only use systemNames instead of usernames?

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Bob Jacobsen
 

It’s because the route code (along with multiple other parts of JMRI) existing long before the idea of movable names came along, and have never been retrofitted.

For what needs to be done:
http://jmri.org/help/en/html/doc/Technical/Patterns.shtml#NamedBean in the “Handles” section.

Bob

On Jan 6, 2019, at 6:36 AM, Ken Cameron <@KenC57> wrote:

I was surprised to see that the routes only retain the system names for
turnouts. A user had changed turnouts from one connection to another and
used the 'move' option for the username. Everything else picked up just
fine. Myself, I've seldom used routes and hadn't noticed this. I suspect it
is only an artifact of the selection list. Or does anyone know why it
would/should only use systemNames instead of usernames?
--
Bob Jacobsen
@BobJacobsen

Dave Sand
 

Routes is 99% compliant.

diff --git a/java/src/jmri/jmrit/beantable/RouteTableAction.java b/java/src/jmri/jmrit/beantable/RouteTableAction.java
index 62953bf405..c34f2e1022 100644
--- a/java/src/jmri/jmrit/beantable/RouteTableAction.java
+++ b/java/src/jmri/jmrit/beantable/RouteTableAction.java
@@ -1014,7 +1014,7 @@ public class RouteTableAction extends AbstractTableAction<Route> {
int setTurnoutInformation(Route g) {
for (int i = 0; i < _includedTurnoutList.size(); i++) {
RouteTurnout t = _includedTurnoutList.get(i);
- g.addOutputTurnout(t.getSysName(), t.getState());
+ g.addOutputTurnout(t.getDisplayName(), t.getState());
}
return _includedTurnoutList.size();
}

Dave Sand

On Jan 6, 2019, at 12:54 PM, Bob Jacobsen <@BobJacobsen> wrote:

It’s because the route code (along with multiple other parts of JMRI) existing long before the idea of movable names came along, and have never been retrofitted.

For what needs to be done:
http://jmri.org/help/en/html/doc/Technical/Patterns.shtml#NamedBean in the “Handles” section.

Bob

On Jan 6, 2019, at 6:36 AM, Ken Cameron <@KenC57> wrote:

I was surprised to see that the routes only retain the system names for
turnouts. A user had changed turnouts from one connection to another and
used the 'move' option for the username. Everything else picked up just
fine. Myself, I've seldom used routes and hadn't noticed this. I suspect it
is only an artifact of the selection list. Or does anyone know why it
would/should only use systemNames instead of usernames?
--
Bob Jacobsen
@BobJacobsen





Bob Jacobsen
 

Cool! Thanks for figuring that out.

I’m going to create a few test cases for DefaultRoute to double check that resolves it.

Bob

On Jan 6, 2019, at 11:44 AM, Dave Sand <@davesand> wrote:

Routes is 99% compliant.

diff --git a/java/src/jmri/jmrit/beantable/RouteTableAction.java b/java/src/jmri/jmrit/beantable/RouteTableAction.java
index 62953bf405..c34f2e1022 100644
--- a/java/src/jmri/jmrit/beantable/RouteTableAction.java
+++ b/java/src/jmri/jmrit/beantable/RouteTableAction.java
@@ -1014,7 +1014,7 @@ public class RouteTableAction extends AbstractTableAction<Route> {
int setTurnoutInformation(Route g) {
for (int i = 0; i < _includedTurnoutList.size(); i++) {
RouteTurnout t = _includedTurnoutList.get(i);
- g.addOutputTurnout(t.getSysName(), t.getState());
+ g.addOutputTurnout(t.getDisplayName(), t.getState());
}
return _includedTurnoutList.size();
}

Dave Sand


On Jan 6, 2019, at 12:54 PM, Bob Jacobsen <@BobJacobsen> wrote:

It’s because the route code (along with multiple other parts of JMRI) existing long before the idea of movable names came along, and have never been retrofitted.

For what needs to be done:
http://jmri.org/help/en/html/doc/Technical/Patterns.shtml#NamedBean in the “Handles” section.

Bob

On Jan 6, 2019, at 6:36 AM, Ken Cameron <@KenC57> wrote:

I was surprised to see that the routes only retain the system names for
turnouts. A user had changed turnouts from one connection to another and
used the 'move' option for the username. Everything else picked up just
fine. Myself, I've seldom used routes and hadn't noticed this. I suspect it
is only an artifact of the selection list. Or does anyone know why it
would/should only use systemNames instead of usernames?
--
Bob Jacobsen
@BobJacobsen







--
Bob Jacobsen
@BobJacobsen

Bob Jacobsen
 

Routes is 99% compliant.

diff --git a/java/src/jmri/jmrit/beantable/RouteTableAction.java b/java/src/jmri/jmrit/beantable/RouteTableAction.java
index 62953bf405..c34f2e1022 100644
--- a/java/src/jmri/jmrit/beantable/RouteTableAction.java
+++ b/java/src/jmri/jmrit/beantable/RouteTableAction.java
@@ -1014,7 +1014,7 @@ public class RouteTableAction extends AbstractTableAction<Route> {
    int setTurnoutInformation(Route g) {
        for (int i = 0; i < _includedTurnoutList.size(); i++) {
            RouteTurnout t = _includedTurnoutList.get(i);
-            g.addOutputTurnout(t.getSysName(), t.getState());
+            g.addOutputTurnout(t.getDisplayName(), t.getState());
        }
        return _includedTurnoutList.size();
    }


I think it might be more extensive than that, but I’m having trouble understanding how RouteTableAction works.

As near as I can tell, the RouteElement and hence RouteTurnout, RouteSensor internal classes just track the user and system names of the elements.  They don’t use handles [1] and they don’t track whether the user selected/specified items via system name or via user name.  

Am I misunderstanding how this works?

Changing the RouteTurnout & RouteSensor classes to use NamedBeanHandles to preserve the name-of-selection is pretty straightforward.  The bigger problem is the UI.  When adding/editing via RouteTableAction, there are two basic selection operations.  (See big screen show below).  Some select via JComboBoxes that let you pick a user name or system name (gold arrows).  That’ll just work once it’s connected to Handles.

The bigger problem is the main turnouts and sensors, which are selected in a little embedded table where you click a checkbox to include the item (blue arrows).  That currently doesn’t specify whether the user selected the user or system name.  What’s the best way to update that so it does?

My first thought is to have each row have a checkbox at the start of the user name cell (which should be to the left of the system name cell to give it priority), and another checkbox next to the system name one.  


But that seems overly detailed and likely confusing to the _VAST_ _MAJORITY_ of JMRI users who just want to do simple things, and don’t want to spend time preparing for a future where our new robot overlords arrive with new DCC systems that we are all compelled to migrate to.  

Remember, JMRI Routes come from the Digitrax idea when you entered numbers into a throttle to configure them; if you wanted to change/migrate that, you did so entering new numbers. Somehow, despite system names and user names and migrating and tools and stuff, people actually made that simple idea work on their layout.

I would very much like to keep this interface simple, preferably simpler than now, rather than making it more complicated for a very rare use case. Any ideas on how to do that?

Bob


[1] That might be OK, as editing is a somewhat-transient operation.  Maybe it’s OK if moving-names while also editing at the time remains a “maybe people shouldn’t do amazingly obscure things” item.




On Jan 6, 2019, at 11:44 AM, Dave Sand <ds@...> wrote:

Routes is 99% compliant.

diff --git a/java/src/jmri/jmrit/beantable/RouteTableAction.java b/java/src/jmri/jmrit/beantable/RouteTableAction.java
index 62953bf405..c34f2e1022 100644
--- a/java/src/jmri/jmrit/beantable/RouteTableAction.java
+++ b/java/src/jmri/jmrit/beantable/RouteTableAction.java
@@ -1014,7 +1014,7 @@ public class RouteTableAction extends AbstractTableAction<Route> {
    int setTurnoutInformation(Route g) {
        for (int i = 0; i < _includedTurnoutList.size(); i++) {
            RouteTurnout t = _includedTurnoutList.get(i);
-            g.addOutputTurnout(t.getSysName(), t.getState());
+            g.addOutputTurnout(t.getDisplayName(), t.getState());
        }
        return _includedTurnoutList.size();
    }

Dave Sand


On Jan 6, 2019, at 12:54 PM, Bob Jacobsen <rgj1927@...> wrote:

It’s because the route code (along with multiple other parts of JMRI) existing long before the idea of movable names came along, and have never been retrofitted.

For what needs to be done:
http://jmri.org/help/en/html/doc/Technical/Patterns.shtml#NamedBean in the “Handles” section.

Bob

On Jan 6, 2019, at 6:36 AM, Ken Cameron <kcameron@...> wrote:

I was surprised to see that the routes only retain the system names for
turnouts. A user had changed turnouts from one connection to another and
used the 'move' option for the username. Everything else picked up just
fine. Myself, I've seldom used routes and hadn't noticed this. I suspect it
is only an artifact of the selection list. Or does anyone know why it
would/should only use systemNames instead of usernames?

--
Bob Jacobsen
rgj1927@...











--
Bob Jacobsen
rgj1927@...



Dave Sand
 

Your understanding is correct. Currently a row selection saves the sensor displayName or the turnout systemName. The side effect for turnouts is that turnout table moves are not reflected in Routes.

I would not change the UI. The separate system and user name columns provide flexibility for sorting. I have always assumed that user names are the default if available. The JmriBeanComboBoxes use the default DISPLAYNAME option.

The sensor and turnout lists in implementation.DefaultRoute do use named bean handles.

As far as I can tell, the only problem is the turnout system name. If I move a name and return to the route, the user name is now on a different system name.

Dave Sand

On Jan 8, 2019, at 10:19 AM, Bob Jacobsen <@BobJacobsen> wrote:

Routes is 99% compliant.

diff --git a/java/src/jmri/jmrit/beantable/RouteTableAction.java b/java/src/jmri/jmrit/beantable/RouteTableAction.java
index 62953bf405..c34f2e1022 100644
--- a/java/src/jmri/jmrit/beantable/RouteTableAction.java
+++ b/java/src/jmri/jmrit/beantable/RouteTableAction.java
@@ -1014,7 +1014,7 @@ public class RouteTableAction extends AbstractTableAction<Route> {
int setTurnoutInformation(Route g) {
for (int i = 0; i < _includedTurnoutList.size(); i++) {
RouteTurnout t = _includedTurnoutList.get(i);
- g.addOutputTurnout(t.getSysName(), t.getState());
+ g.addOutputTurnout(t.getDisplayName(), t.getState());
}
return _includedTurnoutList.size();
}

I think it might be more extensive than that, but I’m having trouble understanding how RouteTableAction works.

As near as I can tell, the RouteElement and hence RouteTurnout, RouteSensor internal classes just track the user and system names of the elements. They don’t use handles [1] and they don’t track whether the user selected/specified items via system name or via user name.

Am I misunderstanding how this works?

Changing the RouteTurnout & RouteSensor classes to use NamedBeanHandles to preserve the name-of-selection is pretty straightforward. The bigger problem is the UI. When adding/editing via RouteTableAction, there are two basic selection operations. (See big screen show below). Some select via JComboBoxes that let you pick a user name or system name (gold arrows). That’ll just work once it’s connected to Handles.

The bigger problem is the main turnouts and sensors, which are selected in a little embedded table where you click a checkbox to include the item (blue arrows). That currently doesn’t specify whether the user selected the user or system name. What’s the best way to update that so it does?

My first thought is to have each row have a checkbox at the start of the user name cell (which should be to the left of the system name cell to give it priority), and another checkbox next to the system name one.

<PastedGraphic-3.tiff>

But that seems overly detailed and likely confusing to the _VAST_ _MAJORITY_ of JMRI users who just want to do simple things, and don’t want to spend time preparing for a future where our new robot overlords arrive with new DCC systems that we are all compelled to migrate to.

Remember, JMRI Routes come from the Digitrax idea when you entered numbers into a throttle to configure them; if you wanted to change/migrate that, you did so entering new numbers. Somehow, despite system names and user names and migrating and tools and stuff, people actually made that simple idea work on their layout.

I would very much like to keep this interface simple, preferably simpler than now, rather than making it more complicated for a very rare use case. Any ideas on how to do that?

Bob


[1] That might be OK, as editing is a somewhat-transient operation. Maybe it’s OK if moving-names while also editing at the time remains a “maybe people shouldn’t do amazingly obscure things” item.


<PastedGraphic-2.png>


On Jan 6, 2019, at 11:44 AM, Dave Sand <@davesand> wrote:

Routes is 99% compliant.

diff --git a/java/src/jmri/jmrit/beantable/RouteTableAction.java b/java/src/jmri/jmrit/beantable/RouteTableAction.java
index 62953bf405..c34f2e1022 100644
--- a/java/src/jmri/jmrit/beantable/RouteTableAction.java
+++ b/java/src/jmri/jmrit/beantable/RouteTableAction.java
@@ -1014,7 +1014,7 @@ public class RouteTableAction extends AbstractTableAction<Route> {
int setTurnoutInformation(Route g) {
for (int i = 0; i < _includedTurnoutList.size(); i++) {
RouteTurnout t = _includedTurnoutList.get(i);
- g.addOutputTurnout(t.getSysName(), t.getState());
+ g.addOutputTurnout(t.getDisplayName(), t.getState());
}
return _includedTurnoutList.size();
}

Dave Sand


On Jan 6, 2019, at 12:54 PM, Bob Jacobsen <@BobJacobsen> wrote:

It’s because the route code (along with multiple other parts of JMRI) existing long before the idea of movable names came along, and have never been retrofitted.

For what needs to be done:
http://jmri.org/help/en/html/doc/Technical/Patterns.shtml#NamedBean in the “Handles” section.

Bob

On Jan 6, 2019, at 6:36 AM, Ken Cameron <@KenC57> wrote:

I was surprised to see that the routes only retain the system names for
turnouts. A user had changed turnouts from one connection to another and
used the 'move' option for the username. Everything else picked up just
fine. Myself, I've seldom used routes and hadn't noticed this. I suspect it
is only an artifact of the selection list. Or does anyone know why it
would/should only use systemNames instead of usernames?
--
Bob Jacobsen
@BobJacobsen







--
Bob Jacobsen
@BobJacobsen



Ken Cameron
 

I agree with Dave, I had the presumption that the username was used when one
was available. I'm trying to think of a use case where it would be important
to create a route by systemName when there is a username available, and
nothing comes to mind.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Bob Jacobsen
 

The SP Shasta (see https://github.com/bobjacobsen/SPShasta/tree/master/userfiles ) has routes (and logix and other things) that were created with system names that should stay as system names, because there’s a set of scripts that works with them as such. Having them change semi-magically to user names would be unfortunate.

More generally, if a user specified a name, that’s the name that should be remembered. Doesn’t matter what type it is: They choose something, and it’s not the programs place to correct that.

The question here is what’s a good UI to figure out which one they chose.

Bob

On Jan 8, 2019, at 10:22 AM, Ken Cameron <@KenC57> wrote:

I had the presumption that the username was used when one
was available. I'm trying to think of a use case where it would be important
to create a route by systemName when there is a username available, and
nothing comes to mind.
--
Bob Jacobsen
@BobJacobsen

Dave Sand
 

Does the Logix, etc., care about the content of a route?  Jython could look at the route internals, but not Logix.

The systemName field in the XML for route output sensors and turnouts contains the handle getName value which can be either the user name or the system name.  There is no provision for name type.  

Since a user has never had the ability to choose the name type for an included sensor or turnout, I don’t see any value in making the UI more complicated.

If someone REALLY wanted to move a user name to a different object but keep the Route reference on the old object, they would have to re-select the old object in the route which now only has a system name.


Dave Sand


On Jan 8, 2019, at 1:45 PM, Bob Jacobsen <rgj1927@...> wrote:

The SP Shasta (see https://github.com/bobjacobsen/SPShasta/tree/master/userfiles ) has routes (and logix and other things) that were created with system names that should stay as system names, because there’s a set of scripts that works with them as such.  Having them change semi-magically to user names would be unfortunate.

More generally, if a user specified a name, that’s the name that should be remembered.  Doesn’t matter what type it is:  They choose something, and it’s not the programs place to correct that. 

The question here is what’s a good UI to figure out which one they chose.

Bob

On Jan 8, 2019, at 10:22 AM, Ken Cameron <kcameron@...> wrote:

I had the presumption that the username was used when one
was available. I'm trying to think of a use case where it would be important
to create a route by systemName when there is a username available, and
nothing comes to mind.

--
Bob Jacobsen
rgj1927@...






db123@bergqvist.se
 

I have a possible solution, but it doesn't follow the user interface conventions so it could be a bad solution.

The table could be redesigned so that the names themselves are clickable and that you select or unselect an item by clicking on that name. For those items that are selected, the entire row are marked, for example by a different background color. The item in that row that the user selected has a different marking, for example a different background color.

Example:
The row is blue and the selected name is yellow.

Then these things can happen:

* The user clicks on a name in a row that isn't selected. The row now gets blue and the item gets yellow.
* The user clicks on a selected name in a selected row. The row now get unselected (no background).
* The user clicks on another name in a selected row. The row stay selected (blue) but the new name gets selected (yellow) and the previous name gets unselected (blue).

But as I said above, this is not a common user interface.

Daniel

2019-01-08 20:45 skrev Bob Jacobsen:

The SP Shasta (see
https://github.com/bobjacobsen/SPShasta/tree/master/userfiles ) has
routes (and logix and other things) that were created with system
names that should stay as system names, because there’s a set of
scripts that works with them as such. Having them change
semi-magically to user names would be unfortunate.
More generally, if a user specified a name, that’s the name that
should be remembered. Doesn’t matter what type it is: They choose
something, and it’s not the programs place to correct that.
The question here is what’s a good UI to figure out which one they chose.
Bob

On Jan 8, 2019, at 10:22 AM, Ken Cameron <@KenC57> wrote:
I had the presumption that the username was used when one
was available. I'm trying to think of a use case where it would be important
to create a route by systemName when there is a username available, and
nothing comes to mind.
--
Bob Jacobsen
@BobJacobsen

Randall Wood
 

I think that if you change the user interface to include a single include check box, that check box should be in its own column. This would allow sorting by if the turnout is included in the route. Since tables can be sorted by multiple columns, sorting by username and then included would give the user the ability to see a sorted list of all (not) included usernames (depending on sort order of included).