FWD » Core Development » User Interface

See #2707-11 for details.

Put your changes into task branch 1811s.

Quote from the #2707

run simple_sm.p open the second sub-menu and move mouse pointer to it's body and than out of it: you will see, that menu background around the body is drawn as menubar background. There is also some blinking, when moving mouse in the sub-menu body between different menu-items.

This bug is not reproduced at this moment. But the other is founded: when mouse pointer is moved from menu-item outside of the sub-menu body and return back: focus is not returned.

When we press sm1 (it's body become opened) and move mouse pointer to sm2, sm2 body must also must become opened, but it doesn't happen.

Was this working previously?

In regard to your changes in revision 10967, are they safe to include in the trunk?

The changes look OK to me, but I need you to update the history entry for each of the files you changed.

Greg Shah wrote:

When we press sm1 (it's body become opened) and move mouse pointer to sm2, sm2 body must also must become opened, but it doesn't happen.

Was this working previously?

I made that earlier, but after some moment those changes were lost. I.e. "pressed" state didn't transferred at all, I've tried to fix it.

In regard to your changes in revision 10967, are they safe to include in the trunk?

The are safe in regards to other functionality.

Please make the history entry updates that are missing.

Done. revno 10985.

Does PaintPrimitives contain absolute coordinates (x,y) or relative?

I'm recalling, that current problem is the following. Let's remember "pressed" state transfering scenario: 2 sub-menus in a MENUBAR. User opens the first one's body (by mouse click on title) and moves mouse pointer to the second sub-menu's title and that sub-menu's body must be also opened (without explicit mouse click).

This does not occur. There is some drawing affect (have a look at image in the note 5). May be the body is overdrawn. I've debugged it and founded that sub-menu's code drawing the body is called and the code gd.fill3DRect(0, 0, bodyDim.width, bodyDim.height, true); is also called and PaintPrimitives is processed in SwingEmulatedWindow.draw with the body dimensions:

PaintPrimitives.FILL_3D_RECT  x = 0; y = 0; width = 91; height = 46; raised = true

Could you advice me where to look the reason?

Vadim Gindin wrote:

Does PaintPrimitives contain absolute coordinates (x,y) or relative?

Coordinates passed to PaintPrimitives are always relative to the translated origin. So if you want to use absolute coordinates, you must use the drawFromOrigin API.

I'm recalling, that current problem is the following. Let's remember "pressed" state transfering scenario: 2 sub-menus in a MENUBAR. User opens the first one's body (by mouse click on title) and moves mouse pointer to the second sub-menu's title and that sub-menu's body must be also opened (without explicit mouse click).

This does not occur. There is some drawing affect (have a look at image in the note 5). May be the body is overdrawn. I've debugged it and founded that sub-menu's code drawing the body is called and the code gd.fill3DRect(0, 0, bodyDim.width, bodyDim.height, true); is also called and PaintPrimitives is processed in SwingEmulatedWindow.draw with the body dimensions:
[...]

Could you advice me where to look the reason?

Debug the PaintEvent's being raised against the coordinates used during drawing. This usually happens because there is some drawing code which clips the drawing area so that the menu's body is excluded (if you are drawing both the menu's title and the body in the same draw API call). Another reason might be that the body is overwritten by the workspace - if the body is not on top (z-order), then the workspace will draw last and will overwrite the menu's body.

Also, if nothing works, you can debug the PaintEvent's being posted (via some System.out.println code in TitledWindow.processEvent with the event's source and rectangle) and check if there is one posted for the menu's body.

Constantin Asofiei wrote:

Debug the PaintEvent's being raised against the coordinates used during drawing. This usually happens because there is some drawing code which clips the drawing area so that the menu's body is excluded (if you are drawing both the menu's title and the body in the same draw API call). Another reason might be that the body is overwritten by the workspace - if the body is not on top (z-order), then the workspace will draw last and will overwrite the menu's body.

Also, if nothing works, you can debug the PaintEvent's being posted (via some System.out.println code in TitledWindow.processEvent with the event's source and rectangle) and check if there is one posted for the menu's body.

1. Clipping. There are 3 different gd.draw(..) calls: title, body, children and the last calls do not use clipping (clip is null). Could the clipping take place somewhere outside of sub-menu?
2. Z-order. Workspace rectangle is always filled before it's children being drawn, see BorderedPanelGuiImpl.draw().
3. PaintEvent's. There was some inaccuracy, but after I fixed it (just for try if it is the source reason) - nothing changed.

About PaintEvent rectangle.

SubMenuGuiImpl.prepParentLocation() for sub-menu "Smooth operator" adds the height of sub-menu title. It leads to incorrect PaintEvent rectangle during repaint: it's top=69, but it should be about top=48. I.e. for sub-menu in MENUBAR we shouldn't need to increase parent location. I'm not sure if it is correct, but it generates correct PaintEvent after I commented the lines in SubMenuGuiImpl.prepParentLocation():

         int fontHeight = FontManager.getFontHeight(wnd, gf.resolveFontNum(), gd);
         p.y += fontHeight + 5 + 5;  // under the title

Anyway It didn't solve the main problem.

It seems I've solved it. Sorry to trouble. I'll commit it a little later. I'm testing solution at this moment. The reason was related to solution of "blinking" problem. Some logic was moved from mouse* listeners to onFocusGain/onFocusLost listeners to avoid blinking during navigation. And I was forced to add manual FOCUS_GAINED generation to mouseExit to correctly setup flags. I could manually call source.showBody() but it will leads to blinking, that we wanted to avoid. This solved the body showing issue.

Code Review Task Branch 2677a Revision 11010

The changes look good.

It seems that all drawing is happen, but after that window is closed without any pauses or messages. Procedure /uast/menu/popup_ext.p other procedure works as usual. How to debug window closing?

Once again, it is not a configuration/build problem, because simple_sm.p, for example, works as usual. Drawing happen, event processing loop is working, i.e. not finished in ThinClient.waitForWorker(..). BUT: Window is not shown.. By the way Window also has visible=false. Is it OK for default window? If that is the reason, where it must be set? As I'd found, the client side does not support logging configuration. Isn't it?

Vadim Gindin wrote:

Once again, it is not a configuration/build problem, because simple_sm.p, for example, works as usual. Drawing happen, event processing loop is working, i.e. not finished in ThinClient.waitForWorker(..). BUT: Window is not shown.. By the way Window also has visible=false. Is it OK for default window? If that is the reason, where it must be set? As I'd found, the client side does not support logging configuration. Isn't it?

DEFAULT-WINDOW is not-visible by default. Only when some UI statemen targets it (like DISPLAY or MESSAGE), then it is displayed.

I'm looking into your popup_ext.p issue now.

Vadim Gindin wrote:

Once again, it is not a configuration/build problem, because simple_sm.p, for example, works as usual. Drawing happen, event processing loop is working, i.e. not finished in ThinClient.waitForWorker(..). BUT: Window is not shown.. By the way Window also has visible=false. Is it OK for default window? If that is the reason, where it must be set?

Actually, there is a regression related to DEFAULT-WINDOW, introduced by my HIDDEN changes

As I'd found, the client side does not support logging configuration. Isn't it?

Correct. You can use System.err.println to log messages on client-side.

OK, the issue in note 17 is related to repaint calls for the sub-menu. Currently, you are posting a PaintEvent with repaint area equal with the maximum width/height as if all sub-menus are expanded (and this includes space outside of the area actually occupied by a sub-menu). This is not OK. I think is better to post a PaintEvent for each individual expanded sub-menu. I'm thinking something like this in SubMenuGuiImpl.repaint(), so that repaint events are posted only for the rectangles where the sub-menu (and its body) are actually shown:

      if (this.isBodyDisplayed())
      {
         repaint(new Rectangle(bodyLocation(), bodyDimension(), screen().coordinates().baseUnits()));

         for (Widget<O> w : widgets())
         {
            if (w instanceof SubMenu)
            {
               w.repaint();
            }
         }
      }

Constantin Asofiei wrote:

Vadim Gindin wrote:

Once again, it is not a configuration/build problem, because simple_sm.p, for example, works as usual. Drawing happen, event processing loop is working, i.e. not finished in ThinClient.waitForWorker(..). BUT: Window is not shown.. By the way Window also has visible=false. Is it OK for default window? If that is the reason, where it must be set?

Actually, there is a regression related to DEFAULT-WINDOW, introduced by my HIDDEN changes

Is there some fix already (may be temporary)?

Vadim Gindin wrote:

Constantin Asofiei wrote:

Vadim Gindin wrote:

Once again, it is not a configuration/build problem, because simple_sm.p, for example, works as usual. Drawing happen, event processing loop is working, i.e. not finished in ThinClient.waitForWorker(..). BUT: Window is not shown.. By the way Window also has visible=false. Is it OK for default window? If that is the reason, where it must be set?

Actually, there is a regression related to DEFAULT-WINDOW, introduced by my HIDDEN changes

Is there some fix already (may be temporary)?

Add a DEFAULT-WINDOW:VISIBLE = true in your tests, it will solve the problem for now. I'm working on a fix.

Constantin Asofiei wrote:

OK, the issue in note 17 is related to repaint calls for the sub-menu. Currently, you are posting a PaintEvent with repaint area equal with the maximum width/height as if all sub-menus are expanded (and this includes space outside of the area actually occupied by a sub-menu). This is not OK. I think is better to post a PaintEvent for each individual expanded sub-menu. I'm thinking something like this in SubMenuGuiImpl.repaint(), so that repaint events are posted only for the rectangles where the sub-menu (and its body) are actually shown:
[...]

1. Note that this bug is related for pop-up menu only. When MENUBAR with sub-menus is used, there is not such error.
2. I could be wrong, but I remember that resulting invalidation rectangle is an intersection of rectangles of all child widgets in a hierarchy. So that can broke all repainting. Isn't it? You wrote about something like that in the task #1790 notes 189,409,428. Please have a look.

Vadim Gindin wrote:

Constantin Asofiei wrote:

OK, the issue in note 17 is related to repaint calls for the sub-menu. Currently, you are posting a PaintEvent with repaint area equal with the maximum width/height as if all sub-menus are expanded (and this includes space outside of the area actually occupied by a sub-menu). This is not OK. I think is better to post a PaintEvent for each individual expanded sub-menu. I'm thinking something like this in SubMenuGuiImpl.repaint(), so that repaint events are posted only for the rectangles where the sub-menu (and its body) are actually shown:
[...]

1. Note that this bug is related for pop-up menu only. When MENUBAR with sub-menus is used, there is not such error.
2. I could be wrong, but I remember that resulting invalidation rectangle is an intersection of rectangles of all child widgets in a hierarchy. So that can broke all repainting. Isn't it? You wrote about something like that in the task #1790 notes 189,409,428. Please have a look.

I think this is really an issue of posting a too "aggressive" repaint rectangle. When focus is lost from a sub-menu, a PaintEvent is posted which uses the smallest rectangle as if all sub-menus are expanded. Look how AbstractContainer.getDrawableWidgets works: it goes through all widgets, in z-order, from top to bottom, and stops when all the invalidation rectangles are "consumed". So, as the MENU is higher on z-order than the WindowWorkspace, the MENU's boundaries (which is, again, the smallest rectangle including all sub-menus expanded) will match the only posted rectangle in the ScreenBitmap: so all "invalidation rectangles" are consumed when the MENU is found, and the WindowWorkspace widget never gets repainted - as it is below the MENU.

The idea here is, if a rectangle is posted to ScreenBitmap, is assumed that the entire area needs to be drawn by the widget - ScreenBitmap can not use "transparent" rectangles, as these make no sense. So that's why you get an incorrectly drawn area when focus is lost: the workspace (which is below the MENU) never gets a chance to repaint, as the P2J internal drawing mechanism assumes that if a widget posted a rectangle to be repainted, then that widget is responsible of fully drawing that area, if the widget is the topmost widget.

1. a PaintEvent is posted with the sub-menu's title
2. a PaintEvent is posted with the sub-menu's body, if it's expanded

Constantin, thank you for help! Just one question. How about BorderedPanelGuiImpl? I recall that mentioned erroneous rectangle is drawn from there: BorderedPanelGuiImpl.draw(..) without throwing PaintEvent and using straight call gd.fillRect(...).

P.S. I'm trying to implement your proposals and fixing arising bugs at this moment.