← Back to team overview

widelands-dev team mailing list archive

Re: [Merge] lp:~widelands-dev/widelands/fh1 into lp:widelands

 

> Currently I use that method, rendering a test string to know the font height.

As mentioned, I think with the caching this approach is fine.

> I'm coming to the multiline edit box, and I was thinking, should the
> wordwarpper be kept around? 
No, I think it should definitively be killed. The one in the richtext render should be strictly superior to what we have in wordwrap.

> It is currently only used in the multiline
> textarea and the multiline edit box. For the multiline textarea, i think the
> wrapping done by the renderer will be sufficient. Now for editbox, in which
> caret must be rendered, that will be an issue. The multiline textarea is only
> used in one place in the map editor.

This is the hardest thing to change imho. I am not really sure how to proceed either - I was thinking about a <caret> tag too. It might not be a problem - a human types at most 4-5 chars per second, we should be able to rerender the text this often. And the cache will just overflow with useless cached images, but eventually clear out. So I'd try this approach first.

> According to me, it would be nice to allow rendering of the caret further down
> in the new renderer and get rid of this wordwrap class. I was thinking of a
> caret tag, but it will interfere with surface caching. I'm just asking if you
> think it is a viable solution, and if you have some guess of where to
> implement that.

Okay, so I think I commented on this before reading this paragraph. As mentioned, I find this a difficult design decision and I am not sure if the tag is viable, but I have no clear path forward that is not using a tag, so I suggest trying that.

Again, thanks for working on this Charly!
-- 
https://code.launchpad.net/~widelands-dev/widelands/fh1/+merge/177228
Your team Widelands Developers is subscribed to branch lp:~widelands-dev/widelands/fh1.


References