Making cegui more mobile - oriented.

[CrazyEddie]

I got that impression from here (in your FAQ)

Ah, right, that Well, that was a decision taken long before the iPhone even existed, and is in reference to when the Ogre project was offering a paid, closed source licensing option. Since we had / have no interest in going down that same route, we chose instead to make our license even more permissive, such that it could be used on proprietary / closed systems, which the LGPL would have prevented. That change is in no way related to Ogre's most recent licensing change to MIT. That FAQ is out dated and will be replaced with a more useful FAQ that will form part of the main CEGUI documentation - I have this work started and hopefully will complete it when I return next month.

With regards to why you posted, I totally understand that It was me, either in this thread, or another one on a similar topic, who said that people should voice their support in order that this might work might get done - and I stand by that. The more people who want something to happen, the more likely it is to (eventually) get done. As far as this goes, I thank you for your +1 in support for the idea as I have done for others

The last paragraph in my previous post was a general statement to all who may read this, rather than being directed at any one individual (or in reply to your post alone). As is this one too I understand that most people who are using (or thinking of using) CEGUI are likely knee deep in stuff that they themselves have to get done, and perhaps do not have time or resources to commit a lot of effort to contributing code to CEGUI. I will say two things in response to that: first, it can't be that important to any of you that the work be done then and second, if necessary, it is definitely something that I will get to myself, though it is likely to take a long time. Currently my focus is on the Skin Editor, which is essentially a TODO from 2005 / 2006 or so - given that amount of 'lag', you might expect me to get started on the iPhone / mobile support around 2014

CE

PS. I know my posts tend to come over very dryly, though in general, things are meant in a light hearted way. So take this post in that way

[ShiftZ]

So, where did we stopped?

(multitouch)
Any advancement in that field? I afraid only thing i where i cannot help you is "mulitouching" implementation, or way to fake it.
What else do we need?
Ah, alittlebit of light weightness. I was stuned abit by the size of compiled cegui debug lib. But cannot say exactly how much it will weight inluded in iPhone binary, yet.

As far as i remember there also was a little issue to use pvrtc\any compressed textures in render.

PS What was that about "OpenGL ES lacks build system" on page 2?

[CrazyEddie]

No progress has been made due to lack of time, inspiration and motivation The only work that gets done on CEGUI at the moment is maintenance on the stable branch, and work on the upcoming skin editor. So all the issues / TODOs are still as they were.

With reference to the build system, I mean I have not yet added any build support, so the GLES renderer and associated image codec are not included in the autotools build, are not part of the Xcode project and no MSVC++ projects are generated by premake. I've yet to make decisions about how I want this to be done, like from a dependency standpoint and what have you. However, the code is in, and if people roll their own project / build support, it does compile and does work

CE.

[ShiftZ]

Hi,
Trunk version still cannot be compiled without pcre even with commented #define CEGUI_HAS_PCRE_REGEX.

CEGUIPCRERegexMatcher.h:

#ifdef CEGUI_HAS_PCRE_REGEX
# include <pcre.h>
#else
typedef void pcre;
#endif

this allowed me to compile.

And about FreeType2.
Why not to give an alternative way, i.e. prerender font sheets by a little font rendering tool instead of rendering it in runtime?
I found FreeType2 too heavy, ugly and full of sh*t. I really hate it. Is there a way to skip it?

[CrazyEddie]

Well, the option for PCRE does work with linux and with premake generated solutions on MSVC++. The Xcode situation is a bit different IIRC. The correct way to handle that at the moment is to exclude the PCRE related code file. Conditionals that rely on the content of CEGUIConfig.h / config.h may not go into header files at the moment, though controlling an entire source file that way would be fine. Hopefully at some stage I'll get around to addressing the situation as far as config.h goes and re-unify the settings back into CEGUIConfig.h for all build platforms.

There is already a setting to disable the use of freetype2, "CEGUI_HAS_FREETYPE". The situation there is similar as it is for PCRE - you need to exclude the CEGUIFreeTypeFont.cpp source file from the build. This leaves you with Pixmap type fonts which can be hand constructed or made with tools such as the Font Studio bitmap font generator which can export to CEGUI format.

CE.

[ShiftZ]

CEGUIEditBox.cpp has "#include "CEGUIPCRERegexMatcher.h" without any statement checking. And CEGUIPCRERegexMatcher.h has pcre identifier same without any statement checking. Maybe i missed something. Do i need to exclude CEGUIEditBox.cpp ?
I added checking in CEGUIPCRERegexMatcher.h like in my post above.

[CrazyEddie]

I had a quick look, and it's a mistake It shouldn't cause anything to get compiled in, but obviously if pcre is not there then that causes issues regardless

CE

[ShiftZ]

My damn Apple Developer Account expired, so i compiled release under win32. Size of executable binary increased from 0.34 Mb to 2.04 Mb. O_O
Using /Os flag cut it to 1.5Mb.

Can i exclude heavy weighted elements like MultiColumnList or FalMultiLineEditbox ?

[CrazyEddie]

There are no ready made options for that, but you can easily omit the code for those types (and remove factory registration from System), if you wish to. I'm not sure what difference it will really have. CEGUI does have a large footprint. If you wish to call it bloat, feel free to do so

CE.