Log for on 19th July 2013:
Times are UTC Toggle Colours
00:12:59  *** Supercheese has joined
06:18:50  *** tycoondemon has quit IRC
06:35:58  *** tycoondemon has joined
06:55:56  *** tycoondemon has quit IRC
06:56:47  *** tycoondemon has joined
07:32:57  *** Zuu has joined
07:32:57  *** ChanServ sets mode: +v Zuu
08:09:34  *** Supercheese has quit IRC
08:36:29  *** Ristovski has joined
09:29:27  *** Alberth has joined
09:29:27  *** ChanServ sets mode: +v Alberth
10:34:49  *** ntoskrnl has joined
10:56:30  *** ntoskrnl has quit IRC
12:16:30  *** ntoskrnl has joined
13:13:27  *** LordAro has joined
13:13:27  *** ChanServ sets mode: +v LordAro
13:15:33  <Zuu> If you in DrawWidget() detect that you need to ReInit the window (so that widget sizes get re-calculated), you cannot do that because DrawWidget is const. A hackish solution is to override You can override OnPaint and manually call this->DrawWidgets(). To the window, add a mutable member that DrawWidget set and read that in OnPaint to do a this->ReInit. However, that sounds like a non-nice solution.
13:16:00  <Zuu> In the station construction window, this has been solved by painting the text at the bottom in OnPaint rather than in DrawWidget.
13:16:15  <Zuu> (OnPaint is non-const)
13:17:13  <Zuu> So maybe I should paint the widget that needs to react on string changed length directly from OnPaint rather than using the DrawWidget callback.
13:22:30  <Alberth> sounds like a good way out
13:22:50  <Alberth> as you said, we already do that kind of trickery, so it's not adding new problems :)
13:26:48  *** ntoskrnl has quit IRC
13:31:45  <Zuu> It at least don't add a nasty mutable member variable :-)
13:34:15  <Alberth> :)
13:34:27  <Zuu> A possible solution is to follow your path of the solution (just one widget), draw the right-most column first and see how much width it used and then use the remaining width for the left column.
13:34:52  <Zuu> This should just work without needing to re-calculate widget sizes.
13:35:01  <Alberth> but still keep a column-ish look
13:35:05  <Zuu> yep
13:35:14  <Alberth> sounds like a good idea
13:36:51  <Zuu> But that assumes that the right column is aligned to the right (so that it can use as much space as it needs), or that we check the required width before painting (resulting in rendering the same string twice)
13:39:13  <Zuu> There will still need to be a variable for keeping track of the previous width of the column (if it is aligned to the left) and a complete re-paint if any string is found to be larger than the old width, or if no string is wide enough to fill the whole column width.
13:40:01  <Zuu> Old width will simply be used as the left border of the second column. (and the opposite for rtl)
13:41:38  <Zuu> Hmm, if you display numeric percentages, you will like that the progress column is aligned to the right. If you display something else it may be useful to have align to left. But perhaps numeric values is most common?
13:42:31  <Alberth> oh, that's why you aligned to the right
13:45:09  <Alberth> either solution is fine I think, openttd uses both forms
13:50:29  <planetmaker> how does that work with rtl languages?
13:51:14  <Alberth> globally  s/left/right/   and vv
13:52:11  <planetmaker> ok, good. Just wanted to make sure that you're aware of that in the above discussion
13:52:13  <Alberth> ie you start drawing at the other end too, so you have the same problem
13:53:00  * Alberth hopes (and mostly expects) I added rtl support in my patch
13:54:31  <Alberth> the only thing Zuu is changing is to preserve the column-ish feeling, which could be useful for interpreting the window
13:54:56  <planetmaker> yes
13:56:01  <Alberth> hmm, does it support clicking at the window to get back to the story book with the long description?
13:58:04  <Zuu> No. A goal can be located at 0, 1 or many story book pages.
13:58:19  <Zuu> s/located/refered to by/
14:02:37  <Alberth> pity, perhaps someone will find a way to do that one day
14:10:17  <Zuu> hmm, on each paint I will need to check the width of also hidden lines (scrolled out).
14:10:51  <Zuu> Otherwise, scrolling the list will cause the column width to change.
14:13:30  <Zuu> The split widget solution has the benefit that it will do that when a ReInit() is made. But you could still cheat and not ReInit when a scrolled out item changes size.
14:15:03  <Zuu> Though, I could in theory do this with the one-widget solution. Eg. check the size of drawn strings. If they differ from the old width. Run through all non-displayed lines and check their width. If the max width still is different from the old one, use the new one and trigger a new re-paint.
14:16:21  <Zuu> So if you display a part of the list that don't contain the widest string, you will need to check the size of all lines on each paint. This will however need to be done in both solutions.
14:16:39  <Alberth> but that involves weird handling for the width variable, the OnPaint solution seems a more natural place for it, to me
14:17:27  <Zuu> Agreed that OnPaint still works. It saves a ReInit for each column size change.
14:17:38  <Zuu> (I just ramble a bit as I think of what I need to do ... )
14:53:35  *** Lord_Aro has joined
14:53:35  *** LordAro is now known as Guest384
14:53:35  *** ChanServ sets mode: +v Lord_Aro
14:53:35  *** Lord_Aro is now known as LordAro
14:59:30  *** Guest384 has quit IRC
16:47:31  *** frosch123 has joined
16:47:31  *** ChanServ sets mode: +v frosch123
16:57:37  <Zuu> Hmm... DrawLayoutLine appears to return 0 on empty strings even if when the string is aligned to the right.
16:58:02  <frosch123> it returns 0 if stuff is clipped
16:58:06  <Zuu> I would expect it to return the value of [right] in that case.
16:58:10  <frosch123> and similar cases
16:58:32  <frosch123> what ever it returns, it is wrong
16:58:58  <frosch123> what do you need that info for?
16:59:02  <Zuu> If you draw aligned to right, the return value is the leftmost pixel used.
16:59:35  <Zuu> However, if the string you pass happen to be an empty string you get 0 as response and not the right most pixel.
16:59:52  <Zuu> When I calculate the width of the drawn text, I don't get zero-width in that case.
17:00:00  <frosch123> well, you also get 0 if the string is clipped by the dpi
17:00:29  <frosch123> why don't you use getstringwidth?
17:00:40  <Zuu> Because that reneders the string twice
17:00:51  <frosch123> it doesn't
17:01:15  <Zuu> If I paint it, I get the width, why should I render the text another time to get its width?
17:01:24  <frosch123> is the return value of drawlayoutline actually used anywhere?
17:01:27  <frosch123> maybe we can remove it
17:01:39  <frosch123> Zuu: because you don't get the width
17:01:55  <frosch123> windows are not always drawn in total, but sometimes only sections
17:02:35  <frosch123> anyway, the string layout is cashed
17:02:40  <frosch123> you can just call getstringwith
17:02:52  <frosch123> we should remove the returnvalue of drawstring, if possible
17:03:24  <Zuu> DrawString returns "In case of right alignment the left most pixel we have drawn to." according to the doxygen comment. That gives me the idea that I can use that to calculate the width of the string without having to do a separate width check.
17:03:52  <Zuu> In SDL+TTF that causes a complete render of the string which is why I though it was expansive.
17:06:47  <Zuu> Thanks for pointing it out. I will now just iterate over all strings and check the max width pririor to drawing. Makes the code possible easier to read.
17:12:07  <frosch123> there are exactly two places in the source where the returnvalue is used :)
17:12:58  <frosch123> station list (weird cargo rectangles after text) and groupbox caption (frame line starts after caption)
17:14:31  <frosch123> it might be possible to make the station list glitch
17:14:54  <frosch123> but i guess the cargo thingie in the stationlist should be replaced by somethnig better anyway
17:15:31  <frosch123> remains the groupbox as only valid usecase
17:16:16  <frosch123> not sure whether we use them anywhere beyond game options :p
17:19:09  <Zuu> so, we need to move more options away from game options or re-design it :-)
17:20:11  <Zuu> That said, can't the group box make use of GetStringBoundingBox(str).width?
17:20:13  <planetmaker> both really
17:25:10  <frosch123> checking currently :)
17:31:26  <frosch123> fs#5658 is funny
17:31:49  <frosch123> never knew the vehicle gui would affect the smallmap, if the vehicle is already centered
17:34:51  <frosch123> @commit 4339
17:34:52  <DorpsGek> frosch123: Commit by peter1138 :: r4339 trunk/newgrf.c (2006-04-09 18:08:20 UTC)
17:34:53  <DorpsGek> frosch123: - Comment Change: NewGRF, update comments for units of speed
17:35:01  <frosch123> @commit 6040
17:35:01  <DorpsGek> frosch123: Commit by truelight :: r6040 /trunk (3 files in 2 dirs) (2006-08-21 17:41:04 UTC)
17:35:02  <DorpsGek> frosch123: -Add: when clicking twice on a Location Button, the SmallMap centers on your position (based on FS#54 by thomasdev)
17:35:03  <DorpsGek> frosch123: -Add: when clicking twice in SmallMap on a position, it centers there (based on FS#54 by thomasdev)
17:35:04  <DorpsGek> frosch123: -Add: add a button in SmallMap that centers the SmallMap on your current position (based on FS#54 by thomasdev)
17:35:27  <frosch123> truebrain and rigs of rods guy!
18:02:24  <Zuu> Alberth: I've uploaded an update of your patch to FS#5611 ( ). I've split out your coding style improvements into a separate patch.
18:28:57  <Alberth> thank youy
18:29:03  <Alberth> -y$
19:15:12  *** Alberth has left
21:47:17  *** frosch123 has quit IRC
22:04:06  *** LordAro has quit IRC
22:44:38  *** Supercheese has joined
23:03:01  *** Ristovski has quit IRC

Powered by YARRSTE version: svn-trunk