features before the 0.3.0 release

[granx]

Hi,
I just wanted to put in a plug for a feature that would really help me if it was added prior to the next release.
plug

Lindquist, if you already got this into the CVS, I apologize for missing it.

Thanks all!

[CrazyEddie]

It's unlikely that any new features will be added for the 0.3.0 release; I believe this release will happen within 5 days or so, and this is not enough time to add new features, test them properly, and package things up. Personally, I like to let features exist in CVS for a while before they get put into a 'stable' release, so that they have some testing in the field - otherwise it may not be much of a stable release

With reference to the requested feature, for my part, I feel that there is enough facility to achieve what you want already (as we already suggested in that thread). I'll just repeat that I would not feel comfortable having something like this in CEGUIBase - there are many different approaches to binding to code via the data files, and I do think that each person needs to choose the best technique for their app, rather than trying to use something we provide (no matter what you put in, someone always complains ).

The code to achieve what you want is extremely simple:

You need a std::map of function pointers keyed by a string containing the handler name you'll use in the XML files.

Now create a dummy script module which implements the

Code: Select all

executeScriptedEventHandler(const String& handler_name, const EventArgs& e)

method (the other methods can just be stubbed out). Within this method you just look up the handler_name in your std::map and call the corresponding function, passing the EventArgs as required.

In your layouts, use the <Event> tag to specify which events you want bound to which handlers.

CE

[granx]

I will give this a try when I have more time tonight, but I heard a rumor that an "install" of the CEGUI package will copy the headers into $(INSTALL_DIR)/CEGUI/ . Is this correct? I hope you'll tell me 'no' since the cegui_mk2/include is where the headers are located rather than cegui_mk2/include/CEGUI/ . I'm sure you can appreciate that this would cause some development headaches if it were true. Also, why are the headers not under cegui_mk2/include/CEGUI/ in the CVS repository?

Thanks again for the great library. I hope to test the scripting module support soon, and I hope to use those hooks from the layout editor application too (assuming I can add this support if it isn't already existing in the editor). I am happy to use it and I am trying to increase its popularity among my peers. Later-

[_mental_]

If you use Linux it's actually $(prefix)/include/CEGUI where $(prefix) defaults to /usr/local.

Also there isn't really any reason why the headers should live under cegui_mk2/include/CEGUI in CVS since it all gets sorted out at install time.

[granx]

Well, my (albeit picky) reasons would include having to append the include path search list for an *installed* project. When a package is installed into /usr/local/include, then I get to write code that says #include <gl/gl.h> (just an example), without appending the search path. But for CEGUI, I write code that says #include <CEGUI.h>, and even though it is installed, I have to be smart and ask my client code to append its search path to include /usr/local/include/CEGUI. I really don't mean to be too picky, but it seems like something easy to over come by modifying the CEGUI source and/or source tree in CVS.

However, given the limitations of CVS for changing a directory structure, I understand the "other opinion" You'll lose history if you do that. I just thought it would be nice to write code that says #include <CEGUI/CEGUI.h> whether I am developing against the CVS or an installed version.

I've made my peace. Cheers.

[_mental_]

I'm not sure I follow. When you have CEGUI installed, you can use includes like #include <CEGUI/CEGUI.h>.

[granx]

Hi _mental_,
You are right about me being able to write code that says #include <CEGUI/CEGUI.h> after CEGUI has been installed, but I see 2 things wrong with that:

1) I still have to append my include search path to have /usr/local/include/CEGUI - AND MORE IMPORTANTLY - I have to ask client code to *also* append their search path to use /usr/local/include/CEGUI. I don't really care about this extra step for myself, because I will do this, move on, and be happy. However, I don't enjoy adding extra steps for build environment for *client* code, and this is the only project I use where I can't get around this issue. CEGUI headers are not written to #include <CEGUI/xxxx.h>, so the search path must be appended, *even when it is installed*.

2) I can't develop from the CVS with code that says #include <CEGUI/CEGUI.h> unless I make a symbolic link like:
cegui_mk2/include/CEGUI->/cegui_mk2/include
I see this as a deterent for interested and talented developers which might, on occasion, have been happy to add some new widgets or other fun stuff.

I'm feel really bad now for making this comment. It sounds more like I am ranting now, and I don't care to do that. You're project is great, I am enjoying learning how to use it (aside from my other imbisile usage errors which I am still sorting out). I only brought this point up because I think it would help the project.

As I see it, the fix is this:
#1 mkdir cegui_mk2/include/CEGUI
#2 cvs add cegui_mk2/include/CEGUI
#3 mv cegui_mk2/include/*.h cegui_mk2/include/CEGUI
#4 change ALL CEGUI source files to use #include <CEGUI/xxx.h>
#5 cvs add cegui_mk2/include/CEGUI/*.h
#6 cvs update&commit

I am laughing at myself for writing this, because I doubt any CVS _boss_ will care to do step #4. That is what I think the project needs, just so 1) and 2) are resolved. Maybe there are other reasons for it too. Good day.

[CrazyEddie]

We provide pkg-config support to bring in the required include and lib paths on *nix style (and similar) systems; this is the preferred way the library should be accessed on those systems, as is the case with many, many other libraries (relying on anything else, without manually adding search paths, is little more than a hack; since you don't know for sure where things were installed (in the case of a user supplied prefix for example).

Having said this, you're on MacOS which kind of 'hides' most of the internals of the underlying system which is unfortunate because it makes us look bad

In cases such as this, I think that adding a single entry to your include seach path is of little consequence and is no more than is required for users on MS Windows based platforms - so at least you're not alone

As such I see no need for any changes to be made - it would be a lot of bother for not much gained. In addition, it likely breaks everything for anybody who already took the trouble to set up their environments.

CE.