FWD » Core Development » User Interface

Refer to the ask-gui.p screenshots (4GL, P2J Web and P2J Swing) in #2701-2

The "Program Name" fill-in has the following problems:

1. In Swing, the outline rectangle is truncated (a portion of the right side is not displayed). In the web client, the entire highlight is shown exactly like in the 4GL.

2. The white background of the fill-in is truncated in P2J (for the Swing client, it is truncated at the same location as is the highlight rectangle). The web client truncates it at the same location even though the highlight is not truncated.

There is a problem that can be seen when a fill-in is explicitly sized taller than the default height. When the field is NOT enabled, the text is vertically centered. But when the field is enabled, the text appears at the vertical top of the fillin (like we do it in P2J by default).

demo/calc-static.p can be made to show this. See #2715-5

Issue in note 1 is fixed in 1811s rev 10969. Working on issue in note 2.

After using 1811s rev 10969 AND loaded the custom fonts in the directory, I get this:

For the same code, the P2J window is smaller in both dimensions. The difference is larger in height than width.

Without the custom fonts loaded, I get the same sizing results, so the sizing problem is not caused by using the custom fonts.

There is one more issue here: using the SENSITIVE attribute to enable a widget must not make it current focus (focus remains unchanged!). So our approach of using the same logic as ENABLE is not correct.

Greg Shah wrote:

For the same code, the P2J window is smaller in both dimensions. The difference is larger in height than width.

Without the custom fonts loaded, I get the same sizing results, so the sizing problem is not caused by using the custom fonts.

This is because P2J assumes the width/height specified via the attributes is for the full window, while in 4GL the new size is for the workspace... we need to differentiate resizing incoming from the driver (via MouseResizable), where the full window width is passed, and resize triggered by attribute change.

Constantin Asofiei wrote:

Greg Shah wrote:

For the same code, the P2J window is smaller in both dimensions. The difference is larger in height than width.

Without the custom fonts loaded, I get the same sizing results, so the sizing problem is not caused by using the custom fonts.

This is because P2J assumes the width/height specified via the attributes is for the full window, while in 4GL the new size is for the workspace... we need to differentiate resizing incoming from the driver (via MouseResizable), where the full window width is passed, and resize triggered by attribute change.

1811s rev 10970 contains a fix for window resize via attributes - the windows are now identical.

Is the issue in note 2 still open?

What is the plan to fix the issue in note 7? SENSITIVE is definitely used heavily in GUI so it is an important problem.

Greg Shah wrote:

Is the issue in note 2 still open?

Yes, I think I'll have a fix soon.

What is the plan to fix the issue in note 7? SENSITIVE is definitely used heavily in GUI so it is an important problem.

From some testing with calc-static.p looks like just setting the WidgetConfig.enabled attribute is OK, but I need to test some other scenarios.

1. once we fix the #2727 for right-aligned number formats, some TODOs in FillinGuiImpl.editableNativeDimension and editableNativeLocation need to be addressed (actually, the code removed). Currently, to place the content at the proper location, the location is moved to the right with the width of the space prefix. Horizontal placement works fine otherwise
2. vertical placement is still off by a few pixels... this is mostly related to drawing the text centered vertically. I think instead ascent/descent values need to be used (especially when editable mode is on).
3. caret color depends on the background - might be the same XOR operation as for other cases we saw.

Constantin Asofiei wrote:

Greg Shah wrote:

What is the plan to fix the issue in note 7? SENSITIVE is definitely used heavily in GUI so it is an important problem.

In the end this was related to this: ENABLE/SENSITIVE=true must not switch focus if current focus is valid. I've checked the MAJIC test which required TC.getEnablePendingFocus (GSO 491) and it works OK.

There is another issues in the end with GSO 491 and I'm in a conundrum: in 4GL, testcases/uast/enable_focus.p doesn't move focus with an ENABLE. In GSO 491 (on which the test relies), on a different step (when FOCUS is valid, in the same frame, but on a BUTTON), MAJIC expects for the focus to be moved... but I can't replicate this in 4GL, all combinations (scoping the frame to triggers, nested triggers, procedures) doesn't give me the "enable moves focus" feature MAJIC expects.

Eugenie: was all of the GSO 491 behavior captured on the 4GL or was some of it based on P2J?

The ThinClient revisions which introduced these are:

** 652 SIY 20110504          Fixed focus handling for ENABLE inside trigger.
** 653 SIY 20110506          Narroved conditions for ENABLE focus handling fix.
** 654 SIY 20110510          Another attempt to fix focus handling fix.

Greg Shah wrote:

Eugenie: was all of the GSO 491 behavior captured on the 4GL or was some of it based on P2J?

The test was captured 2011/04/27. Dragonfly was turned off ~2010/04/23(a year before). So I think this test is completely P2J based.

OK, let's fix the test to match the behavior that is believed to be correct based on 4GL testing.