0.5.0

[Dalfy]

0.5 will not be available until a complete move to MIT. This includes some rewrites of the code for non written by Crazy Eddies parts which we do not get the authorization (most of the time no answer) from contributors.

There is no release date planed at the moment but the initial date was april the 1st so it should not be in a so long time


Any try of the code in subversion repository is well apreciate as well as comments on the forum or on irc but not in mantis bug tracker. The code in the repository is really not far from what you should get in the release.

[Sneftel]

Unfortunately, I can't even compile SVN head right now. The dependencies package for 0.4.1 is insufficient to compile, and the updated dependencies package mentioned here doesn't work properly with VC++ 2005 (it references VC7 libraries).

[Dalfy]

The dependencies are quite low, It consists in PCRE which should be easy to compile and it's a good thing to start compiling dependencies and other thing cause there is no plan to provide binary for 0.5. There has been binary distribution for 0.4.1 cause it was a last release before a lot of rewrite and a long time without release. But we don't think at providing binary distribution for 0.5 at the moment. It can change later but it's not in our todo list.

[Sneftel]

I have to say, I'm rather surprised to hear there aren't plans to offer binaries nor binary dependencies. I just finished compiling CEGUI from scratch, and it is not a process I would wish on an enemy, let alone everybody who wants to try out CEGUI. Here's the abbreviated list of steps:

* Download PCRE
* Realize PCRE does not come with a Visual C++ project
* Fruitlessly search the web for prebuilt project files
* Spend some time reading through the Makefile.am and Makefile.in trying to figure out exactly how source files are being auto-generated in UNIX during the build process
* Recreate that build process in VC++, use the generated binaries to generate autogenerated source files
* Gingerly generate a config.c by hand
* Figure out which files actually need to go into the PCRE lib for CEGUI
* Compile PCRE
* Download FreeType
* Try to compile FT with provided project files
* Figure out how to put libs and headers for PCRE and FreeType where CEGUI wants them to be
* Compile CEGUI, receive link error
* Work back through libs with DUMPBIN, trying to figure out where the dependency crept in
* Spend a few minutes trying to figure out why part of FreeType wasn't being built
* Find a newsgroup post explaining (well, mentioning) the problem, and giving a solution which involves disabling part of FreeType
* Grep through the CEGUI source figuring out whether it uses that module (it doesn't)
* Edit the FreeType source code
* Recompile FT
* Recompile CEGUI

Since I'm writing my own renderer plugin, I didn't need to compile any of the included ones, so the build process for those is omitted here. Of course, that means I couldn't compile the samples. If I wanted to try out CEGUI, rather than already knowing how awesome it is, I would have fled long ago. Why put prospective users through a similar hazing process? I can understand not providing a full CEGUI binary, but not even dependencies?

[lindquist]

just use the 0.4 dependencies and a PCRE from http://www.psyon.org/projects/pcre-win32/index.php and it works fine!
Plus the deps pkg for 0.5 is preliminary. When 0.5 is released a proper dependency package will be provided, and we'll test compilation on all platforms we can.

Binaries are not TOTALLY out of the question either.

[lindquist]

Regarding the Lua post.
I've only now noticed that 5.1 is out as a stable release.
I'll probably give it a go, and see how it works.

I think that keeping 5.01 support is necessary for a while still tho. Any thoughts are welcome.

Personally I would'nt mind upgrading the bundled lua to 5.1

[Dalfy]

Lua 5.0.1 and lua 5.1.X should be two distinct scripting modules

[gcarlton]

Just a note on the lua module, there exists a problem with the executeScriptFile:

Code: Select all

   // load file
   RawDataContainer raw;
   System::getSingleton().getResourceProvider()->loadRawDataContainer( filename, raw, resourceGroup);

   // load code into lua and call it
   int top = lua_gettop(d_state);
   int error =   luaL_loadbuffer(d_state, (char*)raw.getDataPtr(), raw.getSize(), filename.c_str()) || lua_pcall(d_state,0,0,0);

   System::getSingleton().getResourceProvider()->unloadRawDataContainer( raw );

If an exception is thrown, the data container isn't unloaded via the "unload" function, instead the destructor of the container calls delete[] directly, which can cause problems for the app.

[spannerman]

Just carrying on from the 0.5 todo post lindquist made:

Sounds great! Im glad you guys are moving forward with Cegui and plan to release the new version soon. Just a couple of simple questions concerning the points listed -

1) Write a combobox widget using the new listbox:
Does this mean that the new listbox code definately will be included in this next version? If so, doesnt that mean all things listbox based (like the combobox) needs to be rewritten / tweaked to use this new method?

2) MIT license: Sorry, I think I missed the announcements concerning the move from LGPL to this license, but by reading up about it on the web it sounds pretty good; It sounds extremely unrestrictive, which Im guessing is the reason for the move.
Am I right in thinking that the casual non-commerical Cegui user is not really affected by this license change?

3) Precompiled dependency packages for M$ Visual C++ (7.1 and 8.0-express): Just double checking, but will users of VC 8 Pro be fine with the express dependencies?

Cheers

[lindquist]

@spannerman:
1) yes the new listbox is in the trunk already. it's not a breaking change tho as it's called ItemListbox and the old Listbox will still be there.

2) Yup, MIT is very unrestrictive. You can pretty much do anything you like except claim it as yours.

3) I honestly dont know, but I would think that they work together. If not you are welcome to provide a deps package for 8pro

@gcarlton:
Thanx for the report, I'll make sure this gets fixed.

[spannerman]

1) yes the new listbox is in the trunk already. it's not a breaking change tho as it's called ItemListbox and the old Listbox will still be there.

Ah right, cool.

2) Yup, MIT is very unrestrictive. You can pretty much do anything you like except claim it as yours.

Sounds good.

3) I honestly dont know, but I would think that they work together. If not you are welcome to provide a deps package for 8pro

Hehe. You think someone asking these sort of questions should be putting together dependancy packages?
Anyways, I guess I'll just wait and see what happens and do what needs to be done. I am having some issues compiling head at the moment tho, and Im waiting for feedbackfrom other users to see if its an isolated problem.

Cheers for the replies

[Sneftel]

In my experience, libraries work just fine between 8pro and 8express. It's the same runtime, after all. If there are issues, though, I'd be happy to release the deps package I've made for my own use with 8pro.

[spannerman]

Thanks Sneftel, I'd appreciate it if I could give it a spin with your dependancies to see if it solves my problems.

[lindquist]

I have been trying to find a directx 8.1 sdk, to no luck. It seems to be discontinued, so I'm considering if we should drop the dx81 renderer in 0.5.

It's hard to maintain something that I cannot compile.

Any objections? Or maybe a link to the SDK ?

Edit:
Spons was kind enough to provide me the files I needed, so we'll keep it for now I think

[muhkuh]

Hi lindquist,

I've had a look at the new listbox. I used the current svn trunk and copied over the samples from the pre_itemlistbox branch mentioned above.

The sample 8 runs smoothly except some problems with the popup menu of an item being behind the scrollbars of the window. What I don't understand is how to add some other window types to the itemlistbox. For example: How to insert a textbox into a itemlistbox?

Thanks.

Markus