CrazyEddie's GUI System: Version 0.7.0 is Released!

[CrazyEddie]

What i don't understand is whether i should or shouln'd have picked the latest?

I think it was the right thing to do; at least, I'd have done the same

[scriptkid]

*edit: just wanted to add why I think /MT is better - because this option statically links the vc runtime libraries, where as /MD uses dynamic linking (requireing dlls); if you are going for a static-build, you most likely want the vc runtime linked statically as well.

This has just been committed to SVN, it was indeed something which we had overlooked. DebugStatic links as /MTd and ReleaseStatic as /MT now.

I am not sure how the dependencies were build. I guess that -in order to support complete static builds- all dependency projects should be linking statically as well, even though they might be DLLs themselves.

[Jamarr]

*edit: just wanted to add why I think /MT is better - because this option statically links the vc runtime libraries, where as /MD uses dynamic linking (requireing dlls); if you are going for a static-build, you most likely want the vc runtime linked statically as well.

This has just been committed to SVN, it was indeed something which we had overlooked. DebugStatic links as /MTd and ReleaseStatic as /MT now.

I am not sure how the dependencies were build. I guess that -in order to support complete static builds- all dependency projects should be linking statically as well, even though they might be DLLs themselves.

Right. It's hard to remember the details now, but I am fairly certain that all of the statically-built dependencies are built with /MD instead of /MT. So to get a 100% statically built library I had to go find, download, and rebuild all of the dependencies with the /MT switch. I believe that if you try to link libs with /MD against a lib with /MT you will get some symbol-already-defined linker errors.

[CrazyEddie]

I think really we're going to need two sets of dependencies - one for the dynamic builds with /MD(d) and another set for the static builds with /MT(d). Otherwise we're never going to be able to please everybody - since I'm the 'dependencies guy' I'll look into this shortly - early next week - and see whether this can be done for a 0.7.1 release.

CE.

[Van]

Woot! I'm glad to see this! been waiting along time!

[CrazyEddie]

Hey! Currently the release is looking a bit shabby to be honest. While I knew there would be some issues with such large changes, the extent and range of the issues coming in are surprising With any luck the upcoming 0.7.1 might be a bit more solid...



CE.

[Jamarr]

I think really we're going to need two sets of dependencies - one for the dynamic builds with /MD(d) and another set for the static builds with /MT(d). Otherwise we're never going to be able to please everybody - since I'm the 'dependencies guy' I'll look into this shortly - early next week - and see whether this can be done for a 0.7.1 release.

CE.

Right now you there are two pre-compiled download packages: 1) dynamic-cegui + static-cegui and 2) dynamic-deps + static-deps, right? Instead, why not offer: 1) dynamic-cegui + dynamic-deps (with/MD) and 2) static-cegui + static-deps (with /MT). This seems far more pratical.

Maybe my judgement is way off, but it seems like the number of users who want static and not /MT, as well as the number of users who download cegui and not the dependencies are few and far between. Judging solely by forum posts, I would guess that 99% of users fall into two categories: 1) those who want dynamic cegui+deps and really don't care about the vcruntime switch, and 2) those who want static cegui+deps with the /MT switch. You can't possibly cater to everyone, but I think this would cover the majority. /shrug

I could personally care less either way, as I've already gone through all the trouble. But I think having these two packages instead of the current would have made my life easier in the beginning

[scriptkid]

It sounds good from the point of having less files, but grouping those two packages as one would only work for the SDKs. Because people who want to build the sources themselves, only need the dependencies, right?

[CrazyEddie]

Yeah, currently we have:

Source package
Dependencies package built with /MD (one per compiler)
SDK - includes dependencies (one per compiler)

I thought we're looking at:
Source package
Dependencies package containing one version of everything built with /MD and one version built with /MT (one per compiler)
SDK - including dependencies (one per compiler).

However, we do then have the situation where we have people downloading twice as much as they need - in that circumstance we might consider a 'static deps package' and a 'static SDK' separate from the dynamic versions. Though I agree here that this creates a lot of new files, packages and confusion.

Personally, I'm all for any solution that reduces the amount of effort I have to put in So, if someone tells we what that is, that's what we'll do

CE.

[tbaldree]

A quick question - I started migration to .7 for Torchlight ( REALLY wanted those embedded color changes in text, as will allow us to do a lot of UI polish that is otherwise too cumbersome to do ) - however I noted the removal of getFormattedTextExtents from font, and ended up having to back it out.

We were relying on this quite heavily to be able to determine the correct extents for our relatively complex item tooltips, which have lots of differences in internal formatting, with some areas needing wrapping and others not. At any rate, is there an alternative to this, whereby the width of a wrapping text element can be determined prior to setting the sizes on everything? Thanks!

[CrazyEddie]

Hi there,

Awesome work on Torchlight

This is kind of covered here: viewtopic.php?f=10&t=4363. Though depending on exactly how you have the windows and text arranged - and on who and how things are being drawn - this may or may not be completely relevant.

A little bit of history and what have you, so that you'll be able to decide the best course of action... The removal of this (and other) functions is due to us removing the formatting responsibilities from Font and re-implementing it elsewhere, this is all related to the string markup changes (because a window text is no longer just text, so Font does not have enough information to return correct extents information). Basically what happens now is that the input text string is parsed into a CEGUI::RenderedString - which is largely the level at which text is rendered in the newer CEGUI (Editbox widgets being an exception). Formatting is now applied at the RenderedString level via a FormattedRenderedString, which basically wraps the RenderedString in order to do formatting.

So what's the importance of all that? If you've previously been drawing your own formatted text (say via Font::drawText and supplying a TextFormatting value) then this is no longer available and should be updated to use RenderedString and FormattedRenderedString - doing this will give you access to the FormattedRenderedString::getHorizontalExtent and FormattedRenderedString::getVerticalExtent functions that return the pixel extents of the string as currently formatted. If you're not currently drawing the text directly, but are using some combination of other window types, things become possibly more complex. As seen in the thread linked, I've added property updates to expose the formatted extents for the StaticText - so that may be enough for you. If you're using other window types instead (or as well), it may be that those will need to add functions and/or properties to expose the extents values from the internally used FormattedRenderedString objects (though I think it's only StaticText affected anyway - will check once I get my dev system up and running again ).

HTH

CE.