Times are UTC Toggle Colours
00:12:59 *** Supercheese has joined #openttd.dev 06:18:50 *** tycoondemon has quit IRC 06:35:58 *** tycoondemon has joined #openttd.dev 06:55:56 *** tycoondemon has quit IRC 06:56:47 *** tycoondemon has joined #openttd.dev 07:32:57 *** Zuu has joined #openttd.dev 07:32:57 *** ChanServ sets mode: +v Zuu 08:09:34 *** Supercheese has quit IRC 08:36:29 *** Ristovski has joined #openttd.dev 09:29:27 *** Alberth has joined #openttd.dev 09:29:27 *** ChanServ sets mode: +v Alberth 10:34:49 *** ntoskrnl has joined #openttd.dev 10:56:30 *** ntoskrnl has quit IRC 12:16:30 *** ntoskrnl has joined #openttd.dev 13:13:27 *** LordAro has joined #openttd.dev 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 #openttd.dev 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 #openttd.dev 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 ( https://secure.openttd.org/bugs/task/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 #openttd.dev 21:47:17 *** frosch123 has quit IRC 22:04:06 *** LordAro has quit IRC 22:44:38 *** Supercheese has joined #openttd.dev 23:03:01 *** Ristovski has quit IRC