The Development of CEGUI 0.7.x

[CrazyEddie]

Why don't just release 0.7 with base functionality and then upgrade from there?

The issue with making a 0.7.0 release now, is that the ongoing development is going to require further interface changes - on top of what's already been done. This means that we make the 0.7.0 release, everybody updates their code (and perhaps 3rd parties rewrite their renderer modules) to work, then we make the 0.7.1 release, which changes many things an breaks the interfaces requiring everybody to update their code again, then we do the same again with 0.7.2 and so on - this is unacceptable to me, and I feel that it would be unacceptable to many others also.

This way it'll get way more testing and a lot more bugs will be fixed. Also might highlight some design/implementation problems earlier.

We have the code in a public SVN repository for this purpose. I'm not trying to be funny by saying that, I do understand the POV of those people wanting a quick release of this code, but it's just not ready. The way to look at it is that if people are unable or unwilling to check the code out of SVN and build it, then they are definitely not ready to use the code in it's current state.

One thing I do want to look at is unstable development snapshot releases (source and binary packages) - though I want that to be a fully automated process, but I've not looked into getting that under way yet.

CE.

[Jabberwocky]

When people start asking "is it ready yet?" and "when will it be done?", you know you're working on something cool.
Sinbad has got the same thing going on over in the Ogre forums with the new terrain upgrades.

[CrazyEddie]

It's certainly good to know that users are wanting to use the new improved features; there would be nothing worse than spending a lot of time on something nobody really wants

CE.

[Shareth]

I just wanted to point out that for those using a library, releases with small amount of features half a year are better than releases with huge amount of features but once per 2 years. Its obvious that if code is not ready, its not ready. No one is going to put into production svn builds of untested code. But waiting another year just to get a decent speed up in rendering (which is needed a lot) is sometimes not an option. That is why I was asking why current features couldn't be frozen and 0.7 be released with all its current stuff that can help a lot of people right now, not after 1 year of waiting. I understand your position, I understand that there will be breakage of API/ABI with all the other features you are working on right now and I clearly understand all the problems it might cause but sometimes its better to release early and release often.

[CrazyEddie]

I absolutely agree with "release early, release often" - although it seems quite the opposite here with CEGUI at times Last year I had intended to increase the release rate quite a bit; we started off ok with 0.6.0 and the three monthly point releases, though as I got bogged down in all the BS again, this did not continue into 2009. I had also stated (on IRC, I think) a desire to move to time based releases - whereby we release on set dates with whichever feature set we had at that time - this still interests me more that feature based releases, but is only really valid when there has been continuous development occurring - since this was not the case for CEGUI (where many months nothing is done at all), we would have probably have had 0.7.x and 0.8.x released by now with the same core feature set as 0.6.x

I also fully understand the position of yourself, and others, who for a wide range of reasons are unable to wait for the 'next big release'. Though I must point out that while 0.7.0 is indeed CEGUI's 'next big release', it's not actually going to contain a huge volume of new features - most of the the things shown in the videos are all possible by way of the rendering system redesign (though that is a huge deal for us). Aside from the renderer module rewrites, the only other completely new feature in 0.7.0 will be the support for formatting tags in text strings.

So now people will wonder why it's taken so long to get those things done, well the main reason for that is that CEGUI is a part-time project that we do in our free time, so these things are done when they're done, and if they're not done, well, that's unfortunate but not the end of the world; I'm certainly not going loose any sleep over the fact that so far it's taken about 18 months to do six weeks work - that's just the way it is. This project is supposed to be a fun diversion for me, so when it's not fun I just take a few weeks - or months - away from it, hence the large delays

CE

[Speedo]

0.7 is looking absolutely fantastic. As much as I'm drooling over the new features, I would really like to see a release as soon as it's practical just for the new renderer changes.

I do have a feature suggestion though (as if to contradict what I just said ). You mentioned earlier about a 0.7 feature that would let you embed buttons and so on in text. What about something that would allow a portion of text a tooltip or a window in a toolip manner (on mouse hover). I'm thinking about the ability to do something like you typically see in MMOs, where you can "link" a game item in chat that will show the item's icon, stats, etc when you hover over it.

This project is supposed to be a fun diversion for me, so when it's not fun I just take a few weeks - or months - away from it, hence the large delays

Breaks?! No breaks allowed, back to work!

[CrazyEddie]

0.7 is looking absolutely fantastic. As much as I'm drooling over the new features, I would really like to see a release as soon as it's practical just for the new renderer changes.

Thanks. I want a 0.7.0 release ASAP too Currently there are still many things to be addressed that were messed up when the renderer modules got rewritten - so I must ask you guys to be patient for a bit longer (sorry!)

I do have a feature suggestion though (as if to contradict what I just said ). You mentioned earlier about a 0.7 feature that would let you embed buttons and so on in text. What about something that would allow a portion of text a tooltip or a window in a toolip manner (on mouse hover). I'm thinking about the ability to do something like you typically see in MMOs, where you can "link" a game item in chat that will show the item's icon, stats, etc when you hover over it.

This will be possible in a similar way to what was mentioned above with regards to clickable link texts. Basically you have a window of some type (that renders so it looks like part of the normal text) under the control of the string layout facility, and just assign an appropriate tooltip string to that window. I am aware that there are some window management pitfalls when using this facility; these are not insurmountable, and further improvements will be made in response to user moaning feedback

This project is supposed to be a fun diversion for me, so when it's not fun I just take a few weeks - or months - away from it, hence the large delays

Breaks?! No breaks allowed, back to work!

Hopefully, I'll make progress today

CE.

[Mikademus]

Why don't just release 0.7 with base functionality and then upgrade from there? This way it'll get way more testing and a lot more bugs will be fixed. Also might highlight some design/implementation problems earlier.

The issue with making a 0.7.0 release now, is that the ongoing development is going to require further interface changes - on top of what's already been done. This means that we make the 0.7.0 release, everybody updates their code (and perhaps 3rd parties rewrite their renderer modules) to work, then we make the 0.7.1 release, which changes many things an breaks the interfaces requiring everybody to update their code again, then we do the same again with 0.7.2 and so on - this is unacceptable to me, and I feel that it would be unacceptable to many others also.
...
We have the code in a public SVN repository for this purpose. I'm not trying to be funny by saying that, I do understand the POV of those people wanting a quick release of this code, but it's just not ready. The way to look at it is that if people are unable or unwilling to check the code out of SVN and build it, then they are definitely not ready to use the code in it's current state.
...
I absolutely agree with "release early, release often" - although it seems quite the opposite here with CEGUI at times Last year I had intended to increase the release rate quite a bit; we started off ok with 0.6.0 and the three monthly point releases, though as I got bogged down in all the BS again, this did not continue into 2009. I had also stated (on IRC, I think) a desire to move to time based releases - whereby we release on set dates with whichever feature set we had at that time - this still interests me more that feature based releases, but is only really valid when there has been continuous development occurring - since this was not the case for CEGUI (where many months nothing is done at all), we would have probably have had 0.7.x and 0.8.x released by now with the same core feature set as 0.6.x

CE.

What about trying to combine the best of several worlds and release early and often release candidates (0.7.RC1, 0.7.RC2, etc)? Then you will get the early testing and feedback, allow people to try out stuff, avoid the difficulty-or-stigma-of-sorts association with SVN downloads, and not be committed to not breaking the API.

[CrazyEddie]

Thanks for the suggestion. We will consider all the options and make a decision shortly.

[CrazyEddie]

To update: We are almost certainly going to start issuing unstable development packages of the CEGUI lib in the near future. Additionally, I intend to have a final release of cegui 0.7.0 by the middle of September (this year, btw ).

Just to inform as to the current state of things, I committed most of the new string rendering bits a while ago. As it stands in SVN right now, the new text rendering is all working except for strings with embedded newlines - my current working copy has that fixed also, but this subsequently breaks the template word-wrapper classes, I will fix that either tonight or tomorrow and commit the finished thing. Once that is done, on Thursday I will start work on making some improvements to the resource loading...

CE.

[CrazyEddie]

Update time...

The first wave of resource loading enhancements are in. For the user of CEGUI, these changes basically mean that when loading schemes, imagsets and fonts, the default is no longer to throw an exception if a resource of the same type already exists with that name. Rather, we return the existing instance instead. It's possible to pass an XMLResourceExistsAction value to the create functions to choose some other action also, the choices being to return the existing object (default), destroy and replace the existing object (currently dangerous!), or to throw an AlreadyExistsException.

This is actually quite a large interface breaking change; most of the breaks come due to the use of a common base class for the imagset, font and scheme manager objects, other breaks were when made to be consistent with that new base class interface. Details have been added to the 0.7.0 porting page on the wiki. This has meant a large number of internal things have moved about, though mostly it's a much better and cleaner implementation - which much less repetition.

There are some more changes to come with regards to this. Some are more internal changes, some are support facilities for the changes already made, others are intended to make the use of 'linked' resources a bit easier (those being the ones that refer to some other xml resource, such as schemes and fonts). Most of these changes should be done by next weekend, at which point I'll turn to the input injection / recursive events issue.

CE.

[CrazyEddie]

Okelley dokelley.

Yesterday I made a few more mods and enhancements. Now in a scheme file you do not have to list the CEGUI name for fonts and imagesets that you load; you can just specify the xml filename and the name will be acquired later automatically. This makes schemes easier to maintain, since if you change the name of a font you do not have to remember to update all references to it in schemes. So, in schemes you can now just have this:

Code: Select all

<GUIScheme Name="TaharezLook">
   <Imageset Filename="TaharezLook.imageset" />
   <Font Filename="Commonwealth-10.font" />
   <LookNFeel Filename="TaharezLook.looknfeel" />
   ...
</GUIScheme>

I also (finally) relaxed the requirement that the target type for a window alias exist at the time the alias is specified.

The main, and final, part of the resource loading changes was to allow the automatic loading of all resources from a resource group matching a specified name. This may or may not end up demonstrated directly in the samples, but for most of you guys writing games and such, this new system is what you'll want to be using, since generally you'll just be distributing the resources you need to be loaded. So, what this means is that in your init code you'll do things like this:

Code: Select all

CEGUI::ImagesetManager::getSingleton().createAll( "*.imageset", "imagesets" );
CEGUI::FontManager::getSingleton().createAll( "*.font", "fonts" );

And that will load as imagesets, all files matching '*.imageset' from the resource group 'imagesets', and load as fonts, all files matching '*.font' from the resource group 'fonts'. Of course if you have all your UI assets in a single resource group, you use the same group name, and rely on the filename pattern matching to get the right set of files for each type of file.

CE.

[Jamarr]

Those changes look good. While you said those are the final changes to the resource system, what about additions? I was thinking something along the lines of wxWidgets, where they provide a separate tool (zlib-based) to archive all resources into a single file and then the system loads resources from the archive. Really all you need is a resource provider that can use zlib to load the resources from said archive; this would be ideal for embedded systems and/or to deter most users from modding resources.

[CrazyEddie]

Yeah this is definitely something that could be considered missing, though my stance has always been to provide the most basic function for certain parts, while providing the needed interface for people to provide their own more advanced implementations; I think I said elsewhere that we're a GUI lib not a resource loading lib. But again, if enough people started asking for this, eventually it would probably go in - perhaps we should run a poll, perhaps we'll get seven or eight people vote

One more feature I forgot to mention before is the addition of events for those managers that load those scheme, imageset and font resources. There's notifications for Created, Destroyed and Replaced.

CE.

[CrazyEddie]

Note to IgnisInCaelum: I have split the scheme / imageset / devil / codec loading issue into it's own topic, which can be found here: viewtopic.php?f=3&t=4214, because it's turned into something much bigger and deserves it's own special place

CE.