I'd like to refactor the way how PaneProgPane is built up. No UI change intended in this phase, but rather code can be cleaned up.
Why doing this: in a later phase, I'd like to make _visual_ changes (see below). Any change, or bugfix will be more consistent, if done on 'canonical' code and easier to review.
The class actually contains 3 (almost) independent services:
- panel content builder
- the panel's logic itself (button binding, activation of functions)
- programmer process
I believe these three things are better separated, to follow prinicples of Go4. The current code is also quite messy (see newGridItem) and duplicated (newGroup, newColumn, newRow) as well.
Many arguments are passed to methods, which could be provided in context object, if a "builder" pattern is used. Initial prototype shows reduction of duplicated code AND GridBagConstraints manipulation code. Refactor is however not THAT successful since the LOC is +- the same before/after.
Why I am writing this mail at all: This is refactoring - should not affect end-user or API behaviour. Despite some testing, I need help from someone with more JMRI background to analyse the code for accidental changes; if found, the should be evaluated. Consistency fixes could be kept, but the goal is to just simplify the code, at this moment.
Anyone willing to collaborate / review ?
Second, I would like to separate XML reading code, from the *actual* layout building one. During analysis, it turned out that a decomposition will actually save some branches in the code.
Why doing this: In a later phase, I'd like to provide enhanced GridBag-based UI (some - IMHO - better alignment + anchors). I believe that UI should not be arranged as scattered tea leaves on the line.
And try to implement GroupLayout-based UI (except grids). GroupPanel COULD give better layout, better respect for L&F control spacing reducing the "scatter" effect even further.
The separation of xml / layout allows to provide "enhanced" impls as opt-ins, or small changes on a branch so users (who want) can play with it and later decide the fate of these changes for the official release. And makes way easier to review the changes, which should be mostly in the layout code itself.
Again someone more knowledgeable could point me on counter-examples in decoder configs early, so I could either accomodate the code or propose consistent layout change - when the result is presented to users, it could look "differently", but should be "more consistent" within the changed style.
BTW there's a non-JMRI motivation as well: I plan to plug into the refactored code in my own project, providing yet different UI. Cleaning JMRI code first could make my life quite easier.