From: Robert C. <rco...@ya...> - 2008-06-27 18:20:26
|
Bob; Overall I think you have a great idea here and a very solid plan of how and when to implement it. I also like how you are trying to keep the default very simple so that new users just declare one system and some of the advanced or not supported by that one system 'things' default to internal. I also want to echo Dave's two-cents which we all can see from the user forum -- JMRI is by definition not the easiest thing to just plug in and use -- it is, again, by definition, trying to do an awful lot for everyone with any type of computer and any type of (DCC) train control hardware. But we need to find ways (like the excellent work that people are doing on the tutorials for the upcoming meets) and better examples and (to the point of this thread) better defaults so that new users remain excited and do not get turned off. As you all have probably noticed, I use JMRI more on the Layout Control side than on the reprogram my decoders side (I do use it to program my decoders -- i just don't reprogram them very often). Now, not ignoring the previous paragraph, if I understand your proposal I have a suggestion that has to be thought about carefully so as not to make JMRI too hard to use: > Each row is a set of radio buttons (only one can be selected) that > allow you to select the select the system/protocol that provides the > default implementation. For Sensors and Turnouts, this is not such > big deal, but the first thing this will buy us is the ability to have > throttles on one connection while using a programmer on another. You > could select SPROG for programmer and NCE for throttle, or even > LocoNet 1 for programmer and LocoNet 2 for throttle. (Eventually, > throttle, programmer, etc GUI tools and scripts will need to have > ways of selecting non-default connections, but that would be a second > phase of the work) If a system doesn't provide an option (C/MRI > doesn't do throttles or programmers; EasyDCC doesn't do sensors, > etc), then the button at that cross-point is grayed-out and not > available. > I guess I am drilling down on the "second phase of work" that you tried to exclude :)). Rather than Radio buttons (which I definitely agree are easier to use and less confusing to new users) we should consider a number (or a number from a picklist that defaults to 1). The idea of the number is that internally we will use it as the search order -- that is, if Loconet has a 1 and NCE has a 2 then first try and find that turnout on Loconet and then try and find it on Acela. As you can see, what I am trying to introduce underneigth the covers is support for a search list of supported systems for a given thing (throttle, turnout, sensor, light, etc). This underlying feature could perhaps then be used down the road by the N-Track, etc crowd who want to control a group of 'sub-divisions' (or modules or whatever) but really don't know until Friday night what the whole mess is going to look like. They could (again, down the road) have the NorthTown Loconet Subdivision and the Middleton Loconet Subdivison and the Southtown NCE Subdivision and the computer can worry about the commands getting to the right Connection wihout the need for massive re-assignments. Note: I am not talking about DCC addresses here, I am talking about Connections and Throttles and Turnouts and Lights, etc. More to my needs, I can have some of my Turnouts and Lights and Sensors on Loconet and some on Acela and they can all operate independent of which Connection they use. And then if I want to dust off my CMRI system (actually I think I need to solder most of it together as well) then I can add more turnouts and lights there as well. So, separating implementations from architecture, what I am asking for you to consider is the support for a ordered list of connections for each thing (throttle, turnout, sensor, light, etc). Sorry for rambling. Bob C ----- Original Message ---- From: David Duchamp <djd...@ma...> To: "Discussions about changes to the code; design, intent, etc" <jmr...@li...> Sent: Friday, June 27, 2008 1:11:29 PM Subject: Re: [Jmri-developers] On Multiple Systems, Configuration and the User Interface Bob, I really like your plan for handling multiple systems. It should make multiple systems much easier to handle and understand, and should provide a firm basis for future development. I have two implementation concerns with your planned changes--both easy to take into account, I think. 1. For current users, the first system is the "default" system when a system letter is not entered, e.g. a turnout system name is entered as a number only. This should be the default, so current configuration files continue to work as they currently do. You may have covered this in your plan, but if so, I missed it. 2. Most JMRI users have a single system connection and almost all new users start with single system connections. The current system configuration GUI is challenging enough to new users, but I worry that the new GUI will be even harder for them to get straight. I think that this concern can be addressed by designing the new configuration GUI with the goal of "simplicity for single system connection users". Such users, for example, don't need to change the system letter, or select which configuration defaults for throttles, etc., so they should not be presented with options only needed for multiple system connections. My 25 cents. Dave On Jun 27, 2008, at 11:10 AM, Bob Jacobsen wrote: > There have been recent threads on jmriusers, most recently one > helpfully entitled "PanelPro 2.1.6 problem", about configuration of > multiple systems. This note is about my current thinking on the same > topic. I've also put it in the doc Wiki at > <http://jmri.wiki.sourceforge.net/Configuration+Update>, > in a slight hope that we'll end up with a design note there after the > discussion. > > I'm hoping to start enough discussion that we can settle on some > ideas before Anaheim, knock them around some more there, and > implement them during the rest of July and August (I've got a long > trip in the August that will involve a lot of time on airplanes) > > Bob > > ---- Problem Statement ----- > > Focusing just on layout connections, there are really multiple > different kinds of things that get configured when a layout > connection is activated: > > 1) The basic communications protocol. > 2) The connection to the system > > These are only partially different in practice. For example, > jmri.easydcc has a single (set of) class(es) for handling the > communications (the TrafficController section), but multiple > connections to the layout (implementing PortAdapter). That's a clean > separation. > > At the other end is jmri.loconet, which originally had a nice clean > separation like that for the TrafficController, plus separate > PortAdapter implementations for MS100, then LocoBuffer, then > LocoBuffer-II, etc. > > But that soon separated, with now four (or five, depending on how you > count) TrafficController implementations to handle things like that > packetizing for different kinds of network connections, for the > slightly different PR2, etc. There's a similar hybrid situation in > several other system packages. > > Yet, these various LocoNet implementations share more than just a > system letter ("L"). They all provide a common LocoNet packet > interface, which allows mid-level tools to be (almost) entirely > common: Turnouts, Lights, Sensors all can use the same > implementation . Higher LocoNet-specific tools also benefit from all > those layout links via the common interface. (Power, Throttles and > Programming are customized with specific subclasses, but even they > provide common hig-level interfaces for tools) > > So there's a higher thing that's configured: > > 0) The system type > > > If you view the system from the top, you see three more types of > configuration: > > 3) Things accessed via the ImplementationManager and a manager which > proxies for multiple implementations of the specific manager > > 4) Things accessed via the ImplementationManager providing a unique > manager > > 5) Things accessed via direct access to the implementing class. > > People are generally most familiar with (3), but (4) is simpler so I > start with that. Power, programming and throttles are examples of > "unique manager". In the code right now, essentially all the tools > that use those ask the InstanceManager for the unique manager they > need (PowerManager, etc), and then just use it. The tools have no > support for more than one manager: No way to choose a different, > record which was used, overlap requests to alternate ones, etc. > > Turnouts, sensors, etc are examples of (3). Addressing is handled by > system letters for specific requests, and smart proxies that map > other requests. Use of system letters has essentially built support > for multiple managers into the basic code. > > Going back to type (4) unique managers, there's no reason that > InstanceManager couldn't make more than one available; that would be > an easy change. One would still be the default. Then all the GUI > tools, scripts, etc could over time be modified to allow the user to > select a different manager. > > Type (5) access is not commonly thought of as part of configuration, > but it's remarkably common in system-specific tools. Almost all of > them work by using a "class static" reference to find e.g. the > LocoNet TrafficController interface to send and receive LocoNet > packets. Those requests don't go through the InstanceManager, but > directly access the particular TrafficController via e.g. > LnTrafficController.instance(). This works because the configuration > process creates an object of the appropriate type for this, but it > presents many of the same problems of default, selection, etc as (4); > they just need to be indirected through the InstanceManager as part > of the solution. > > > There are ways of dealing with all this, some of which are present in > our current configuration GUI and some of which are not, but it's not > an entirely satisfactory situation. Jim Betz gave some sample cases: > >> I know of layouts that are either already running - or are under >> construction >> to run - multiple command stations using the following variations: >> >> a) Digitrax(1st) for trains and Digitrax(2nd) for control. >> >> b) NCE for trains and CMRI for control. >> >> c) NCE for trains and Digitrax for control (and vice versa). >> >> d) Digitrax for trains and CMRI for control. > > All of these are possible with the existing code; I've actually done > (a), (b), and (d), and I have no doubt that somebody has done (c). > (b), (c) and (d) can be done cleanly with the existing GUI; the only > trick is that you have to specify the order properly in (b). (a) > requires a custom configuration XML file and startup script, so it's > not possible in the GUI. > > The real problem is that our current configuration process (GUI and > underlying mechanism) completely conflates configuration of all the > separate parts discussed above. It's possible to get hack past some > of that with custom XML files and scripts, but that's not a desirable > solution. > > > ---- Proposal ---- > > I'd like to propose a new direction. Note that I definitely am _NOT_ > suggesting that anything be changed in the current development > series, or before the next production release. Rather, this is > something that we can start on with the 1st development releases > after the next production release, after Anaheim, and after we get a > chance to breathe a little. > > First, a description of what it might look like to the user, > following by some discussion on internals. > > I suggest that we leave the configuration screen as having one > "layout connection" in the basic section, and keep everything else > about connections, systems, etc, in the advanced section. This > defaults to a (new) choice that makes basic operation work via > internal sensors, turnouts, etc work, so that it's not necessary to > select _LocoNet_ simulator for that. > > The advanced section would have a "add connection" button that gives > you another (and another and another, as many as desired) area for > defining layout connection. Each layout connection definition area > (except the one in the basic preferences) carries a "remove" button > to remove it entirely, and go back to N-1 layout connections. > > Each layout connection definition will look different, however. > Right now, you select an option which combines a couple of concepts > ("EasyDCC via serial port" vs "EasyDCC via network"), which then > changes the input fields for various options. Sometimes, this > combines various things (The LocoNet options include both > communications settings like baud rate, but also protocol-specific > things like command station). > > I suggest that the top level selection is just basic system/protocol > type. For our current code, this would be the 21 existing systems > under jmrix (Acela, EasyDCC, Grapevine, Lenz, LocoNet, NCE, OakTree, > Powerline, etc; XPA might be included under Lenz, or maybe not). > > Once you've made that selection, you get a next round of selections > as needed: > > *) For some, you'd get choice of command station, EPROM version, etc. > (This might effect the choices in the next item; e.g. the methods to > connect to an Intellibox are different from connecting to a DCS050 > because the Intellibox also allows direct serial connection) > > *) For all, you'd get a choice of "Connection Methods". > > o) For those systems/protocols like NCE or EasyDCC that involve just > a serial connection, you'd have a "Serial Cable" choice, which once > selected would then open a section to set serial port, baud rate, > etc. But those would also have a "Over Network" choice for > connecting with a terminal server, along with the options needed for > that. > > o) For those systems/protocols that involve more levels of access, > e.g. Lenz and LocoNet require selecting an adapter type (LI100, > LI101, etc), you do that first, perhaps with options, and within that > you get to set any necessary communications options. > > Visually, I'm imaging a set of nested boxes. The inner ones change > to new choices when you make a selection in an outer box. The > nesting is "system (or hardware type or protocol; I'm not sure of the > best name)", then "connection (or adapter)", then "communications". > > > Below all this is a section on configuring default implementations. > I think Dick Bronson suggested displaying this as a table, which I > think is a great idea. > > Across the top, labelling the columns, are the N selected > communications types (including "internal") > > Down the rows are the various JMRI managed tools: Sensors, Turnouts, > Throttles, Programmers, etc. > > Each row is a set of radio buttons (only one can be selected) that > allow you to select the select the system/protocol that provides the > default implementation. For Sensors and Turnouts, this is not such > big deal, but the first thing this will buy us is the ability to have > throttles on one connection while using a programmer on another. You > could select SPROG for programmer and NCE for throttle, or even > LocoNet 1 for programmer and LocoNet 2 for throttle. (Eventually, > throttle, programmer, etc GUI tools and scripts will need to have > ways of selecting non-default connections, but that would be a second > phase of the work) If a system doesn't provide an option (C/MRI > doesn't do throttles or programmers; EasyDCC doesn't do sensors, > etc), then the button at that cross-point is grayed-out and not > available. > > As a special, separate row at the top, there will be a row of > 1-character text fields for the system letter for each connection. > At first, these will all be displaying defaults and locked, but > eventually you'll be able to specify the system letter. This is > particularly useful when using e.g. two LocoNet or two C/MRI > connections, or later when we run out of unique letters. (We've sort > of run out of unique letters now, in that we're using "L" for > "LocoNet as a communications network" and "PR3/PR2 programmer, which > doesn't talk to a LocoNet") > > At present, I'm not imagining that we'll add rows for selecting the > default for system-specific tools. You could imagine that if you've > got two LocoNet connections defined, you might want to control which > one of those is the default for e.g. the BDL16 programmer. But this > way lies madness, because it will result in an N^3 configuration > problem. Better is to just bite the bullet and invest the time to > make those tools be able to select which (of the valid choice) layout > connection to use. > > ---- Implementation ---- > > There's a lot of work needed to implement this, but almost all of the > pieces actually exist somewhere. A variable system letter has been > prototyped in the Powerline system, and basically works. The new CAN > system has a structure that allows some separate configuration, and > I've got a work directory where the (currently large amount of) > common code is refactored into one package. The configuration GUI > will need a lot of work, but it's recently been nicely localized. > The proxy managers already have separate default objects, though we > need a cleaner way to specify them. Etc. > > > > > -- > Bob Jacobsen, UC Berkeley > jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Jmri-developers mailing list > Jmr...@li... > https://lists.sourceforge.net/lists/listinfo/jmri-developers ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Jmri-developers mailing list Jmr...@li... https://lists.sourceforge.net/lists/listinfo/jmri-developers |