Date   

Re: Preview: alignment in gridbag layout

Dave Heap
 

Update,

On 16 Oct 2019, at 9:49 AM, Dave Heap <dgheap@...> wrote:

Do we need a "justify" attribute for labels?

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.
That's probably a good move, given it doesn't break existing layouts.
Looking again at the north-west alignment, I'm not sure it sits well with the centre alignment of the action/status panels below. I'd prefer a north alignment rather than the current centre alignment.

Likewise, the more I look at the samples, the less I like the enforced stretching of the input fields to all match the longest field and the detachment (by variable-length whitespace) of the labels from the input field.

I'm afraid that in both sample cases I find the old versions easier to read.

But I certainly don't like the current way multi-column format (e.g. The Basic pane) pads every column to fit the panel, resulting in a disconnection of columns if the tab size is expanded in order to easily view other (wider) tabs.

But these are just my opinions and others will no doubt have differing responses.

Dave in Australia


Re: Preview: alignment in gridbag layout

Bob Jacobsen
 

A couple high-level comments on this:

It would be helpful if you would push a branch with this to your GitHub repo so that we can run it ourselves. Understood that it’s not final. The idea is to see how it works with various existing definitions, etc.

We might want to have a discussion about what kind(s) of compatibility is going to be required. There’s a spectrum:

4) _All_ existing decoder & programmer definitions validate and display exactly as they did before
3) A manageable (which is an operational question, it’s manageable if we get it done) number require updates to display exactly as they did before
2) _All_ existing decoder & programmer definitions validate and display all the content reasonably, but not laid out as before
1) A manageable (which is an operational question) number have validation issues, which we correct, and they all display all the content reasonably, but not laid out as before
0) A manageable (which is an operational question) number have validation issues, which we correct; they all display, but some are Really Ugly and we don’t have the time it would take to fix them right.

i.e. (3) might be because we added an attribute that has to be specified to get them to look the same, and somebody has to decide how to set that. Reasonable people can differ on the ordering of e.g. 3&2, and what the definition of “reasonably” vs “Really Ugly” are.

I think “everything has to display exactly as it did with no changes” is too high a standard. On the other hand, having any significant number of decoders too ugly to use isn’t going to be a success.

I think there’s certainly room to _improve_ the display, even if that means people have to get used to some changes. But perhaps others differ.

Bob





On Oct 15, 2019, at 12:57 PM, Svata Dedic <svatopluk.dedic@...> wrote:

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

2/ extend with (height) to match the column. Makes rows in a column visually aligned. Spacing according to "related" spacing (will yet recode that to match L&F behaviour).

3/ labels left-justified: recommended for complex dialogs as the user can scan top-down starts of lines to find the one of interest.

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.

5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)

6/ Added puctuation to labels, support for accelerators (see the basic new pane).

7/ Spinners instead of decimal-value inputs, where there's min+max range. Consistent with GTK+.

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.

Todo:
- Add colorized background for spinners.
- provide tooltips for individual ComboBox items + selected item. Merge with combo's own tooltip
- generate "range" tooltips for numeric fields, from min/max.

Future possible experiments:
* Support some "merged" attribute for rows/column: layouter could make a grid from adjacent columns (rows). I don't want to turn it into <grid> directly, as the column (row) emphasizes flow of the components. A two-column (three-column) newspaper like layout is different from a grid.

* Think about three-cell variable layout: label, control, explanation. Could be useful for *some* (or all ?) layouts.

-Svata



<basic-new.png><basic-old.png><lights-new.png><lights-old.png>
--
Bob Jacobsen
@BobJacobsen


Re: Preview: alignment in gridbag layout

Dave Heap
 

Comments;

On 16 Oct 2019, at 6:57 AM, Svata Dedic <svatopluk.dedic@...> wrote:

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

The design philosophy when I created <grid> in JMRI was to allow use of all  GridBagLayout features supported by Swing. Discarding (making unavailable) a previously-available feature because you don't like the results of using it is not your call. It's also not fair on other custom definition developers who may already be relying on it in ways you don't expect/forsee.


2/ extend with (height) to match the column. Makes rows in a column visually aligned. Spacing according to "related" spacing (will yet recode that to match L&F behaviour).

We have to remain aware of the fact that other custom definition developers may have used techniques to overcome the existing shortcomings and your changes could break existing things.


3/ labels left-justified: recommended for complex dialogs as the user can scan top-down starts of lines to find the one of interest.

I'm undecided on the readability merits of that, given the widely-varying label length in some panes and the resulting wide gaps between some labels and their boxes.

Personally, I find your modified Basic and Lights panes harder to read than the old versions.

We have to remain aware of the fact that other definition developers may have used techniques to overcome the existing shortcomings and your changes could break things.

Do we need a "justify" attribute for labels?

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.

That's probably a good move, given it doesn't break existing layouts.


5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)

Again, we have to remain aware of the fact that other definition developers may have used techniques to overcome the existing shortcomings and your changes could break things.

6/ Added puctuation to labels, support for accelerators (see the basic new pane).

I'm not sure what you mean by "punctuation"? Do you simply mean adding a ":" in the definition  to the end of some labels (as in your sample) or that the ":" punctuation will be added to all labels by default?

By "accelerators" I'm guessing you mean the underlined shortcut keys to gain focus on a field?

Related question: We explicitly support embedded HTML in pane text, and I'm assuming that embedded HTML is also supported in our labels:
We don't want to break that.



7/ Spinners instead of decimal-value inputs, where there's min+max range. Consistent with GTK+.

I'm quite in favour of spinners provided we allow text-field editing of the value (JSpinner.NumberEditor).

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.

Not sure how you plan to decide on when and how far to shorten? Assume some extra attribute(s) to maintain compatibility.

Todo:
- Add colorized background for spinners.

I assume you mean STATE colour?

- provide tooltips for individual ComboBox items + selected item. Merge with combo's own tooltip

Make sure any merges to tooltips uses "jmri.util.StringUtil.concatTextHtmlAware" in case existing and/or added text uses embedded HTML.

Also be aware that Preferences->Roster->Programmer->Show CV Numbers in Tooltips uses StringUtil.concatTextHtmlAware to append CV number(s) and bit allocation(s) to tooltips.

- generate "range" tooltips for numeric fields, from min/max.

See above.


Future possible experiments:

* Support some "merged" attribute for rows/column: layouter could make a grid from adjacent columns (rows). I don't want to turn it into <grid> directly, as the column (row) emphasizes flow of the components. A two-column (three-column) newspaper like layout is different from a grid.

Provided it doesn't break existing...

* Think about three-cell variable layout: label, control, explanation. Could be useful for *some* (or all ?) layouts.

Provided it doesn't break existing...

Some of these suggested changes look good to me, but not all.

I'd certainly want to see the results of applying your Java code changes to untouched existing custom panes I wrote for the LokSound V4 and 5 definitions. Your changes need to pass the "don't break existing" rule. We've far too many definitions out there that we don't want/need to check and change, not to mention users who have their own private not-submitted definitions.

Dave in Australia






Preview: alignment in gridbag layout

Svata Dedic
 

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

2/ extend with (height) to match the column. Makes rows in a column visually aligned. Spacing according to "related" spacing (will yet recode that to match L&F behaviour).

3/ labels left-justified: recommended for complex dialogs as the user can scan top-down starts of lines to find the one of interest.

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.

5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)

6/ Added puctuation to labels, support for accelerators (see the basic new pane).

7/ Spinners instead of decimal-value inputs, where there's min+max range. Consistent with GTK+.

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.

Todo:
- Add colorized background for spinners.
- provide tooltips for individual ComboBox items + selected item. Merge with combo's own tooltip
- generate "range" tooltips for numeric fields, from min/max.

Future possible experiments:
* Support some "merged" attribute for rows/column: layouter could make a grid from adjacent columns (rows). I don't want to turn it into <grid> directly, as the column (row) emphasizes flow of the components. A two-column (three-column) newspaper like layout is different from a grid.

* Think about three-cell variable layout: label, control, explanation. Could be useful for *some* (or all ?) layouts.

-Svata


Re: A 4.17.5ish commit has made LRoute edits unable to be saved

Bob Jacobsen
 

If you have a particular set of the code (I.e. v4.17.4) that works and one that doesn’t (i.e. master), you can use `git bisect` to really rapidly find the commit that made the difference.

https://www.jmri.org/help/en/html/doc/Technical/GitFAQ.shtml

Bob

On Oct 14, 2019, at 6:52 PM, Pete Cressman <pete_cressman@...> wrote:

After editing an LRoute Initializer, any save panel operation removes all settings. Saves are OK on 4.17.4 and previous releases.

This must be an inadvertent error and although it's hard to resolve a negative question, if no one thinks its their commit,
I will look into it.

Pete
(waiting for no one's answer)
--
Bob Jacobsen
@BobJacobsen


Re: A 4.17.5ish commit has made LRoute edits unable to be saved

danielb987
 

Pete

Take a look at Issue #7504. It might be related.

Problem saving Logix conditionals
https://github.com/JMRI/JMRI/issues/7504

Daniel

2019-10-15 03:52 skrev Pete Cressman:

After editing an LRoute Initializer, any save panel operation removes
all settings. Saves are OK on 4.17.4 and previous releases.
This must be an inadvertent error and although it's hard to resolve a
negative question, if no one thinks its their commit,
I will look into it.
Pete
(waiting for no one's answer)
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/2077
[2] https://groups.io/mt/34541350/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged


A 4.17.5ish commit has made LRoute edits unable to be saved

Pete Cressman
 

After editing an LRoute Initializer, any save panel operation removes all settings.  Saves are OK on 4.17.4 and previous releases.

This must be an inadvertent error and although it's hard to resolve a negative question, if no one thinks its their commit,
I will look into it.

Pete
(waiting for no one's answer)


Re: Layout of some panes

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


Re: Which JDK

Randall Wood <rhwood@...>
 

I recommend AdoptOpenJDK’s LTS JDKs (either 8 or 11) from https://adoptopenjdk.net (it has none of the restrictions on use the Oracle JDKs have).

If you use homebrew:
- `brew cask install adoptopenjdk8` installs JDK 8
- `brew cask install adoptopenjdk` tracks the latest (currently 13)
- `brew tap AdoptOpenJDK/openjdk && brew cask install adoptopenjdk11` installs JDK 11 

Randall

On Oct 13, 2019, at 6:22 PM, Dave Sand <ds@...> wrote:

I am rebuilding my Mac with Catalina.   

I don't use an IDE, just Git, Ant, etc. from the command line.

Dave Sand





Which JDK

Dave Sand
 

I am rebuilding my Mac with Catalina.

I don't use an IDE, just Git, Ant, etc. from the command line.

Dave Sand


Re: Layout of some panes

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


Re: Layout of some panes

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


Re: Netbeans Help

Bob Jacobsen
 

People don’t have to use any particular Git setup for JMRI. We recommend that one for beginners because some people think it’s easier for beginners, but there are certainly other approaches.

Another one is to use separate remote settings explicitly. I’ve seen a couple examples:

- have origin point at GitHub JMRI/JMRI so “git full origin” does an update; have a separate remote called ‘mine’ pointing to your own GitHub repot and use ‘git push mine’ when something is ready for PR (Not and IDE recommendation for people who have authority to push to JMRI/JMRI, because it’s easy to make a mistake)

- or flip that, with a remote called ‘origin’ pointing to your own, and a remote called ‘main’ pointing to JMRI/JMRI. (This one tends to cause people to be working well behind head, because they forget to do timely “git pull main” operations)

Lots of ways to do this….

Bob

On Oct 13, 2019, at 5:41 AM, Bob M. <jawhugrps@...> wrote:

In my experience, Netbeans' GIT support is full-featured, but DOES NOT work well in a "triangular" repository situation as is recommended in JMRI's GIT help.

What I saw was that Netbeans would _CHANGE_ the local repository's "remote" setting for "push" to match the setting for the "remote" "pull". This effectively bypassed the personal github repository.
--
Bob Jacobsen
@BobJacobsen


Re: DecoderPro panel cleanup

Svata Dedic
 

Dne 09. 10. 19 v 18:26 Bob Jacobsen napsal(a):

https://www.jmri.org/help/en/html/apps/DecoderPro/CreateDecoderAdvanced.shtml
I looked on how ZIMO uses the layout and I found a funny thing:
Layout comes from programmer definition, ZIMO decoder gives variable title working (i.e. various light stuff).
When looking on the outcome, I am tempted to wrap ZIMO's items into a titled pane (common label in the title, save words in control labels). BUT
- programmer definition can't assume similar wording of the placeholder items, since they can be, in fact, unrelated, or can be just a few of them to form a visual group,
- decoder can't influence the layout in this case, but "knows" it would be good to group them

Strange thing ! Someone has an idea how the decoder could provide "hint" for the layout templates ?

The presentation model of rows and columns was meant to allow people to pack pages simply. It doesn’t give really detailed layout tools, and the hope was that people would just accept simple, common layouts. But some of decoder definitions go beyond that to use tricks in their custom panes to i.e. align things between columns. Not sure what to do about that, it’ll be interesting to see what develops.
I'm not sure that either. The tricks have to fail (IMHO) as they rely on presentation of a variable to be the same size as a text (label), which can't be guaranteed.
If some validation feedback elements step in (i.e. possible error will be displayed on next line), this assumption will break at all.

With GroupLayout, it is *possible* to skip intermediate panels (that are there just for grouping), which allows to glue components on a row, across columns. Maybe an extension hint element/attribute would be helpful to express the intent clearly (e.g. alignY='item-name-of-the-leader-component'; disallowing forward references).

I am not sure if this is doable with across JPanel levels with GridBag even if I somehow hacked the algorithm in a subclass.

-S.


Re: Netbeans Help

Bob M.
 

Steve,

In my experience, Netbeans' GIT support is full-featured, but DOES NOT work well in a "triangular" repository situation as is recommended in JMRI's GIT help.

What I saw was that Netbeans would _CHANGE_ the local repository's "remote" setting for "push" to match the setting for the "remote" "pull". This effectively bypassed the personal github repository.

Based on that experience, I have NOT done any "pull" or "push" operations from Netbeans - only from a separately-installed GIT command-line tool.

If I recall correctly, Github Desktop install has an option to include a linux-based terminal with git command line support. I do not remember the details. On my Win7Pro machine, I am currently using a GIT command line which was separate from the Github Desktop implementation. Unfortunately, I do not know where I got it...

FYI - it appears that Netbeans support for ANT is running in your Netbeans install, otherwise you would not have gotten the failure to find 'git' error you've shown.

I have not knowingly installed an ANT implementation.

I perform any JMRI build operations via right-clicking on the "build.xml" file and choosing the correct option, or via a pushbutton if simply running PanelPro or running a test of a single module.

This has served me well for many years, over I think Netbeans 6.x thru Netbeans 8.x.

When I press the "run" button, I get the following in the Netbeans "output" window. Note that there is a "cannot find git" message, but it does not stop the ant build!

ant -f "E:\\User Data\\NetBeans\\JMRI\\nbproject\\nbjdk.xml" panelpro
Warning: nbjdk.active=JDK_1.8 or nbjdk.home=${platforms.JDK_1.8.home} is an invalid Java platform; ignoring and using C:\Program Files\Java\jdk1.8.0_25
panelpro:
Execute failed: java.io.IOException: Cannot run program "git" (in directory "E:\User Data\NetBeans\JMRI"): CreateProcess error=2, The system cannot find the file specified
JMRI.init:
JMRI.copyfiles:
JMRI.jjtree:
JMRI.javacc:
JMRI.update-template-code:
Copying 1 file to E:\User Data\NetBeans\JMRI\java\tmp
JMRI.compile-generated-source:
Copying 1 file to E:\User Data\NetBeans\JMRI\target\classes\jmri
JMRI.compile:
JMRI.debug:
JMRI.panelpro:
Execute failed: java.io.IOException: Cannot run program "git" (in directory "E:\User Data\NetBeans\JMRI"): CreateProcess error=2, The system cannot find the file specified
JMRI.runtime-library-selection:
arch.lib.path E:\User Data\NetBeans\JMRI/lib/windows/x64:E:\User Data\NetBeans\JMRI/lib/windows
Launch normally (no debugger support)
2019-10-13 08:35:59,707 util.Log4JUtil INFO - ****** JMRI log ******* [main]
2019-10-13 08:35:59,723 util.Log4JUtil INFO - This log is appended to file: C:\Users\huzzah\JMRI\log\messages.log [main]
2019-10-13 08:35:59,723 util.Log4JUtil INFO - This log is stored in file: C:\Users\huzzah\JMRI\log\session.log [main]
2019-10-13 08:35:59,739 apps.Apps INFO - PanelPro version 4.17.5ish+huzzah+20191013T1235Z starts under Java 1.8.0_25 on Windows 7 amd64 v6.1 at Sun Oct 13 08:35:59 EDT 2019 [main]
2019-10-13 08:36:01,720 apps.Apps INFO - Starting with profile AGE3_sim.3f113c63 [main]
2019-10-13 08:36:02,110 node.NodeIdentity INFO - Using 54a13122-2e81-44c1-a2ae-3ecc16430ef7 as the JMRI storage identity for profile id 3f113c63 [AWT-EventQueue-0]
2019-10-13 08:36:02,437 xml.AbstractSerialConnectionConfigXml INFO - Starting to connect for "C/MRI" [main]
2019-10-13 08:36:03,093 util.FileUtilSupport INFO - File path program: is E:\User Data\NetBeans\JMRI\ [main]
2019-10-13 08:36:03,093 util.FileUtilSupport INFO - File path preference: is C:\Users\huzzah\JMRI\AGE3_sim.jmri\ [main]
2019-10-13 08:36:03,093 util.FileUtilSupport INFO - File path profile: is C:\Users\huzzah\JMRI\AGE3_sim.jmri\ [main]
2019-10-13 08:36:03,093 util.FileUtilSupport INFO - File path settings: is C:\Users\huzzah\JMRI\ [main]
2019-10-13 08:36:03,093 util.FileUtilSupport INFO - File path home: is C:\Users\huzzah\ [main]
2019-10-13 08:36:03,093 util.FileUtilSupport INFO - File path scripts: is C:\Users\huzzah\JMRI\AGE3_sim.jmri\jython\ [main]
2019-10-13 08:36:04,840 PanelPro.PanelPro INFO - Main initialization done [main]


I believe that the git version I am running is _not_ integrated into the operating system. This is likely the cause of the error. Luckily Netbeans (or JMRI's ant build mechanism?) has some way to get past the error.

Regards,
Billybob


Re: Netbeans Help

Randall Wood <rhwood@...>
 

The JMRI build chain in ant does not use NetBean’s built in Git tools, even when executed from within NetBeans, so, yes, installing git is required.

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


Dne 13. 10. 19 v 14:20 steve young via Groups.Io napsal(a):
I've been following the advice from
https://www.jmri.org/help/en/html/doc/Technical/NetBeans.shtml
however should I have Git installed?
Shouldn't be necessary; NetBeans ships with Eclipse JGit implementation bundled AFAIK, so it shouldn't require external git tools.

-S.




Re: Netbeans Help

Svata Dedic
 

Dne 13. 10. 19 v 14:20 steve young via Groups.Io napsal(a):
I've been following the advice from
https://www.jmri.org/help/en/html/doc/Technical/NetBeans.shtml
however should I have Git installed?
Shouldn't be necessary; NetBeans ships with Eclipse JGit implementation bundled AFAIK, so it shouldn't require external git tools.

-S.


Re: Netbeans Help

Randall Wood <rhwood@...>
 

I’d install git. Ant includes the first few characters of the current commit hash in the JMRI version number.

Randall

On Oct 13, 2019, at 08:20, steve young via Groups.Io <icklesteve@...> wrote:

Hi Folks,

I tried IDE's in the 90's and had bad experiences so have previously stuck with Notepad++ .
Since Randall's excellent suggestion that I try out an IDE, I've had my main dev laptop fail, so installed NB on a fresh Win7 install with 64bit JDK 8u221
I'm actually pretty impressed with the inline hint suggestions that NetBeans 11.1 offers however am struggling to compile.

Git not installed nor ant, using the JMRI folder in the Github desktop location ( For the moment I'll stick with Github Desktop for version control ).
I've been following the advice from
https://www.jmri.org/help/en/html/doc/Technical/NetBeans.shtml
however should I have Git installed?

TIA,
Steve.

Output from NB console

ant -f C:\\Users\\steve\\Documents\\GitHub\\JMRI\\nbproject\\nbjdk.xml clean debugWarning: nbjdk.active=JDK_1.8 or nbjdk.home=${platforms.JDK_1.8.home} is an invalid Java platform; ignoring and using C:\Program Files\Java\jdk1.8.0_221clean:Execute failed: java.io.IOException: Cannot run program "git" (in directory "C:\Users\steve\Documents\GitHub\JMRI"): CreateProcess error=2, The system cannot find the file specifiedJMRI.clean:C:\Users\steve\Documents\GitHub\JMRI\nbproject\nbjdk.xml:11: The following error occurred while executing this line:C:\Users\steve\Documents\GitHub\JMRI\build.xml:439: java.nio.file.InvalidPathException: Trailing char < > at index 41:  C:\Users\steve\Documents\GitHub\JMRI\temp at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)at java.io.File.toPath(File.java:2234)at org.apache.tools.ant.taskdefs.Delete.isDanglingSymlink(Delete.java:879)at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:642)at org.netbeans.modules.java.source.ant.DeleteTask.access$001(DeleteTask.java:37)at org.netbeans.modules.java.source.ant.DeleteTask$1.call(DeleteTask.java:52)at org.netbeans.modules.java.source.ant.DeleteTask$1.call(DeleteTask.java:49)at org.netbeans.modules.java.source.ant.DeleteTask.execute(DeleteTask.java:60)at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)at sun.reflect.GeneratedMethodAccessor270.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)at org.apache.tools.ant.Task.perform(Task.java:350)at org.apache.tools.ant.Target.execute(Target.java:449)at org.apache.tools.ant.Target.performTasks(Target.java:470)at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)at org.apache.tools.ant.Project.executeTargets(Project.java:1251)at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)at sun.reflect.GeneratedMethodAccessor270.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)at org.apache.tools.ant.Task.perform(Task.java:350)at org.apache.tools.ant.Target.execute(Target.java:449)at org.apache.tools.ant.Target.performTasks(Target.java:470)at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)at org.apache.tools.ant.Project.executeTarget(Project.java:1361)at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)at org.apache.tools.ant.Project.executeTargets(Project.java:1251)at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:261)at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:574)at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:128)BUILD FAILED (total time: 1 second)


Netbeans Help

steve young
 

Hi Folks,

I tried IDE's in the 90's and had bad experiences so have previously stuck with Notepad++ .
Since Randall's excellent suggestion that I try out an IDE, I've had my main dev laptop fail, so installed NB on a fresh Win7 install with 64bit JDK 8u221
I'm actually pretty impressed with the inline hint suggestions that NetBeans 11.1 offers however am struggling to compile.

Git not installed nor ant, using the JMRI folder in the Github desktop location ( For the moment I'll stick with Github Desktop for version control ).
I've been following the advice from
https://www.jmri.org/help/en/html/doc/Technical/NetBeans.shtml
however should I have Git installed?

TIA,
Steve.

Output from NB console

ant -f C:\\Users\\steve\\Documents\\GitHub\\JMRI\\nbproject\\nbjdk.xml clean debugWarning: nbjdk.active=JDK_1.8 or nbjdk.home=${platforms.JDK_1.8.home} is an invalid Java platform; ignoring and using C:\Program Files\Java\jdk1.8.0_221clean:Execute failed: java.io.IOException: Cannot run program "git" (in directory "C:\Users\steve\Documents\GitHub\JMRI"): CreateProcess error=2, The system cannot find the file specifiedJMRI.clean:C:\Users\steve\Documents\GitHub\JMRI\nbproject\nbjdk.xml:11: The following error occurred while executing this line:C:\Users\steve\Documents\GitHub\JMRI\build.xml:439: java.nio.file.InvalidPathException: Trailing char < > at index 41:  C:\Users\steve\Documents\GitHub\JMRI\temp at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)at java.io.File.toPath(File.java:2234)at org.apache.tools.ant.taskdefs.Delete.isDanglingSymlink(Delete.java:879)at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:642)at org.netbeans.modules.java.source.ant.DeleteTask.access$001(DeleteTask.java:37)at org.netbeans.modules.java.source.ant.DeleteTask$1.call(DeleteTask.java:52)at org.netbeans.modules.java.source.ant.DeleteTask$1.call(DeleteTask.java:49)at org.netbeans.modules.java.source.ant.DeleteTask.execute(DeleteTask.java:60)at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)at sun.reflect.GeneratedMethodAccessor270.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)at org.apache.tools.ant.Task.perform(Task.java:350)at org.apache.tools.ant.Target.execute(Target.java:449)at org.apache.tools.ant.Target.performTasks(Target.java:470)at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)at org.apache.tools.ant.Project.executeTargets(Project.java:1251)at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)at sun.reflect.GeneratedMethodAccessor270.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)at org.apache.tools.ant.Task.perform(Task.java:350)at org.apache.tools.ant.Target.execute(Target.java:449)at org.apache.tools.ant.Target.performTasks(Target.java:470)at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1388)at org.apache.tools.ant.Project.executeTarget(Project.java:1361)at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)at org.apache.tools.ant.Project.executeTargets(Project.java:1251)at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:261)at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:574)at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:128)BUILD FAILED (total time: 1 second)


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