Re: [Jmri-developers] Observations from using RT3 for a weekend show

[Giorgio <xnt...@gm...>]

Hi Pete,

Implementation:
> In Layout Editor, LayoutBlocks contain Jmri.Block by composition. An OBlock
> is a subclass of Jmri.Block, so a LayoutBlock could contain an OBlock.
> Wherever LE connects blocks, it would need to create Portals and OPaths.
> Perhaps Sections could be converted to be the PBlock class mentioned above.
>
> When OPath appeared I got the impression that they were somehow a duplicate
of Paths created by LayoutEditor, the main difference being that OPaths were
created manually and LE Paths automatically.

I think it would be rather easy to create OBlocks from LE Blocks and OPaths
(and Portals) starting from LE Paths.  They likely contain the same
relationships. The main problem I see is maintaining the synchronization
between Paths and Opaths. As far as I understand, the first ones get
re-created each time the panel is loaded (this helps overcoming problems due
to changes).  Furthermore, if the panel is changed, LE creates/modifies
paths (should this changes be automatically reflected in Opaths, where user
may have manually added/modified data?).

It's a typical problem of synchronization between data automatically created
and those manually entered :-)

Probably, creation of OBlocks, etc. from LE data should be manually
triggered by user and, in case previous data (OBlocks, etc.) are found and
do not match, differences should be listed letting user decide what to do.

I am looking into generating OBlocks, Portals and OPaths from track diagrams
> in Control Panel Edito
>
>
Converging data created by LE and those created/used by Panel Editor (Or
Control Panel Editor) into a unique structure would allow users to employ
the same automation tools irrelevant from the chosen editor.


ciao

Giorgio