Log for on 24th March 2013:
Times are UTC Toggle Colours
00:29:45  *** Zuu has quit IRC
02:41:31  *** LordAro has quit IRC
07:29:55  *** Dewin has quit IRC
08:27:33  *** Zuu has joined
08:27:33  *** ChanServ sets mode: +v Zuu
09:07:49  *** Alberth has joined
09:07:49  *** ChanServ sets mode: +v Alberth
10:17:15  *** LordAro has joined
10:17:15  *** ChanServ sets mode: +v LordAro
10:41:57  *** frosch123 has joined
10:41:57  *** ChanServ sets mode: +v frosch123
11:02:15  *** ntoskrnl has joined
11:02:53  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25117 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
11:18:32  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25118 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
11:41:29  *** LordAro has quit IRC
11:52:32  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25119 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
12:04:11  *** LordAro has joined
12:04:11  *** ChanServ sets mode: +v LordAro
12:29:28  *** Supercheese has quit IRC
12:30:01  *** Supercheese has joined
13:10:06  *** Ristovski has joined
16:18:43  *** fonsinchen has joined
16:18:43  *** ChanServ sets mode: +v fonsinchen
16:40:40  <Zuu> I wonder, assuming that the story book is wanted, which path to choose. The problem at hand is that the story book will want to refer to industries towns etc. and have currently no way to allow user to click on some button to go there.
16:41:25  <Zuu> I think there is two ways to solve this. A) using click-on-text or B) to use stacked content. Eg. first some text, then a reference to a town and then some more text.
16:42:21  <frosch123> C) Text at the top, a list of locations (names) at the bottom
16:42:46  <Zuu> I have put some work into A) and have a working patch for encoding click areas into a char** string. However taking that into working with strings from GSes is some aditional work and more code that will need to be maintained.
16:45:23  <Zuu> I also had some plans for displaying answer options at the bottom or goals. Perhaps one could streamline it down to only allowing location references (and reference to goals) or answers on the same page.
16:45:29  <frosch123> subsidies have only two locations, but they solve it by scrolling to the 1st location, and if the viewport is already there, scroll to the 2nd
16:46:05  <frosch123> do you have a list of example use cases?
16:46:11  <frosch123> for me the discussion is quite abstract
16:46:22  <frosch123> i do not have any vision on how to use the feature
16:47:17  <Zuu> I think that the Story Book would be used by Beginner Tutorial, but also scenarios or GSes that need to tell a story or give some more text than a short sentence in the goal list.
16:48:45  <Zuu> In Beginner Tutorial I move the viewport for users (after they click on continue), this could be removed if the location is a button that can be clicked. Also having the location coded into the window and not an asynchronos response from the GS will give a more responsive UI.
16:49:08  <frosch123> do you have a usecase where you would need more than 2 locations for an item?
16:49:44  <Zuu> Transport X from any of industry A, B or C to D
16:50:01  <Zuu> Although that would be a goal then.
16:51:42  <frosch123> <- that would be how C would look like
16:52:17  <Zuu> Yes
16:52:25  <frosch123> So, maybe one can limit it to two locations per "item" on a page
16:52:35  <frosch123> the two locations would toggle like for subsidies
16:52:43  <frosch123> if you have more locations you would have to use more items
16:52:46  <Zuu> If a location is assumed to never span more than one line, the resizing code can be made quite quick which is otherwise a drawback with B)
16:53:07  <Zuu> (window resize)
16:53:40  <frosch123> i think multiple items per page sounds best up to now
16:53:53  <frosch123> you just need some method to sort them :p
16:54:06  <Zuu> Why allow more than one location per item, if you say that each line in your example is an item?
16:54:37  <Zuu> Eg. if you need more locations, just add an additional item.
16:56:30  <Zuu> Also, if the items are "location" and not "industry", "town", etc. that will keep the API slim and leave it up to a GS (library) to turn towns etc. into a tile index. Which in turn give them more freedom what to pass as location.
16:57:32  <frosch123> "Transport stuff from A to B" looks weird as two lines
16:59:03  <Zuu> The text above would say that, and the location list would then contain A and B.
16:59:33  <frosch123> ok, also an option :)
16:59:35  <Zuu> Eg. like the reference list of an article.
17:00:44  *** Lord_Aro has joined
17:01:34  *** LordAro is now known as Guest77
17:01:34  *** Lord_Aro is now known as LordAro
17:01:52  <Zuu> Or an Item can either be a Location or a reference to a Goal. In the later case it could show the literal goal text. Not sure if clicking on it will open the goal window or going to the goal location.
17:06:40  *** Guest77 has quit IRC
17:27:22  *** Lord_Aro has joined
17:33:50  *** LordAro has quit IRC
17:34:01  *** Lord_Aro is now known as LordAro
18:27:07  *** Lord_Aro has joined
18:33:00  *** LordAro has quit IRC
18:33:16  *** Ristovski has quit IRC
18:43:03  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25120 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:52:01  *** Dewin has joined
19:13:22  *** Lord_Aro is now known as LordAro
19:13:32  <Zuu> Comparison of alternative B and C:
19:14:47  <frosch123> with B it's up to the gs to decide whether it wants C, right?
19:14:53  <Zuu> Yes
19:15:46  <frosch123> that should be better, shouldn't it? :p
19:15:48  <Zuu> B is a bit more expansive in computation as it allows multiple multi-line text elements. Those cause resizing the window slow down OpenTTD debug build on my i7. The non-debug build works fine.
19:16:31  <Zuu> I like that B generalize text as a content item.
19:16:47  <frosch123> i don't get why B should be slower than C
19:16:59  <frosch123> it displays the same, just in different order
19:17:15  <Zuu> C only have two multi-line text elements (the title and the body text)
19:17:21  <Zuu> B could have 10 such items.
19:17:37  <frosch123> well, but you only need to recompute the height when the width changes
19:17:42  <frosch123> not when drawing and such
19:17:53  <Zuu> When the window is resized OpenTTD have to test-render all multi-line texts to compute the number of lines needed.
19:18:03  <Zuu> Correct
19:18:13  <frosch123> anyway, B looks better :)
19:18:48  <Zuu> I hope that release builds will not slow down when resizing a long page even on slower machines than 3,6 GHz i7. :-)
19:19:53  <Zuu> Or we will have to set a limit on X number of text items on a page.
19:20:38  <Alberth> several other windows just render the content, and keep track of the bottom. If it is below the window bottom, resize the window
19:21:58  <Zuu> This window uses a scrollbar. Does your method work with that?
19:22:52  <Zuu> Anyway, I will code B and hope that it is not too slow.
19:24:14  <Alberth> those windows do not have a scrollbar
19:28:22  <frosch123> Zuu: the console also does multiline stuff with scrolling
19:37:35  <frosch123> <- ai gui crashes when resizing it too small
19:38:19  <frosch123> i only noticed because my ottd was still switched to german after the gs text tests from yesterday
19:38:37  <frosch123> in english the button texts are shorter, so the editbox never is resized to 0 :p
19:39:11  <Zuu> Hmm, so this is a generic fix in src/widget.cpp. Good
19:40:07  <Zuu> I got random crashes with my patch until I figured out that not setting a drawing parameter in the callback for widget drawing parameter was the reason for them.
19:40:16  <frosch123> yeah, whenever you are able to make a window so small that a editbox becomes zero width
19:40:20  <Zuu> This only happened if there are zero pages.
19:41:38  <Zuu> For the drop down widget the drop down image appears to be hardcoded as 14 px wide. If not the game could possible crash if the image can grow large enough to not fit a narrow drop down widget.
19:49:48  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25121 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:57:11  *** Ristovski has joined
20:21:47  <Rubidium> ugh... the Tamil language rendering bug seems to be quite major
20:22:07  <frosch123> the flickering?
20:22:11  <Rubidium> for some reason they seem to render some characters over eachother, or at least at different offsets
20:22:44  <frosch123> yeah, it looked quite fancy
20:22:50  <Rubidium> (which we obviously do not do)
20:23:09  <Rubidium> is roughly what we need
20:23:49  <Rubidium> which layouts characters and tells you at which offsets you need to draw what glyph, or something like that
20:25:02  <Rubidium> the nuisance is that it makes splitting lines and the likes harder as well
20:25:31  <Rubidium> as we do not necessarily know where the glyphs are drawn
20:28:09  <Rubidium> on the other hand, it will give some mapping to the location where which glyph is going to be drawn which might be of interest for Zuu
20:28:26  <Rubidium> or at least this whole thing is going to mess up Zuu's work
20:31:10  <Zuu> Rubidium: For the moment I've dropped it in favor for another solution for the Story Book window. (see earlier discussions in this channel today)
20:32:08  <Zuu> Basically, I don't know if it is worth all work and then the time it takes to maintain click-on-text. Instead I examinate an alternative solution which might end up be equally good and easier to discover for users.
20:42:00  *** Alberth has left
20:51:19  <michi_cc> frosch123: Told you we need a text rendering engine :)
20:51:47  <frosch123> :)
20:55:07  <michi_cc> Rubidium:
20:58:03  <michi_cc> Needs more of the icu data though for UBreakIterator which at least in source filesystem size is another 3MB.
20:58:52  <michi_cc> There's also the HarfBuzz layout engine, but somebody seems to have forgotten the documentation...
20:59:16  *** LordAro has quit IRC
21:01:53  <Rubidium> looks interesting and might even remove some OpenTTD code
21:02:32  <Rubidium> and the question is whether the 3 MB is really noticable; the biggest problem is getting new libicu builds for Windows
21:03:39  <michi_cc> Is it? I built 5.1.1 a few hours ago and it worked right out of the box.
21:03:54  <frosch123> that class only needs 3.2
21:04:04  <frosch123> which one is the farm using?
21:04:19  <Rubidium> the farm is using the one from openttd_useful
21:04:21  <michi_cc> Okay, DLL version, didn't try the static lib yet.
21:04:25  <michi_cc> So 4.4 I think.
21:04:35  <frosch123> 4.4 is newer than 3.2 :p
21:04:51  *** fonsinchen has quit IRC
21:04:53  <Rubidium> which... for all intends and purposes is built with MSVC 2005 support
21:04:56  <michi_cc> No lib for the layout engine in the zip though.
21:05:06  <frosch123> oh, it's separate?
21:05:39  <michi_cc> Rubidium: I used 2010 for 5.1.1 as the project files are for that, didn't try with 2008.
21:05:55  <Rubidium> and the ones newer than the one used in openttd_useful are not building with 2005 anymore
21:06:43  <Rubidium> one *could* just drop 2005 and 2008 support, but then I'd say that the whole openttd_useful should be rebuild/updated to 2010
21:07:12  <frosch123> that means dropping directmusic and such, right?
21:07:25  <michi_cc> Compile farm is 2010 and I suspect the resulting static lib would also work with the 2008 libc. Not sure we really need to supply libs for 2005.
21:07:39  <michi_cc> frosch123: No.
21:09:59  <Rubidium> I do not know what the 2008 / 2010 library format differences are
21:10:19  <Rubidium> but 2005 doesn't like 2008, so I'd expect 2008 not liking 2010 either
21:13:18  <Rubidium> in any case, almost all the libraries are outdated too much for it to be funny
21:16:17  *** ntoskrnl has quit IRC
21:20:16  <Rubidium> anyhow... I do not have 2005 or 2008 anymore
21:21:24  <Rubidium> so I can't test whether it works, but if we can't deliver a openttd_useful for a particular (MSVC) compiler we shouldn't mark that version as supported anymore
21:22:07  <frosch123> i have an old copy of the windows farm, with 2008
21:22:20  <Rubidium> IMHO dropping 2005 and 2008 might not be such a big deal, especially if that means we could use more C++11 features
21:22:50  <frosch123> isn't using c++11 on linux a no-go?
21:23:04  <Rubidium> no idea
21:23:07  <frosch123> resp. on every system using shared libraries
21:23:43  <frosch123> the stl changes, and if some shared library uses std::vector<uint>
21:24:01  <frosch123> it will crash if the lib is compiled with c++11 and some other one is not
21:24:16  <Rubidium> hmm, that'd be a pity
21:25:57  <michi_cc> Rubidium: MSVC 2008 had no problems compiling OTTD with a static freetype made with 2010. freetype is C only though, so it would still be possible that a 2010 lib could have some conflicts with C++ library functions.
21:26:20  <Rubidium> I only tried ICU I think
21:26:45  <michi_cc> Well, the layout engine part of ICU is C++ ...
21:29:06  <michi_cc> We could possibly offer both the current useful zip (and maybe try to get/compile the ICU layout part as well) and an updated zip for 2010.
21:29:55  <Rubidium> then we need someone with MSVC 2005 to compile the old version of ICU
21:32:35  <michi_cc> "Acquiring" it isn't really a problem and a VM should do I hope.
21:32:45  <frosch123> <- oh, apparently gcc decided to not strictly implement c++11 in favour of keeping api compatibility
21:36:54  <Rubidium> I then wonder when they're going to do that ABI change
21:38:22  <frosch123> well, apparently we can blame it on the distros
21:38:45  <frosch123> and if we make sure that the generic binary links all c++ libs statically, and only pure c ones dynamically
21:38:50  <frosch123> we should be safe
21:57:01  *** Ristovski has quit IRC
22:54:28  *** Zuu has quit IRC
22:56:17  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk