FWD » Core Development » User Interface

When focus is switching between overlapped widgets inside the same frame (these widgets may be a nested frame, too), in ChUI the widget/nested frame reflecting the new focus is brought on top, in z-order. In GUI, the z-order does not get changed.

See uast/frame-z-order/nested-frames.p

The issues in nested_frames.p are not exactly z-order related. The problem is with explicit widget drawing, when there are stacked widgets, on the same location, and the widget is not the one on top (there are other widgets intersecting it). Code like this, in ThinClient.processEventsWorker:15166:

                     src.draw();
                     src.requestSync();

I think the solution is to add a clipping rectangle to the driver, with only the widget's visible part.

No, adding a clipping rectangle with only the widget's visible part will not work - as the visible part may not be a rectangle at all!

So, the approach is this: all direct drawing in ThinClient is replaced with eventDrawingBracket and repaint() calls, with widgetDrawingOn() and widgetDrawingOff() APIs being obsolete (thus removed).

This fixes nested-frames.p, I'm testing the GUI screen now. If the screen is OK, next I will commit these changes and start a runtime testing.

Code Review Task Branch 2677b Revision 10966

The changes are good. The resulting code is much cleaner. Hopefully the regression testing will not find any issues.

The changes exposed an existing issue in Frame.drawDownFrame: frameScroll.minimumSize reports incorrect height; instead, frameScroll.getScrollableSize needs to be used.

2677b rev 10968 fixes the regression in note 7. Runtime testing is in progress again.

Runtime testing passed with only false negatives (I assume). I'm running main part again to confirm.

Second run has only a common failure: GSO 17's gso_17.sum report has an extra row... I'm inclined to assume is a false negative, I don't see how my changes can impact this.