FWD » Core Development » User Interface

Eugenie Lyzenko wrote:

Initial investigations for issue. The 4gl initial picture is attached here.

1. Take a look at the p2j 10974 and 10975 versions pictures. The frame loses the centered position and I think it is the regression from 10975.

Constantin, can you tell what can be the reason, what was changed in Frame with 10975 that causes the frame centering to become off?

The problem was related to the fact that the window doesn't adjust its virtual dimension when its width/height is set via the attributes (and the window is not yet realized). See 2677a rev 10980 for the fix.

There is still an issue here: if the window's size is adjusted (smaller) AFTER it is realized, then scrollbars are not displayed for the workspace.

2. The issue is the button widgets are not properly positioned by automatic layout manager as you can see comparing to 4gl picture.

The layout call which miss-places the buttons is this in FrameGuiImpl:

   public void setVisible(boolean visible)
   {
      if (visible && !config().realized)
      {
         savedTabOrder = null;

         // remove all labels (they we'll be re-added by the layout)
         Widget<GuiOutputManager>[] widgets = getContentPane().widgets();
         for (Widget<GuiOutputManager> widget : widgets)
         {
            if (widget instanceof Label)
            {
               widget.destroy();
               screen().getRegistry().removeWidget(UiUtils.getWidgetId(widget));
            }
         }

         doLayout();

         config().realized = true;
      }

This code needs to remain, as final layout is decided on frame realization. But please investigate why the buttons are miss-placed - maybe something else needs to be reset?

3. There is a good news too. In 10975 the scrollbar is not drawing anymore. I think this was a kind of frame size or scrollpane inside frame size issue.

I'm still seeing the scrollbar with rev 10980.

Eugenie Lyzenko wrote:

So the remaining issue is incorrect button placement inside the frame. Should I investigate and fix it within this task?

Yes, please do.

Hynek,

Debugging widget layout issue I have found the following weird code in StackLayout, method doLayout line 125:

...
      if (direction == Direction.VERTICAL)
      {
         maxSize = container.width() - insets.left - insets.right;
      }
      else
      {
         maxSize = container.width() - insets.left - insets.right;      
      }
...

I think the correct code is:

...
      if (direction == Direction.VERTICAL)
      {
         maxSize = container.width() - insets.left - insets.right;
      }
      else
      {
         maxSize = container.height() - insets.top - insets.bottom;      
      }
...
         if (direction == Direction.VERTICAL)
         {
            // only containers can be assigned size externally
            if (w instanceof Container)
            {
               ((Container<O>) w).setSize(maxSize, ((Container<O>) w).height());
            }

            origin.y += w.height();
         }
         else
         {
            // only containers can be assigned size externally
            if (w instanceof Container)
            {
               ((Container<O>) w).setSize(((Container<O>) w).width(), maxSize);
            }

            origin.x += w.width();
         }
...

Please confirm if the changed code is correct or explain what original version does. Hopefully currently we always have direction == Direction.VERTICAL so potential bug has no affect for now.

Eugenie Lyzenko wrote:

Hynek,

Debugging widget layout issue I have found the following weird code in StackLayout, method doLayout line 125:
[...]

Good catch.

I think the correct code is:
[...]

Yes this is correct.

Task branch 2677a for review updated to revision 10986.

Small fix for StackLayout bug.

Code Review Task Branch 2677a Revision 10984

It looks good.

Careful look at the test shows the following remaining issues:

I see two other issues to add:

4. The bottom border of the frame is not drawn (this is probably just a side-effect of the size problem).
5. Isn't the "Press space bar to continue." message supposed to be cleared from the status area after you press space?

Constantin: Could the size issues be related to some font difference? I do have all the metrics captured and in the jar as expected. I see the same results as Eugenie.

Task branch 2677a for review updated to revision 10988.

This is the fixes for rectangle wrong size and painting for the rounded one.

Code Review Task Branch 2677a Revision 10988

The changes are good. I like the useful comments you added.

Task branch 2677a for review updated to revision 10991.

This is the frame title height fix. When we have the title in a frame - the using of the frame border is mandatory. The frame title is now has the correct height.

Unfortunately the fix causes the regression in issue #2782 movie-ratings-dynamic.p has scroll bars but 4GL window hasn't. Continue working on resolution. The reason can be more difficult to find than I have expected. There can be the dynamic layout and frame size calculation issue in 2782. Continue working.

Task branch 2677a for review updated to revision 10994.

This is the fix for regression in #2782.

The real issue here is the testcase itself. The button on the bottom is placing manually outside the frame virtual size. This is not intentionally because the new row for widget is set to frame:height-chars - 1. This looks good but in GUI the height of the button is not always 1. So p2j turn on the scrollbars. In 4gl this case is ignoring, the coordinate is not changed if part of the widget become outside the frame. So respective checking was added to the widget's server part location setter in BaseEntity.

Code Review Task Branch 2677a Revision 10991/10994

I'm OK with the changes.

Greg Shah wrote:

4. The bottom border of the frame is not drawn (this is probably just a side-effect of the size problem).

Constantin: Could the size issues be related to some font difference? I do have all the metrics captured and in the jar as expected. I see the same results as Eugenie.

Eugenie, is this still an issue? In 2677a there are some changes done previously to WindowLayout in which if the window is resized via attributes, the new size is set for the workspace; and the window's size must include the decorations, too.

I doubt is related to a font difference.

Eugenie Lyzenko wrote:

Eugenie, is this still an issue?

Yes, still wrong painting. See the picture attached.

This is not a Window issue. The affected widget is a Frame and when the size is calculated dynamically based on the frame content. I think we incorrectly calculate the size of visible part for the ScrollPaneGuiImpl or containers inside while doing the frame layout. This is something like one pixel error may be coming from the fact the coord is 0 based value while size is 1 based value. Or rounding error from char<->pixel transformations. And this is happening when the frame is first showing. Further repainting can dismiss this issue. I think I need to carefully debug Frame.doLayout() code or viewport adjusting that is performing before every frame draw.

Are the width/height-chars/pixels attributes for frame and widgets computed correct in P2J? Does it happen if the frame contains i.e. a fill-in instead of button/rectangle?

Code Review Task Branch 2677a Revision 10999

I'm fine with the changes.

Task branch 2677a rev 11003 resolves the regression in this program. My testing shows everything is working properly now (except for a button highlight issue, for which I will open a separate issue).

Eugenie: do you agree that I can close this task?

Greg Shah wrote:

Task branch 2677a rev 11003 resolves the regression in this program. My testing shows everything is working properly now (except for a button highlight issue, for which I will open a separate issue).

Eugenie: do you agree that I can close this task?

Yes, I do. The original issue has been fixed.