CEGUI (Crazy Eddie's GUI) Forums

This topic is largely to serve the same purpose as the render-target topic, though in the broader sense of all changes being made for the 0.7.x release series (including the renderer rewrites, now merged into trunk).

If anybody intends following this, but did not follow the other thread, you can find that thread here.

Ok. Progress is currently very slow. I'm actually working on the beginnings of improvements to resource loading - one of the things we're adding at this early stage basically consists of being able to change the behaviour of CEGUI when encountering a resource that already exists; rather than always getting an exception, it will be possible to return the existing resource, replace the existing resource, or perhaps something else. As I got into the guts of CEGUI I started to get a bit down with regards to the quality of some of the code - there is much repetition, while at the same time little consistency, so I'm going to take the time in order to improve this situation.

Having started this work initially, I then got side-tracked onto other non-CEGUI related matters, and also I have not been feeling too great either; today is my first real day back at CEGUI in almost a week, and hopefully I can now start to make some real progress.

CE.

Ok. Due to coders-block nothing has been done recently, at all. I'm putting this down to a general uneasiness with the area that I was working on, so in order to side-step that issue for now, I'm going to work on other areas and come back to the resource loading changes at a later time and in the mean time a solution for that which I'm happy with should present itself.

So, this week I'll start on the custom text rendering, and also put an "effect manager" object in place that will allow the extension of the window mappings to include named effects, with this it will be possible to directly create window types that have associated effects - you might have your normal "TaharezLook/FrameWindow" and then perhaps "TaharezLook/WobblyFrameWindow" or something.

CE.

I have uploaded a new dependencies package for Mac OS X Xcode users - this is the 0.6.9999 version one. This package is needed for current svn trunk since the 0.6.1 version dependencies package has the install path set to the 'old' incorrect location, whereas svn trunk needs the 'new' correct locations. If that's confusing, try this:

For svn branches/v0-6 and the source releases 0.6.1 and 0.6.2, continue to use the CEGUI-DEPS-0.6.1-mac.zip package
For current svn trunk use the new CEGUI-DEPS-0.6.9999-mac.zip package.

CE.

I have made a start to the enhanced text rendering. There's a bunch of stuff to 'get right' here due to the way the existing formatting and what have you works, so that's the main challenge rather than anything else.

I currently have a test implementation that does some basic parsing and so allows you to specify a property string, thus:

and the output is like this:


The target for the test implementation is currently to provide colour, font and embedded image functionality. Due to the fact this is being implemented via a user re-assignable object, it will be possible to supply an object that does anything you like and also on a per-window basis (which is kinda required since we don't want the enhanced formatting to apply inside editboxes, otherwise how would you edit such strings properly?

CE

CrazyEddie wrote:

Sweeeet!

I like the colored text, that looks good.

I'm glad you mentioned that this will be optional, though I'm sure I will end up using it at some point. I am curious how you plan on handling images or any 'block' shaped object; specifically, if they will span multiple lines? and if so how that will affect the surrounding text?

If we can inline any drawable object, I wonder how difficult it would be to implement a very basic html-control; something along the lines of wxHtml...

At least in the first iteration we will maintain the concept of a 'line', and when laying out text the system will position each line beneath the preceding line at a position that is determined by asking the preceding line for it's height; when reporting it's height a line will use whatever is the tallest element - so if you have text that's 20 pixels tall and an image that's 50 pixels, the line height is 50 pixels.

CE.

CrazyEddie wrote:

The target for the test implementation is currently to provide colour, font and embedded image functionality. Due to the fact this is being implemented via a user re-assignable object, it will be possible to supply an object that does anything you like and also on a per-window basis (which is kinda required since we don't want the enhanced formatting to apply inside editboxes, otherwise how would you edit such strings properly?

CE

That is indeed very nice, especially that it will be pluggable, allowing for some cool specializations (I'm sure the other changes that goes into 0.7 are way more advanced than this, but this is so much easier to see the direct benefit of. )

Absolutely I'm knee deep in a total redesign of the text systems, and as I progress with the new structure lots of possibilities are emerging - even things like circular text (though that will ideally need a minor tweak to the GeometryBuffer support - so things that advanced might not be in the very first 0.7.x offering).

CE.

So uh...are you planning on making a window-based Table/MultiColumnList widget for v0.7.0 or maybe v0.7.1? Because you know...that would be totally awsome, right?

It would be totally awesome, yeah. I think we have to rule out such a thing for 0.7.0 - it's already delayed hugely, with very slooow progress at the moment. 0.7.1? Definitely, maybe

CE.

Quick update on progress.

I have uploaded a new video to the youtube channel that shows what I have (finally) got around to working on over the past couple of days or so; it's the advanced string rendering extensions. Previously I posted a screen shot showing some multi-coloured text, well things are now moved on a bit and we have the ability to have 'strings' that can basically contain anything renderable.

Obviously all this this means that internally things are not just stored in a CEGUI::String, but uses a more complex system - although the main client interface will remain the same and still use basic text strings (though there will be the optional addition of a parser object that will parse the basic text strings into the more complex entities).

Challenges obviously exist with regards to formatting. Most of these are ironed out, though I have not added back the justified support at the moment. As I think I mentioned before, eventually 'Font' will not be charged with rendering duties - those will be farmed out to 'text renderer' objects, though this has not happened yet. Items of varying height on a line are currently centred, though it's my intention to allow some options on how to handle that on a per sub-component basis. The options will basically be top, bottom or centre aligned, with the likely addition of a 'scaled' option also.

Anyhow, none of the code for this has been committed just yet, mainly because it's not in a directly usable form. The demo seen in the screen shot and video actually contains quite a lot of code to get this up and running, though it's all stuff that will be done behind the scenes once I get a bit farther along.

Here's the video:


Here's a screenshot:


CE

Nice Eddie,

Definitely a nice improvement. One more suggestion is to have clickable links embedded in the text.

Just a suggestion

/G

Very cool!!

Thanks for the comments, I'm glad you likey!!

With reference to having links, that's actually quite hard to do using the text alone. However, I'd already considered adding a component that would effectively allow child widgets to appear 'embedded' within a string, so it would then be possible to have a 'button' that looks like a link text embedded in the string.

I added this ability and made a new video to demonstrate:


It's quite small here, but look at it on youtube itself and it's much clearer to see. This could lend itself to some cool layout possibilities. What do you think?

CE.