API breaking consistency fixes intended for CEGUI 0.8.0

[Jamarr]

I do not agree with unifying being equivalent to bastardizing; it has such negative connotations and implies unification as being hackish. Would it require work to unify the schemes, such that the skin (eg: the imagery) and font need to be uniform - of course. You would certainly have to make some compromises, but such is the case when unifying anything. However it would also simplify maintenance (imo), allow for easier skinning, and allow easy extension / adding of widgets to all default schemes. If that is too difficult / time consuming, it can always be broken down into steps / pieces - we not rewriting the system, merely extending it.

I wonder how users currently manage multiple skins and widgets? And do they generally try to create vastly different widget-architectures (eg looknfeel) or do they generally favor using the same architecture, with a different skin (eg imagery)? I would imagine the effort / cost of having different architectures is far too great, and thus rare; this is generally left to the modding communities. It is far easier to paint something, than it is to re-architect. So even if you do not want to unify the imagery for the default-schemes, it may still be beneficial to extend the current system as previously outlined to allow it. It may also open up the door for users to contribute additional skins for some of the default schemes.

[CrazyEddie]

Ok, to update here a little...

It is our intention to issue a 0.8.0 release this coming January. Yes, that was quick! However, it will not contain all the stuff discussed for that release This is not actually bad news though. Basically, we want to move away from the existing situation with having three build systems to maintain, and so will be switching to CMake as soon as possible, and this requires a release a bit more substantial than a stable 'patch' release, so 0.8.0 gets moved forwards.

What this means for the things being discussed here is that some will go into 0.8.0 and others will get bumped to 0.9.0 (or other future releases). Basically, since the move to time based patch releases, I feel less restricted by all things feature based, and am quite happy to make 0.x.0 releases more often as our needs dictate.

Also, be aware that since cegui_mk2/trunk has now become our main focus, the code in there is going to break, and any guys using it would be advised to either side-step to cegui_mk2/branches/v0-7 if possible, or be prepared to make lots of fixes to your code over the coming weeks

CE.

[Mikademus]

I think the contents of this thread (Just went looney with "MouseEnter" and "MouseLeave"...) perhaps should be mentioned here since it involved backward-breaking fixes intended for the 0.8 branch.

I have to agree with emarcotte in that you should try to automate bindings; preferably by generating them from the original source. That said, with v0.7 recently released and already including some non-backwards compatible changes it might be a good idea to go ahead and clean up the consistency issues between the variable and string-literal names.

This is actually a really hard call I don't think it's something we can contemplate in the v0-7 branch as it's supposed to be API stable, so that makes it a trunk 0.8.0 type of a change.

In general we've been reasonably well behaved as far as trying to maintain backwards compatibility with scripts and xml data files, though obviously I'm not going to say that 100% compatibility has been maintained. I mention scripts and data files because in making this change I'd want to change the strings to match the symbols rather than the 'easy' option of doing it the other way around.

There are other places that need to be sorted out too. One that comes to mind is the misspelling of caret as carat.

I think if we could gather all these inconsistencies and errors together somewhere to be collected and discussed, it would then be possible to get those changes in for the 0.8.0 release in one go and we can move to a more consistent and stable API.

CE

[uelkfr]

Small note:

Code: Select all

#ifndef _CEGUIImageset_xmlHandler_h_
#define _CEGUIImageset_xmlHandler_h_

#include "CEGUIXMLHandler.h"
#include "CEGUIString.h"

...

    //! Return reference to the created Imageset object.
    Imageset& getObject() const;


Need to add #include "CEGUIImageset.h" or predefine class Imageset.
Currently is looks like this CEGUIXMLHandler.h -> CEGUIBase.h -> CEGUIForwardRefs.h -> class Imageset;

[Kulik]

uelkfr: I don't get what you mean, Imageset gets forward declared in the CEGUIForwardRefs.h.

[Hanmac]

and the ImageManager has no iterator for the images and the types
same there with the RendererEffectManager or other manager wich has add<T>
i need a function wich returns a list of types

PS: the binding would only work with 0.7.5 to make it work with 0.8 i need very more work