CEGUI (Crazy Eddie's GUI) Forums

I apologize for bad English
I would like to have advanced build settings
such as:
disabling the use of external libraries ( #define CEGUI_NO_USE_FREETYPE )
disabling the use of components of default ( CEGUI_NO_USE_DEFAULT_LOGGER, CEGUI_NO_USE_DEFAULT_... )
disabling of a mechanism of exceptions ( CEGUI_NO_USE_EXCEPTIONS )
I think it should be able to collect full library does not use the services OS
proposed development:

and usage:

Hi,

Some build options are already available and are set in the config.lua file (there are no plans to return to manually editing a header to set build options).

I think some extended build options are a possibility, I would like to have options that allow the build to be streamlined (meaning if you're only using buttons and sliders, you can exclude all the other stuff).

With regards to the use of default objects, these can already be overridden to use a user supplied preference in most cases, although in the case of the logger, for example. the code is still compiled into CEGUIBase (there is no plan to change this, we do not want people easily building with no logger - it's hard enough to get people to post log content as it is ).

I think Freetype will always be a dependency - unless you want a GUI with no text. I've pondered the possibility of allowing PCRE to be optional - disabling some APIs and widgets in response. All other external libraries are already optional.

There are currently no plans to 'optionalise' the use of exceptions. The exceptions are also used internally in a couple of cases and having a user supplied 'catch-all' function be used instead is not something that I like.

Thanks for the suggestions though

CE.

CrazyEddie wrote:Hi,
Some build options are already available and are set in the config.lua file (there are no plans to return to manually editing a header to set build options).

I think you mean config.h
Of course I started with him

CrazyEddie wrote:With regards to the use of default objects, these can already be overridden to use a user supplied preference in most cases, although in the case of the logger, for example. the code is still compiled into CEGUIBase (there is no plan to change this, we do not want people easily building with no logger - it's hard enough to get people to post log content as it is ).

You discard the use of the library on systems not in the file system example

CrazyEddie wrote:I think Freetype will always be a dependency - unless you want a GUI with no text.

In most cases, quite often even preferred to have finished prerenderered raster fonts than to generate them in the boot

CrazyEddie wrote:There are currently no plans to 'optionalise' the use of exceptions. The exceptions are also used internally in a couple of cases and having a user supplied 'catch-all' function be used instead is not something that I like.

I can only repeat about a platform other than PC.
and in general we are talking about the games development?
Any errors should be identified at the debugging phase.

CrazyEddie wrote:Thanks for the suggestions though

I hope for your understanding. And I wish to resist the temptation to make a "thing in itself" and continue the main line project.

Hi,

Thanks for clarifying some of the reasoning behind the requests you made. Based on your reasoning I'm willing to change my mind on most of these points.

I think you mean config.h

Well, not entirely. That file is intended to be actually created by whatever build system is in use - either by running a configure script, or by setting options in config.lua and running premake. Since your platform is obviously different to what we usually consider, the means by which this file would be generated could be different entirely.

CrazyEddie wrote:I think Freetype will always be a dependency - unless you want a GUI with no text.

In most cases, quite often even preferred to have finished prerenderered raster fonts than to generate them in the boot

Yes, I must definitely cede this point I did not consider a scenario exclusively using pre-rendered fonts/texts, and in such a situation it can indeed be that Freetype can be omitted.

CrazyEddie wrote:With regards to the use of default objects, these can already be overridden to use a user supplied preference in most cases, although in the case of the logger, for example. the code is still compiled into CEGUIBase (there is no plan to change this, we do not want people easily building with no logger - it's hard enough to get people to post log content as it is ).

You discard the use of the library on systems not in the file system example

Note I did say we do not want people easily doing this. For the more advanced / experienced developer, it's currently entirely possible to create a 'NULL' logger to be used as the default that does not create a file and just discards logged lines, thus alleviating the need to write to a filesystem. Perhaps we should actually provide an option to switch the default logger over to such a model?

CrazyEddie wrote:There are currently no plans to 'optionalise' the use of exceptions. The exceptions are also used internally in a couple of cases and having a user supplied 'catch-all' function be used instead is not something that I like.

I can only repeat about a platform other than PC.

Yeah, you're right of course. It's very easy for people working exclusively on PC based platforms to become blind to the existence of other types of platform. I need to consider this one very carefully, for various reasons.

Any errors should be identified at the debugging phase.

I agree. Exceptions are not errors in the 'bug' sense. Exceptions are things that happen in exceptional circumstances - things that are unforeseen - you cannot debug for the unknown. However in this context the point is pretty much not relevant to the larger discussion.

I will add a set of tickets to Mantis over the next day or so for these items.

Thanks again for raising the potential changes, and also for subsequently explaining the "why" for a dumb PC guy

CE

. For the more advanced / experienced developer, it's currently entirely possible to create a 'NULL' logger to be used as the default that does not create a file and just discards logged lines, thus alleviating the need to write to a filesystem. Perhaps we should actually provide an option to switch the default logger over to such a model?

I do not propose to turn off logging. I propose to provide an opportunity to remove buildings in default logger in binary if it is unnecessary
"I should not pay for something that does not use"

Thanks again for raising the potential changes, and also for subsequently explaining the "why" for a dumb PC guy

at the divide, I also work with the PC.
I simply can easily lead to an argument other platforms than to explain why the game developers do not use exceptions.

propose to consider such an option:
make all default things in a library, say libCEGUIDefaults

Hi,

I'm not in favour of a new lib to contain the default objects - especially as this would basically just be the logger. However I am willing to investigate possibilities to replace the default with something else.

Since I do not want the solution to end up having to check for the existence of a logger all the time - since I want some kind of logger to exist always - I think a solution involving templates would be nice and clean and also eliminate the existing default logger code when it's not used because the client code provides its own.

I'll get to adding the mantis tickets for these items shortly, I could not do it yet since I have been unwell

CE.

I have added tickets on mantis for these requests:
http://www.cegui.org.uk/mantis/view.php?id=240
http://www.cegui.org.uk/mantis/view.php?id=241
http://www.cegui.org.uk/mantis/view.php?id=242
http://www.cegui.org.uk/mantis/view.php?id=243

They'll almost certainly be 0.7.0 things, though you never know

CE.

With regards to eliminating exceptions...

I am uncertain as to the usefulness of calling a client function in place of the exception. I think the only really valid use is to to output a message and terminate the app - certainly returning from this "exception" function would be completely out of the question (and would be protected against within CEGUI).

If you - or anyone - could perhaps elaborate a little more on the kinds of things this function might do, and how it would be useful, that would be most helpful.

CE.

I could understand a wish for having return values instead of exceptions, but calling some error handler function also has your application jump out from the current context, so i don't see much differences with using exceptions here.

I kind of get the sense that the OP was trying to minimise size by eliminating exceptions.

Having looked some more at CEGUI internal code, there are various places where we catch exceptions and recover / retry - having a client function called in these cases is obviously a non-starter.

I'm really leaning towards abandoning this particular idea. CEGUI (Mk2) was designed intentionally to use exceptions from the very start; they're a fundamental part of the design. CEGUI is written in C++, exceptions are a part of C++; it's not like an external dependency library or something - it's almost like being asked to remove our use of the for loop (which incidentally, would be much easier to do ).

CE.

CrazyEddie wrote:I kind of get the sense that the OP was trying to minimise size by eliminating exceptions.

Having looked some more at CEGUI internal code, there are various places where we catch exceptions and recover / retry - having a client function called in these cases is obviously a non-starter.

I'm really leaning towards abandoning this particular idea. CEGUI (Mk2) was designed intentionally to use exceptions from the very start; they're a fundamental part of the design. CEGUI is written in C++, exceptions are a part of C++; it's not like an external dependency library or something - it's almost like being asked to remove our use of the for loop (which incidentally, would be much easier to do ).

CE.

I propose to introduce only macros are similar to the in first post. To me, they did not cut the functionality of the library
if you need it, it is only override these macros not edit the all files in library

AndryBlack wrote:I propose to introduce only macros are similar to the in first post.

Yeah, I understand that. My question with regards to this is that within CEGUI we catch some exceptions ourselves, recover and continue executing (one example of this is in the Xerces initialisation of the schema files), if these exception catches - that normally result in a logged error but an otherwise successful run - are replaced with a call to a client function, what happens?

CrazyEddie wrote:

AndryBlack wrote:I propose to introduce only macros are similar to the in first post.

Yeah, I understand that. My question with regards to this is that within CEGUI we catch some exceptions ourselves, recover and continue executing (one example of this is in the Xerces initialisation of the schema files), if these exception catches - that normally result in a logged error but an otherwise successful run - are replaced with a call to a client function, what happens?

If the user to override the behavior of these macros, a further full responsibility for the conduct of it, you should not worry about it. You can agree, for example, that CEGUI_THROW no returns in this case.

Hi,

Thanks for the continued discussion

Myself and Scriptkid will discuss this and make a decision one way or the other.

If anyone has any other input in the mean time, please feel free to post it here.

CE.