IRC logs for #openttd.dev on OFTC at 2013-06-29
⏴ go to previous day
02:00:57 *** Belugas has joined #openttd.dev
02:00:57 *** ChanServ sets mode: +v Belugas
07:17:22 *** Alberth has joined #openttd.dev
07:17:22 *** ChanServ sets mode: +v Alberth
08:49:34 *** ntoskrnl has joined #openttd.dev
09:01:15 *** frosch123 has joined #openttd.dev
09:01:15 *** ChanServ sets mode: +v frosch123
09:32:55 <Alberth> pretty much indeed :)
09:33:15 <Alberth> it makes you wonder whether we should just remove all forms of units :p
09:35:26 <Rubidium> frosch123: oh, the kgf?
09:35:50 *** Ristovski has joined #openttd.dev
09:36:04 <frosch123> it's "kp" in german
09:36:06 <Rubidium> next question will undoubtedly be long tons, but there's a good reason for short tons: 1 short ton = 2000 lbf
09:38:44 <frosch123> hmm, oh wait, kgf and kp are different actually, aren't they? 1 kgf = 2 kp?
09:39:55 <Rubidium> frosch123: the English wiki implies they're the same
09:40:00 <planetmaker> 1 Kilopond is the weight force of 1kg at normal acceleration
09:40:10 <frosch123> [11:36] <Rubidium> next question will undoubtedly be long tons, but there's a good reason for short tons: 1 short ton = 2000 lbf <- anyway, the answer to that is newunits newgrf support. how else do you want to support prussian ells propertly in cets?
09:40:29 <frosch123> planetmaker: ok, i was shortly worries that it might rely on pounds instead of kg
09:40:57 <planetmaker> needed to check, too :-)
09:41:31 <planetmaker> hm... forces in Dyn... also *very* nice
09:41:44 <Alberth> patch seems fine to me
09:42:31 <Rubidium> too bad I can't find a nice way to split this patch up
09:43:12 <Rubidium> (except the following patch removing loads of strings)
09:43:23 <frosch123> you can add a second commit to remove old strings, including other languages
09:44:39 <Rubidium> true, though relatively insignificant
12:04:14 <frosch123> no idea what the "+5" means though
12:08:03 <Rubidium> it's for the ', ' and '\0' (or possibly other characters)
13:43:02 *** Zuu has joined #openttd.dev
13:58:29 *** ntoskrnl has joined #openttd.dev
14:15:31 *** ntoskrnl11 has joined #openttd.dev
14:42:28 <Zuu> Eg. use the page elemnet id, and not the page id to update a page element :-)
14:43:48 <Alberth> Zuu seems to like complicated long ?: parameters :)
14:44:37 <Zuu> Yes its some paremeters there :-)
14:45:00 <Zuu> The parameters to the do cammand are used differently depneding on the type of page element.
14:45:44 <Zuu> There is one uint32 for referenced objects (goals, tiles) and a text parameter for page elements that display a text (tiles, text)
14:46:41 <Alberth> I often create temp variables in such a case
14:59:57 *** ntoskrnl has joined #openttd.dev
15:21:41 *** ntoskrnl11 has joined #openttd.dev
15:27:50 *** ntoskrnl has joined #openttd.dev
15:34:08 <Alberth> that issue is not about a crash, but about not displaying progress text
15:35:13 <Alberth> merging both widgets makes sure you use all available space before you shorten text
15:36:44 <Alberth> whether to shorten the text or the progress is debatable, I can see shortening text as a valid alternative
15:37:36 <Zuu> Alberth: The crash I refered to was the one that Idioty wrote about in his comment.
15:38:43 <Alberth> perhaps string handling was a bit broken while he tried, Rb has been rewriting that code
15:39:00 <Zuu> My first guess on a solution before I saw your patch was that OnInvalidate need to re-calculate the min widget sizes more agressively.
15:40:19 <Alberth> that's an alternative, and it keeps 2 columns at all times, which can be seen as an advantage
15:41:34 <Zuu> Not sure if that solution will redistribute width from the progress widget to the text widget in case a GS shortens the longest progress text.
15:41:55 <Zuu> Or if it can only solve the problem in the bug report.
15:42:13 <Alberth> shortening is not bad, you want just to display all text at all times
15:43:22 <Alberth> another alternative is to run a length check while you draw
15:43:55 <Alberth> you can even do a pre-calculation about required width
15:48:08 <Alberth> so feel free to discard my solution :)
16:02:58 <Rubidium> that crash was on OS X, so someone with OS X should check whether it crashes
16:03:14 <Rubidium> though... no specific version was given
16:03:48 <Rubidium> and he didn't report the crash
16:08:23 <Alberth> on starting openttd, the gs goals window does not open, so the changes were never executed as far as I can see
16:16:18 <Zuu> I tried ResizeWindow(this, 0, 0, false) which is hinted as a cheaper method in the Doxygen comment of ReInit.
16:16:51 <Zuu> ResizeWindow didn't solve the problem and looking at it, it doesn't seem to update the min sizes.
16:18:00 <Rubidium> what kind of content can the progress have? I've seen percentages, but is that all?
16:18:56 <Rubidium> if it's just percentages, then you could determine the width of 100% and minimum. If it's not, then things are trickier
16:19:27 <Zuu> Rubidium: It could contain eg. "5/11"
16:19:40 <Rubidium> alternatively you could first draw the progress with 100% of the whole line + right alignment and then use the rest for the progress description
16:20:11 <Rubidium> DrawString gives you the x location where it 'ended', which for right alignment is it's left side
16:20:15 <Zuu> Initially I used an integer to store a percentage value, but got complaints that it was too limited, so now progress is a string that ultimately can hold quite a lot of content if someone wants to.
16:20:46 <Rubidium> so it's hard, to impossible to accurately determine the minimum size
16:21:16 <Rubidium> whereas it's easier-ish for the infrastructure window
16:21:37 <Rubidium> just say: okay, start with 1000 and increase if we go over it
16:22:00 <Rubidium> so I'd use a different method of drawing for the progress window
16:26:20 <Zuu> How is it hard to determine the minimum size? Just iterate over all goals and calculate the width of the progress text. ?
16:27:22 <Zuu> I do this only when the progress text is updated. Or do you also take into account that someone may use {VEHICLE} in the progress text and then rename the vehicle?
16:30:06 <Zuu> In that respect, also the story book is then broken. IIRC, it compute the size requirements when the window is updated using DoCommands or is resized. However, if content change size between two drawing operations, I don't think it detects that.
16:48:56 <Alberth> resizing of a window does indeed not recompute minimal size of anything
16:50:27 <Alberth> popular techniques to fix these things are either establish a maximum length beforehand, or ReInit() when you detect overflow, usually while painting the window
16:51:36 <Alberth> resize is somewhat of a special case, but works only for windows that are not resizable by the user
16:52:17 <Alberth> basically the area you want to control takes the extra space, so when you detect overflow, you resize the window to compensate
16:55:02 <Alberth> the technique you mention above (let go of all widget borders, and paint it yourself at the canvas is also a valid option)
19:50:52 *** Alberth has left #openttd.dev
20:35:00 *** Ristovski has joined #openttd.dev
continue to next day ⏵