Re: The Definitive Users' Guide on How to Save Your Work in JMRI #WebHelpUpdate



I’ve not used JMRI so excuse me if talking through my hat....

Surely the best approach is that used by many other programs: any change, anywhere, made by the user sets a ‘dirty’ flag; this tested during exit, and the user is prompted to save her work (or deliberately not)...

On 4 May 2020, at 05:15, Dave Sand <ds@...> wrote:


I went through your list of links.  There appears to be some very old content, along with inconsistent content.  It is easy to fall into a worm hole.  I admire your courage.

PanelPro has two main classes of data.  The primary class contains the the tables and panels and is "stored" using the various menu items in the tables and panels (tap?) xml file.  The second class is the data handled by the various tools, many of which are in my list. 

I think the help page needs to describe the unique characteristics of the tables and panels data, and the necessary actions to store the data before quit and load the data after starting PanelPro.  The second part of the page should list the known tools and their data that exists outside of the tables and panels data.  This is probably a short description with a link to the appropriate tools help page which ideally will go to the data retention portion of the tool help.

Dave Sand

----- Original message -----
From: "JerryG via" <jerryg2003@...>
Subject: Re: [jmri-developers] The Definitive Users' Guide on How to Save Your Work in JMRI #WebHelpUpdate
Date: Sunday, May 03, 2020 1:44 PM


Perhaps I introduced an extraneous item to my suggested need by putting in the lines “Data stored in” in my original post.  It was not my intend to add tohubohu (, one of my favorite words) but to reduce it - for the beginning and typical user who might actually look at a help page.  So let me try to sort the ensuing discussion into what I see as three threads:

1. My original thought: How to describe to users what they have to do to make sure that all the work they put in to defining their layout, operations, and automation to JMRI will be available after they “quit” and the next time they come back.
2. Whether or not to tell people where various things are stored.  Personally, I think this is mostly for the more advanced user so happy to leave it where it is in in,, and, , and perhaps elsewhere.  Perhaps these pages need to be reworked, but that’s a topic for another discussion.  [More opportunity to reduce tohubohu.]
3. What to call the things we manipulate with JMRI:  layout elements, layout configuration, layout design, operations elements, automation elements, etc.  This is interesting as a good set of terms, widely and commonly used, will help all of our community members.  But that is key:  if they are not uniformly and consistently used by the people who put answers in the user forum (and write help pages and other documentation), they aren’t going to be of much value. I’m happy to start another thread on this topic if there is interest, so let’s drop that for the moment.

So my question (somewhat) remains:  what do users have to do to make sure nothing is lost between “quit” and restarting PanelPro or DecoderPro and reloading their panel file?  In some cases, nothing, since they haven’t done anything to cause anything to change within JMRI.  Not a very interesting case.  So assuming a user makes some change to something (could be as simple as resizing a window or as complicated as defining a new layout panel or operations environment), have I covered all the cases where a button has to be pressed or a menu item selected to meet the simple criteria that whatever the user did will still be there in the morning?  My list is in the first post.  I think that Dave Sand may have added some things to the list in the third post, but I’m not sure (how are those data files you list saved (or not) - does the user have to do anything to make that happen?). Users generally shouldn’t care about the file or files involved - I agree on that - but should know what has to be done to ensure the data is saved, including when something is saved automagically behind the scenes.  Oh, and are there some things that just aren’t saved, like the state of turnouts?  

Can you help me answer that question and I’ll write the help page that hopefully will help all? I at least believe it is pretty fundamental to users working successfully with all the rich features that you created in JMRI.


Join to automatically receive all group messages.