Theme disrupted in 0.7.0

[Armitage1982]

Hi

I'm using a BlitzMax version of CEGUI 0.7.0.
The module is currently upgrading from 0.6.2 to 0.7.0 and all the new features aren't implemented yet.

I'm using OpenGl and a modified version of the Aqua Skin.

Does someone already experienced this by upgrading to 0.7.0?


Title bars aren't correctly placed in FrameWindow (de-structuring the whole content of windows vertically) and tabControl get additional horizontal border space (crushing all the content of the Frame horizontally).

• About the horizontal border space could it be that bug : viewtopic.php?f=10&t=4365 ?

• About the title bar it can of course come from the "alpha" version of the wrapper or maybe do I have to modify the Looknfeel or Layout because of the new TextFormating Falagard rules ?

• Does someone could try this skin with 0.7.0 (no SVN version)?
  http://www.mprazak.info/AquaLook/

• Also my CEGUI.log bring this new error :
  

  Code: Select all

  (Error)   CEGUI::UnknownObjectException in file C:/BlitzMax/mod/bah.mod/cegui.mod/cegui/src/falagard/CEGUIFalWidgetLookFeel.cpp(60) : WidgetLookFeel::getImagerySection - unknown imagery section 'select_mark' in look 'AquaLook/Checkbox'.

• Is there many problems with the current version ?
  I read here and there that a new 0.7.1 must fix a lot of things.
  I'd like to know this because my project is nearly done and I need it for a contest by the end of this month.
  So if there is a lot of issues I may preferably stick to 0.6.2.
  I'd like to use the 0.7.0 version mainly for the text [Tag] (except if there is some cool new features I probably miss).

Thanks a lot for your time

[Armitage1982]

The last SVN trunk as been committed to the module without any success for this problem.

Then I suppose it's not related to the first point of my subject.

If anyone could try the AquaLook with 0.7.0 or the last SVN that would be great thanks !

[CrazyEddie]

Hi,

First I'd advise switching to v0-7 branch over the main trunk, since fixes will be made there first (and only get merged back to trunk on a rough weekly schedule).

I believe the issues you are seeing are related to the 'inner rect' fixes made for 0.7.0. This fixes various issues in previous versions and ensures that normal child content is positioned and sized correctly according to the inner-rect/client-rect/content area of windows rather than being based off of the entire window area. The change means that (as you suspect) the looknfeel needs to be updated, and basically it entails updating Child component definitions for content that should appear as part of the window frame/chrome/system/non-client areas and all you have to do is set the property "NonClient" to "True".

HTH

CE.

[Armitage1982]

Thanks a lot for this support CE !

I have located 5 childs that need NonClient property in the AquaLook Theme
Two for titlebar and close button childs in the FrameWindow
One in the Titlebar WidgetLook itself.
Two for the HorizontalScrollbar and VerticalScrollbar childs in the ScrollablePane
(TaharezLook as Two more for the HorizontalScrollbar and VerticalScrollbar childs in the ItemListbox, not present in AquaLook)

After that the titlebars and the scrollbars appears to be OK.

But unfortunately since the 'inner rect' size change I think I have to change the size of every widgets now.
More important : there is still no layout editor with 0.7.x CEGUI out there
Impossible to precisely edit the inner content of a window inside the 0.6.x CELayoutEditor.
(Plus I do remember that the last one was kinda buggy, miss to save some important parameters).


See what I mean ?
I can't find any other NonClient child in regard to that frameWindow Area
I think it's about the DefaultWindow but I can't set any property for that in my looknfeel.

[CrazyEddie]

Hi again,

Yes, this change will have affected the positioning of all content and the sizing of content with relative components. Obviously we do not make these kinds of changes - those that mess with people's existing layouts - for fun, though I'm sure you'll agree that sometimes such things are a neccessary evil in order to keep progressing forwards.

The way I see it, there are a couple of options open to you; the first is to set all your content to have the NonClient property at True - this will restore the previous positioning and sizing, although be aware that this will also affect the way the content is clipped (it will be clipped to the outside of the frame not the inside), and perhaps z-ordering involving titlebars and scrollbars (which can possibly be additionally worked-around by setting those items to always on top). If these limitations are acceptable, then this solution is the easiest way to go.

The second option is obviously to update all the content - since you say you have so much of it, for this I would recommend some kind of script or utility to automate the process.

CE.

[Armitage1982]

Thanks to the new Layout Editor I'm now able to see more precisely where is the problem in my looknfeel.


It seems that the client area of my FrameWindow contains some kind of inner edge.
I suspect that if I could solve this little problem my looknfeel would be OK.

I suppose that it's what you were talking about with the clipping area CE, I'm currently trying to change the area code but don't know if it's the right solution (LeftEdge, TopEdge, RightEdge, BottomEdge).

In case anyone has an idea I provide a link to the looknfeel : http://www.mediafire.com/?jmzlfm5njiz
The problem probably reside inside AquaLook/FrameWindow

Thanks

[Armitage1982]

Haw... forget about that.
I Just figure out (again) that I had to change the position of each window.
A script could help but not in my case since I mix relative and absolute position everywhere !
Why WHY didn't I grouped every set of gadgets at the very beginning ^^

Ho well, I have some free time today to harness myself to that.
In regard to the FPS slow down (if you remember well ) Do you think it would rather come from the BlitzMax Wrapper, The BlitzMax OpenGl Driver or did you find anything new in this area ?

Thanks

[CrazyEddie]

The analysis as far as the performance issue goes currently remains the same; something is short-circuiting the caching facilities within CEGUI causing the performance hit. I need somebody to provide some kind of test code that demonstrates the issue before I can change this conclusion (or in other words, I have not been able to reproduce the results - the results I've had have been reasonably comparable to the native C++ code, with no slow down / hits).

CE.