Window Inner rect usage is inconsistent and/or incorrect

Create issue
Issue #260 resolved
Paul Turner created an issue

The concept of the 'inner rect' for CEGUI::Window was to allow a means to easily specify an area inside window decorations for rendering and other content (for example the 'client area' of a frame window). The current situation is as follows: - Currently, the positioning and relative sizing are done based off of the main window area - this is incorrect and it should be changed to use the inner rect, with an option to override where appropriate. This change would eliminate all of the positioning issues and stop content disappearing under the title bar of a frame window and so on. - Imagery clipping is already done according to the inner rect, but... - For most cases the main window rect and the inner rect currently describe the same thing. Or put another way, widgets are not making correct use of inner rect (largely because there is no good mechanism to do so)

To address these issues in a way that's flexible enough to be useful, we're looking at the following basic changes: - Add an option to CEGUI::Window to specify whether child positioning / sizing use the main window area or the inner rect area. - Modify the child positioning / sizing calculations done by CEGUI::Window to use the inner rect area and reverting to the main window area where specified by the above option. - Create a default means of accessing an inner rect from within a LookNFeel where one is assigned. This should defer to an assigned WindowRenderer where appropriate. The default implementation could basically be looking for a named area "inner_rect" to use, reverting to the current behaviour if no such area is defined or if no LookNFeel is assigned. - Update the Falagard window renderers, where appropriate, to provide custom inner rect areas. These would generally use existing areas required within the assigned LookNFeel. The idea of this is to be used for example where some widgets' inner rect is not fixed and so a single named area is not appropriate - things like widgets with scroll bars, and also frame window, where the actual inner rect area depends upon the configuration of the widget.

Reproducibility: always

Comments (2)

  1. Paul Turner reporter

    I've attached "v0-6-clientarea-fix.patch".

    The patch addresses the first two points above, and also the fourth point so far as was necessary to have the widgets working in a reasonable fashion.

    The resolution to the third point, and the completion of the fourth point work will continue at a later time.

    This fix will NOT be making it into v0-6 branch for two main reasons: 1) It breaks the binary interface in a huge way, which we're trying to avoid on the stable branch. 2) All existing layouts using FrameWindow (and maybe other windows too) will need to be fixed in order to account for the fact that (0,0) is now within the client area and not somewhere behind the titlebar.

    Other things to also note with this patch are:

    • CoordConverter now takes into account the effects of the inner rect in it's calculations.
    • Inner rect is now more than just about clipping, so any hacks in place using inner rect tricks (like the ones CEGUI used to have) will probably be broken when using this patch.
  2. Paul Turner reporter

    trunk @ rev. 2127.

    For the inner rect / client area of all Window based objects added the usage of default 'inner_rect' named area, where present and where not overridden by a more specialised WindowRenderer.

    There are still outstanding fixes needed due to these changes, though all should be done for the final 0.7.0 release.

  3. Log in to comment