Just a couple of minor issues I noticed. The first is blurry button text (when center aligned). This is most noticeable on thin non-aliased fonts. This was rounding of y position in Button.centerTextVertically.
The other issue is in SelectList / Menu. The vertical text position didn’t take “menuPadding” (listPadding in the SelectList source) into account. This means when the list is scrolled to it’s default position at the top, the left padding doesnt not match the top padding and the selection highlight overlaps the borders.
The patch fixes this … but, when you scroll the list slightly, the selection highlight still overlaps. I am guessing this is something to do with clip padding but I cannot find a way to make it work.
Just a couple of minor issues I noticed. The first is blurry button text (when center aligned). This is most noticeable on thin non-aliased fonts. This was rounding of y position in Button.centerTextVertically.
The other issue is in SelectList / Menu. The vertical text position didn’t take “menuPadding” (listPadding in the SelectList source) into account. This means when the list is scrolled to it’s default position at the top, the left padding doesnt not match the top padding and the selection highlight overlaps the borders.
The patch fixes this … but, when you scroll the list slightly, the selection highlight still overlaps. I am guessing this is something to do with clip padding but I cannot find a way to make it work.
After patch, showing remaining overlap when scrolled …
RR
I’ll update this… thanks for the fixes!
I’m fairly sure this problem will cease to exist once I phase out Bitmap text, as you’ll notice all sorts of minor alignment issues where my attempt to fix only applies until font scaling gets out of hand. Since I’m not using scaling as a basis for resizing fonts after the commit this morning, the first issue should not happen now. However! I’ll make sure I verify this!
Btw, I’ll be adding the hypering to committed version of TextElement likely this evening. I still need to limit the ray cast check against the geometry if and only if a hyperlink exists. And I was hoping to underlining working by now… but this was not possible until this morning change to font scaling.
So… either tonight or tomorrow… underlining, strike-through and hyperlinking will be added to the committed version of TextElement.
I need to add skewing capability to AnimElement before italic will be possible without using two separate fonts (which I want to avoid).
@t0neg0d said:
I'll update this... thanks for the fixes!
I’m fairly sure this problem will cease to exist once I phase out Bitmap text, as you’ll notice all sorts of minor alignment issues where my attempt to fix only applies until font scaling gets out of hand. Since I’m not using scaling as a basis for resizing fonts after the commit this morning, the first issue should not happen now. However! I’ll make sure I verify this!
Btw, I’ll be adding the hypering to committed version of TextElement likely this evening. I still need to limit the ray cast check against the geometry if and only if a hyperlink exists. And I was hoping to underlining working by now… but this was not possible until this morning change to font scaling.
So… either tonight or tomorrow… underlining, strike-through and hyperlinking will be added to the committed version of TextElement.
I need to add skewing capability to AnimElement before italic will be possible without using two separate fonts (which I want to avoid).
Excellent Really looking forward to this change. Last night I tried out TextElement with my layout code, and have it mostly working. I am having one problem with getting the preferred size though. This is mostly because there doesn’t appear to be a way to get at the line count. Will a getLineCount() method exist in the final API?
@rockfire said:
Excellent :) Really looking forward to this change. Last night I tried out TextElement with my layout code, and have it mostly working. I am having one problem with getting the preferred size though. This is mostly because there doesn't appear to be a way to get at the line count. Will a getLineCount() method exist in the final API?
The commit using the new font size method will make this a non-issue, as scaling is not involved at all. Just using getDimensions will work.
I’ll definately add a few methods:
getLineHeight()
getLineCount()
getLineWidth()
etc.
Right now, TextElement.getAnimText().getDimensions() (or getHeight() or getWidth()) should give you the exact dimensions of the text. However, this may be scaled… if you grab the latest commit, this will work as expected.
@t0neg0d said:
The commit using the new font size method will make this a non-issue, as scaling is not involved at all. Just using getDimensions will work.
I’ll definately add a few methods:
getLineHeight()
getLineCount()
getLineWidth()
etc.
Right now, TextElement.getAnimText().getDimensions() (or getHeight() or getWidth()) should give you the exact dimensions of the text. However, this may be scaled… if you grab the latest commit, this will work as expected.
Awesome Sounds like that will do exactly what I want. Will take a look later on tonight.
@rockfire
And… here’s a vid of some of the latest changes. It shows some of the in-line alignment working with base-alignment and resizing. It also shows swapping fonts dynamically and the use of text effects both on buttons and in word-wrapped text while resizing.
You can also see how italics turned out using skewing as apposed to another font (in the top couple lines of the word-wrapped text test).
Currently working on underscore and strike, then I’ll port the hyperlink stuff.
@t0neg0d said:
@rockfire
And... here's a vid of some of the latest changes. It shows some of the in-line alignment working with base-alignment and resizing. It also shows swapping fonts dynamically and the use of text effects both on buttons and in word-wrapped text while resizing.
You can also see how italics turned out using skewing as apposed to another font (in the top couple lines of the word-wrapped text test).
Currently working on underscore and strike, then I’ll port the hyperlink stuff.
Really looking forward to this change. Last night I tried out TextElement with my layout code, and have it mostly working. I am having one problem with getting the preferred size though. This is mostly because there doesn’t appear to be a way to get at the line count. Will a getLineCount() method exist in the final API?