Roadmap ?

[Banania]

Is there a roadmap available somewhere ?

Forgive my curiosity, I just want to know what is to be expected for the system soon (or not so soon).

[CrazyEddie]

Hi,

There's no roadmap document available at the moment, though obviously I do have some plans for the system I'll see if I can get something written and put up here on the site later on this week.

CE.

[Banania]

No pressure, but did you have time to write something ?

I don't want to sound impatient or ungrateful, I am just curious.

[CrazyEddie]

I've got something half written at the moment; I'm hoping to be able to post it tomorrow afternoon or evening.

It's taking longer than I anticipated because at the moment I'm up to my neck in code trying deal with something else, related to the 3rd party dependencies; which I'm also hoping to finish and announce tomorrow. (btw, it is not related to what is being discussed on the Ogre forum; so there's a little clue ).

CE.

[CrazyEddie]

I have managed to get this done

[color=0000AA]click here![/color]

CE.

[Banania]

I have managed to get this done

Great ! I'll have a look .

EDIT : Wow, this is a far more advanced roadmap than I was hoping for. I'll share my comments with you when I will have some more time...

it is not related to what is being discussed on the Ogre forum; so there's a little clue

Don't tell me you got rid of Boost. That would be too good to be true...

[spannerman]

Cool!

Whats the Falagard widgets about then?

And did I miss it...where's the bit about customisable imagery for all widgets?

Anyway, good to see all those tasty goodies still to come. Your going to be a busy man, but once that lot is done world domination is surely within your grasp

[CrazyEddie]

Don't tell me you got rid of Boost. That would be too good to be true...

Yes, as mentioned in the news entry, I have indeed got rid of boost And No, you're not dreaming; I really did it

Whats the Falagard widgets about then?

Guess!

And did I miss it...where's the bit about customisable imagery for all widgets?

Okay, I'll put you out of your misery; these are the Falagard widgets I usually name large components after the person who convinces me to implement them - in this case Falagard made the case for data-driven imagery layouts for widgets (many months ago now). This, incidentally, is the same reason why Taharez look widgets are called Taharez.

...once that lot is done world domination is surely within your grasp

Yes, I think this time I'll actually manage it. Mwhahahahaahaaa!

CE.

[Banania]

Hi CE,

I've read your roadmap carefully and thought I would share some of my thoughts with you.

First, some cheerleader's work :
Congratulations for this roadmap (and for the work you already did). I am quite pleased with a lot of things I read on it, especially the Treeview widget, the scripting module and the "Falagard" widget set.
Not mentioning the sample framework and the disappearance of Boost(which is not on this roadmap but is a great achievement. I still can't believe it is true 8O )

There is another "feature" I am particularly interested in : the internationalisation of the system. The Full Unicode support being one the most significant step of this process and I am looking forward to this.
I worked quite a bit on this topic in the past and here are my thoughts on the matter:

* You are considering right-to-left rendering. A must have feature to support some languages. Although it might not be so important, you might want to consider vertical text rendering while you are at it. Some languages are traditionnaly (Japanese being a good example) written vertically from top to bottom and from right to left. However, in everyday life, it is very common to write it like english. That's why I say we can live without it.
* To have a better support of languages like chinese with a lot of glyphs available, it might be necessary to allow several textures per font. We already discussed that but I thought I would write it again, just to be complete here.
* I would love to have the possibility to load/save texture and glyphs information once generated from a TTF font. This would allow to save the time to generate the texture at runtime. It would also allow to modify the texture font in an external program once generated.
* The possibility to add new glyphs on the texture at the moment they are used would be great, especially when using EditBox.
* Have you considered the usage of String Tables ? Having one string table per language, it would help to switch from one language to another at runtime. It can be done in the application (I did it for myself) but you might want to consider implementing it in the system. Of course, it would probably imply a lot of difficulties as switching strings could also mean having to switch texture font.
* Now forgive me if I say something stupid. I want to talk about line breaking functionnality but I don't have CEGUI's code with me and I might say something irrelevant. I think you are using the space character when breaking lines in text rendering. While this behaviour is good in most languages you will encounter as a European (you are British, aren't you ?), there are languages that don't use space and use subtle rules to break text. For example, japanese can be cut everywhere, even in the middle of a word with a few special cases related to punctuation symbols
(these are called Kinsoku rules IIRC). Thai(again, IIRC) doesn't use spaces but needs to be cut between words. To do that, we had to ask the translators to insert special codes(codes that were not part of the language) in the text to replace spaces so we could break the text correctly. Of course, these codes were to be considered in the breaking
process but were not to be rendered in any case.
Well, this part of my own experience is just to say that some languages have breaking rules that can be pretty different of english rules. To handle these situations, we had a special object, the LineBreaker which had a default implementation that broke lines on spaces. And we had several specialized objects derived from the base one for special languages : JapaneseLineBreaker, KoreanLineBreaker... to implement special behaviours. While this might not be applicable to CEGUI, I thought you might be interested in reading from past experiences.

Well, these are my humble thoughts on the matter. I'll let you think about this. I hope that I was clear enough.....and that it doesn't sound too much like a Feature Request list . Because it isn't, it is just a discussion on the system because I don't need these features now, although I would probably if I were to use CEGUI for a commercial project destined to be localized in twenty languages.

Keep up the very good work ! And good luck with your world domination ! Hope you will still have time to work on the system once you are the master of the world......

[CrazyEddie]

Thanks for your comments; it's nice to hear something from somebody who has previously had experience with internationalisation (this will be my first attempt ).

I thought about vertical text rendering (and actually had it on the first draft of the roadmap). I think support for this would be fairly easy to add since it really is just taking some settings from the source ttf font. The reason I took it off the list was because I've never seen a font like this

The addition of multi-texture support is, as mentioned when we touched on this before, going to be added.

Adding new glyphs to the font texture 'on the fly' is another thing which I'd like to have. Obviously though, each new glyph would cause a performance hit, though once they're on the texture that becomes a non-issue.

String tables is another excellent idea, and pretty simple to implement. Thanks for that one, I'd actually never given it much thought.

Your comments about line breaking is very valid, and most of this (that is, character properties) is part of the Unicode specification. So, with a full implementation of Unicode, this, and may other things beside, would be taken into account.

Hopefully, by the time 1.0.0 is done (and the gobal domination that comes with it ), the system will be a real force to be reckoned with

CE

[Banania]

Glad to read all of this !

Your comments about line breaking is very valid, and most of this (that is, character properties) is part of the Unicode specification. So, with a full implementation of Unicode, this, and may other things beside, would be taken into account.

I didn't know this was also part of the Unicode specification. I have actually very few experience with Unicode as it was not an option for us at the time we were working on this stuff. We had to work with that crappy Windows-specific MBCS stuff at that time because support was better than Unicode. Well, guess I should really dive into Unicode specification when I have some time....

[Banania]

From your roadmap :

Static text widget supporting some minimal markup.

What exactly do you mean by minimal markup ?

[spannerman]

Maybe some sort of basic html or forum BB code? Like Bold, italic, underline? That would be coool

[Banania]

Maybe some sort of basic html or forum BB code? Like Bold, italic, underline? That would be coool

That was my first guess. I was about to propose a text control with formatting styles like what you say : bold, italic, different colors as a feature request and I found that while re-reading the roadmap. So, I am wondering.....

[CrazyEddie]

Yeah, this is the kind of thing I had in mind... Though bold and italics are possibly slightly more difficult than you might think. Technically you require a bold and italic version of a ttf to do it properly, though in most cases it's faked by using other techniques; still not really easy though. I think when I get multiple textures per font this will put me on a better footing for these particular effects.

What I actually had in mind was the ability to change text colour, font, possibly formatting (i.e. left aligned, centred, right aligned, etc), and possibly the ability to embed images.

CE.