Log for on 14th September 2013:
Times are UTC Toggle Colours
07:56:33  *** LordAro has joined
07:56:33  *** ChanServ sets mode: +v LordAro
08:04:49  *** Zuu has joined
08:04:49  *** ChanServ sets mode: +v Zuu
08:14:25  *** Alberth has joined
08:14:25  *** ChanServ sets mode: +v Alberth
08:22:20  <LordAro> Rubidium: out of interest, what's the purpose of r24638 ? there's no reference to OPENTTD_MSU anywhere other than in those files...
08:23:59  <Rubidium> tcp_content.cpp is used by the contentserver (in MasterServer_Updater package -> MSU)
08:24:26  <Rubidium> since I didn't fancy add the whole of OpenTTD to those binaries, the stuff that isn't needed there is 'ignored'
08:25:19  <LordAro> i thought it was something like that - i just didn't find any reference to it in (OTTD's) build files
08:41:32  <LordAro> on a similar but not totally unrelated subject, can i get a review of this?
08:41:47  <LordAro> adds the ability to wrap text in textfile windows
08:43:37  <LordAro> the only problem is that it can't show part of the wrapped line, so heavily wrapped lines make the scrollbar jump about significantly
08:43:42  <LordAro> not sure how to fix that
08:44:24  <Rubidium> make the scrollbar work on pixels instead of logical lines in the file
08:45:16  <Rubidium> though I wonder when to and when not to line wrap, and whether that decision should be made automatically
08:47:12  <Rubidium> and if you line wrap something that is already line wrapped by the text editor, it might look very odd which'll cause (valid-ish) requests about it ignoring those 'text editor autowrapping' and then it's... well can of worms
08:47:32  <Rubidium> though for those files that aren't wrapped it would make sense
08:48:06  <Rubidium> don't have the time to properly test it though
08:48:22  <LordAro> i have no idea how to automagically wrap lines without just setting some arbitary length
08:48:23  <Rubidium> see the 60 open bug reports
08:48:28  <LordAro> D:
08:52:52  *** ntoskrnl has joined
08:57:08  <Zuu> If a string parameter changes length from one draw to another, the Story Book do not update the scrollbar with the new content height. This patch fixes this:
08:58:05  <LordAro> "<Rubidium> make the scrollbar work on pixels instead of logical lines in the file" <-- umm, how? :L (roughly, is there a function or something?)
09:00:39  <Zuu> LordAro: I changed the story book yesterday from line based scroll to pixel based scrolll.
09:01:03  <Alberth> 1 unit in the scrollbar is 1 pixel instead of 1 line, thus one line is 10 unit or so (ie 'text height' units)
09:01:36  <Zuu> You can still set a scroll step to a text line (10 pixles with the default font) so that the scroll wheel and scroll buttons work as before.
09:02:10  <Zuu> The only user difference is that when you drag the scrollbar you can move the content in steps by one pixel instead of a line height.
09:02:51  <Zuu> In the code though it makes the life easier, esepecially if you deal with strings that can contain eg {BIG_FONT} half way through the text.
09:02:55  * LordAro looks
09:03:32  <Zuu>
09:09:50  <LordAro> wait, no, the problem here isn't todo with the scrollbar jumping wildly, it's that the whole line stops getting drawn when the scrollbar 'starts to move past it' (hope i'm making some sense)
09:10:36  <Alberth> that sounds like a bug to me :)
09:13:08  <LordAro> i need to work out...something about the number of lines, i'm just not sure what
09:13:38  <Alberth> but there are no lines, just pixels
09:13:48  <LordAro> aahhhh, the logic is making my head hurt D:
09:14:09  <Zuu> <LordAro> on a similar but not totally unrelated subject, can i get a review of this?  <------ Why do you initialize the scrollbars in DrawWidget?
09:14:20  <LordAro> i need the width
09:14:32  <LordAro> i know, it's  not brilliant
09:14:43  <Zuu> Hmm, though there is a split there - so I could be wrong about the scope
09:15:46  <Zuu> +	this->hscroll->SetStepSize(10);  <---- In the constructor: this->vscroll->SetStepSize(FONT_HEIGHT_NORMAL);
09:15:58  <Zuu> No need to set this more than once
09:17:16  <Zuu> The Story Book don't initialize the scrollbar in DrawWidget, yet the vertical height of the content depend on the width.
09:18:49  <Zuu> It is probably better to do this in OnPaint if you need. Then you can detect content height/width changes, update the scrollbar count and invalidate the widgets that need to be re-painted due to this.
09:19:31  <Zuu> Eg. vscroll->SetCount do not mark the scrollbar as dirty.
09:20:20  <Zuu> If the window core decide to paint the scroolbar before the panel, you will paint the scrollbar using the old Count value with the structure that you use.
09:25:52  <LordAro> hmm, excuse me while i base my work around yours :)
09:32:09  <Zuu> You're welcome. This is open source :-)
09:34:29  *** Supercheese has quit IRC
09:42:24  <Alberth> open source is so much fun, /me trying to get rid of OnPaint functions, other devs adding them again :p
09:43:54  <Alberth> in general, I consider it better if you run computations outside the paint loop, but eg when you resize the window or change the text
09:45:12  <Zuu> A problem is that text with eg. {COMPANY}, {TOWN} etc. can change length from one paint to another without there being any call to invalidate the window.
09:45:47  <Zuu> Otherwise I agree that you should minimize the amount of computations that happen in OnPaint or DrawWidget.
09:47:56  <Alberth> add such calls?
09:50:24  <LordAro> Zuu: am i correct in thinking your story page window doesn't support rtl text (very well) ? :p
09:51:08  <Zuu> I think I have tested it with rtl, but it was possible some time ago.
09:51:39  <Zuu> Anything in particular that you think is broken with respect to rtl?
09:52:25  <LordAro> i dunno, but my window has explicit rtl support :) ( textfile_gui.cpp:93 )
09:54:06  <Zuu> The only thing I can think of is that the goal/location icons are possible not located on the opposite side with RTL. Other things shouldn't need explicit support.
09:55:04  <LordAro> even though you're aligning text with "SA_TOP | SA_LEFT" ?
09:55:32  <Zuu> It depends on if SA_LEFT is mirrowed automatically or not.
09:56:07  <LordAro> could get confusing if it is :)
09:57:12  <Zuu> To do it right, you would need to know if the GS is translated to RTL or not. Not if the game language is RTL or not.
09:57:36  <Zuu> Most GSes are not translated to more than at most 3-4 languages.
10:01:10  <LordAro> you know as well as i do the fact that the content doesn't exist doesn't mean you shouldn't support it :p
10:02:36  <Alberth> LordAro: extend eints, and the problem will pop up all by itself :p
10:02:59  <LordAro> no thanks :)
10:03:10  <LordAro> i wouldn't want to put you out of a job :p
10:12:27  *** frosch123 has joined
10:12:27  *** ChanServ sets mode: +v frosch123
10:26:29  <LordAro> ok, take 2:
10:26:48  <LordAro> vertical scrollbar (when wrapped) is oddly long, but i think everything else is fixed :)
10:27:14  <LordAro> and of course, i'm not sure why the scrollbar is that long and would like one of you lot to tell me where i've gone wrong :)
10:42:08  <Zuu> vscroll->SetCount() is called with line height if line wrap is dissabled. If line wrap is enabled it is given a pixel height.
10:45:21  <LordAro> ok, now they're both too long :p
10:47:20  <Zuu> resize->height = FONT_HEIGHT_MONO; <--- try changing that one to resize->height = 1;
10:48:29  <LordAro> that's it :)
10:49:05  <Zuu> That one tell the scrollbar the height of one item/line. For pixel based scroll a "line" need to be one pixel.
10:49:36  <LordAro> ok, i think that's everything
10:50:00  <LordAro> thanks very much :) (esp for your story_gui.cpp code :) )
10:50:21  <LordAro> i'll tidy up, then make a fs task (or just post it here? )
10:56:57  <LordAro> where should documentation be for SetupScrollbars() ? declaration or definition?
11:01:52  <frosch123> documentation is always next to the implementation in ottd
11:02:35  <frosch123> so if you see a patch changing behaviour of a function, you can directly see whether it also changes the docs above it
11:02:50  <LordAro> good, i guessed correctly :)
11:07:02  <LordAro> right, good. see
11:07:25  * LordAro also takes this time to poke people about :p
12:46:12  <Zuu> With the two new main toolbar buttons for goal/story the main toolbar will show less of the buttons before switching to layered toolbar. This patch adds a new main toolbar arrangement such that the main toolbar is split earlier and still provide access to goal/story.
12:47:35  <Zuu> A drawback with this patch is that some users with some screen size will now get a split toolbar while they before had a non-split toolbar. That said, if it is a touch user, it may still like to have buttons that can be pointed at with your fingers (which is what this patch improve)
12:51:14  * Alberth wonders about a double row of buttons
12:52:42  <Alberth> otherwise, adding an extra level is probably ok
13:25:00  <LordAro> toolbar_gui.cpp looks like it could do with some doxymentation :)
13:26:10  <LordAro> some coding style fixes too, i think
13:27:08  <Zuu> It could do with a rewrite too
13:27:49  <LordAro> that too :)
13:27:54  <LordAro> some outdated stuff in there
13:28:00  <Zuu> I tried to make goal/story buttons dissappear instead of making them just disabled, but that was quite hard to accomplish with the current structure.
13:28:56  <Zuu> If it is outdated, it can just be removed.
13:29:25  <LordAro> i mean an outdated way of doing things - it's still necessary
13:30:22  <Zuu> It has lots of magic constants etc. :-)
13:30:59  <Zuu> At least in GetButtonArrangement
13:32:05  <LordAro> i saw a couple of tables that used spaces for indentation :)
17:22:53  *** Supercheese has joined
17:53:49  *** ntoskrnl has quit IRC
21:02:05  *** Alberth has left
21:51:27  *** Zuu has quit IRC
22:14:45  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk