Topics

Layout of some panes

Svata Dedic
 

Hi,

I wonder why some DecoderPro panes are laid out in the particular way - what was the "intent" - maybe expressed bad, maybe broke over the time.

programmers/parts/BasicPanel.xml:
* first column extends across full height of the panel
* there's <dccaddress> and <label> in the first rows of the first column
* the second column starts with two empty labels.

This seems as if the autor attempted to align the first visible item at the same Y position as the "Short address" display item; but given each Column is separate this can't work, as <dccadress> has different height from a plain label.

What was the original "graphical" intent ?

The panel decoders/zimo/PaneAltFunctionMap8.xml (and others, too):
* work witha a table Function output / Function key;
* use row+column to laid out content
* use SPACES to aligh texts

Why is that ? If the intended "style" is a table, why <grid> is not used to place rows, columns and checkboxes ? Why textual space is used to position - align ... with a variable-pitch dialog font, the idea makes no sense at all (?)

Was the original intent different than table, or is there a behaviour difference between grid and a regular row + column layout ?


Thanks,
-Svata

Bob Jacobsen
 

On the first, I expect that the original graphical intent was just what it appears to be: To make the top of the page look cleaner. A quick check of git shows that this happened in 2003, long before grid layout was available. Moving it now to use grid would certainly be cleaner.

I don’t know anything in particular about the Zimo example, though it also dates to before there was a grid layout. Many of the Zimo files were contributed by somebody who didn’t quite understand the use of indirection to use standard layout, so they have extensive use of embedded panes.

Bob

On Oct 13, 2019, at 4:30 AM, Svata Dedic <svatopluk.dedic@...> wrote:

Hi,

I wonder why some DecoderPro panes are laid out in the particular way - what was the "intent" - maybe expressed bad, maybe broke over the time.

programmers/parts/BasicPanel.xml:
* first column extends across full height of the panel
* there's <dccaddress> and <label> in the first rows of the first column
* the second column starts with two empty labels.

This seems as if the autor attempted to align the first visible item at the same Y position as the "Short address" display item; but given each Column is separate this can't work, as <dccadress> has different height from a plain label.

What was the original "graphical" intent ?

The panel decoders/zimo/PaneAltFunctionMap8.xml (and others, too):
* work witha a table Function output / Function key;
* use row+column to laid out content
* use SPACES to aligh texts

Why is that ? If the intended "style" is a table, why <grid> is not used to place rows, columns and checkboxes ? Why textual space is used to position - align ... with a variable-pitch dialog font, the idea makes no sense at all (?)

Was the original intent different than table, or is there a behaviour difference between grid and a regular row + column layout ?


Thanks,
-Svata


--
Bob Jacobsen
@BobJacobsen

Svata Dedic
 

Dne 13. 10. 19 v 18:08 Bob Jacobsen napsal(a):
On the first, I expect that the original graphical intent was just what it appears to be: To make the top of the page look cleaner
[...]
Moving it now to use grid would certainly be cleaner.
I think that If I convert programmers/parts/BasicPane into <grid>, wrapping individual <display>s in <griditem>s, it would screw up vertical alignment of controls among label-control pairs: each griditem is separated in a JPanel so no vertical alignment within column's parts seems possible.
I might misread the code, didn't try actually.

I don’t know anything in particular about the Zimo example, though it also dates to before there was a grid layout. Many of the Zimo files were contributed by somebody who didn’t quite understand the use of indirection to use standard layout, so they have extensive use of embedded panes.
Hm, so far it seems the "Alt Function Map" checkbox table is "amost" (*) a duplicate of <fnmapping/> for *some* ZIMO decoders; for others, it does roughly the same thing, but for a different range of CVs and even different bit masks (i.e. output #1's mask is XXVXXXXX).

(*) still investigating the details. The difference might be a bug, but can be real. But if true duplicate what is the 'design policy' - should be the duplicated part rather removed ?

-S.

Bob

On Oct 13, 2019, at 4:30 AM, Svata Dedic <svatopluk.dedic@...> wrote:

Hi,

I wonder why some DecoderPro panes are laid out in the particular way - what was the "intent" - maybe expressed bad, maybe broke over the timeay

programmers/parts/BasicPanel.xml:
* first column extends across full height of the panel
* there's <dccaddress> and <label> in the first rows of the first column
* the second column starts with two empty labels.

This seems as if the autor attempted to align the first visible item at the same Y position as the "Short address" display item; but given each Column is separate this can't work, as <dccadress> has different height from a plain label.

What was the original "graphical" intent ?

The panel decoders/zimo/PaneAltFunctionMap8.xml (and others, too):
* work witha a table Function output / Function key;
* use row+column to laid out content
* use SPACES to aligh texts

Why is that ? If the intended "style" is a table, why <grid> is not used to place rows, columns and checkboxes ? Why textual space is used to position - align ... with a variable-pitch dialog font, the idea makes no sense at all (?)

Was the original intent different than table, or is there a behaviour difference between grid and a regular row + column layout ?


Thanks,
-Svata


--
Bob Jacobsen
@BobJacobsen

Bob Jacobsen
 

The purpose of having separated variable and layout information (in xml/decoder and xml/programmer) was to reduce duplication. So if there are custom panes that can fit that system and you want to spend the time to make that update, that would be great. Even taking common parts from decoder definition files (i.e. even a common pane definition from two ZImo* files) and making it a single fragment file would be progress.

Bob

On Oct 13, 2019, at 11:24 AM, Svata Dedic <garat@...> wrote:

The difference might be a bug, but can be real. But if true duplicate what is the 'design policy' - should be the duplicated part rather removed ?
--
Bob Jacobsen
@BobJacobsen