Log for on 12th June 2013:
Times are UTC Toggle Colours
12:33:26  *** fonsinchen has quit IRC
12:34:09  *** fonsinchen has joined
12:40:55  *** fonsinchen has quit IRC
12:41:09  *** fonsinchen has joined
12:43:52  *** fonsinchen has quit IRC
12:44:09  *** fonsinchen has joined
12:47:58  *** fonsinchen has quit IRC
12:48:09  *** fonsinchen has joined
12:51:39  *** fonsinchen has quit IRC
12:52:09  *** fonsinchen has joined
12:52:09  *** ChanServ sets mode: +v fonsinchen
14:51:05  *** ntoskrnl has joined
15:36:39  *** ntoskrnl has quit IRC
15:36:43  *** ntoskrnl has joined
16:26:23  *** frosch123 has joined
16:26:23  *** ChanServ sets mode: +v frosch123
17:22:54  *** Alberth has joined
17:22:54  *** ChanServ sets mode: +v Alberth
17:33:04  *** ntoskrnl has quit IRC
17:38:24  *** Zuu has joined
17:38:24  *** ChanServ sets mode: +v Zuu
17:42:11  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25396 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:53:39  <Zuu> I have realized that I will not be able to hide the story/goal button when a GS is active. The reason for this is that in MP it is not possible for a client to know if a game script is active or not.
17:54:35  <Zuu> What I can do is to make the buttons mared as disabled when there is no content in the window.
17:54:50  <frosch123> does that mean the goal menu from some revisions ago was broken? :p
17:54:58  <frosch123> it conditionally hided the menu entry
17:55:17  <frosch123> anyway, imo hide the main menu buttons if there are no goals/pages then
17:55:26  <Zuu> As far as I understand Game::GetInstance() will return null for a MP client as the GS runs on the server.
17:56:32  * frosch123 compiles r25375 to check
17:57:24  <Zuu> I will try to do that. (I have been able to hide buttons, but need to tell the toolbar window to reduce its size so that he separators don't just use all the freed space)
17:58:48  <frosch123> yeah, r25375 is broken :p
17:59:08  <frosch123> luckily you fixed it already :)
18:02:12  <Zuu> :-)
18:07:11  <Rubidium> Zuu: can't you make it check on the existance of goals/stories?
18:07:24  <Zuu> Rubidium: That is what I will have to do.
18:08:06  <Zuu> Or make the story/goal DoCommand procs invalidate the main toolbar so that it doesn't have to check that at every repaint.
18:08:23  <Rubidium> yes, that'd be more efficient ;)
18:09:21  <Zuu> It actually set the disabled states of the existing buttons in the OnPaint method. However, removing a button will need to trigger resizing of the window which cost a bit more and may not even be a legal action from OnPaint.
18:10:38  <frosch123> i think you are doing it in various cases in onpaint
18:10:45  <frosch123> s/you/we/ :s
18:11:03  <frosch123> station gui wrt acceptance, town gui with extra text
18:11:21  <Zuu> Setting disabled state based on if a pointer is null or if a vector is empty shouldn't cost that much.
18:12:17  <Zuu> But I don't know any case where the window size is changed in OnPaint.
18:14:49  <frosch123> i guess best way to do it is like TownViewWindow
18:15:04  <frosch123> OnInvalidateData triggered by the commands
18:15:27  <frosch123> then check whether something changed, and call ReInit if needed
18:27:06  <Alberth> Zuu: station picker windows
18:27:34  <Alberth> the list of cargoes at the bottom causes changes in window size
18:28:10  <Alberth> if possible, avoiding such things is however preferred :)
18:35:06  <Zuu> Hmm, with the CountLines method that I commited for StoryBook it is now possible to predict how much vertical space a multi-line text with word warp will take.
18:46:02  <Zuu> Adds the Story API additions to the GS changelog:
18:47:04  <frosch123> isn't just "GSStoryPage" enough?
19:09:54  <Zuu> It could be enough. I saw it as a list of functions, but GSStoryPage may be enough in this case.
19:11:04  <Zuu> Alberth: Is it easy for a window instance to find the instance of a specific container class in the widget tree?
19:11:41  <Alberth> by widget number, trivial
19:11:49  <Zuu> Ok
19:12:05  <frosch123> looks like it is common that way. take a look at GSCargoMonitor, AIInfrastructure
19:12:28  <Alberth> this->GetWidget<WidgetClass>(number)    iirc
19:14:00  <Alberth> where the widget base class will always work :)
19:17:05  <Zuu> The NWidgetContainer baseclass do not feature a widget index parameter. Is it enough for a child class to call this->SetIndex in the constructor?
19:28:16  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25397 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
20:31:33  <Alberth> ho, container?
20:31:44  <Alberth> oh sorry, you mentioned that earlier too
20:32:04  <Alberth> what do you need a container for?
20:36:52  <Alberth> widget numbers are only for leaf widgets, containers are just invisible glue to keep a window together
20:38:35  *** orudge has joined
20:38:35  *** ChanServ sets mode: +v orudge
21:00:11  *** frosch123 has quit IRC
21:04:09  <Zuu> The main toolbar uses a custom container which does some magic. It is in the container code the selection of which widgets to draw. However the OnInvalidate is in the window. So the Window need to tell the container instance which widgets to never display independent of if they are included in a widget arrangement or not.
21:05:03  <Zuu> To make things worse I suspect that it is the window that needs to resize the window when a toolbar button is added/removed in situations where it is not constrained by the screen size.
21:06:37  <Zuu> Eg. both the window and the container need to be involved and know which buttons to hide if some icon is going to be hidden based on logic that I don't want to duplicate to have both in both classes.
21:08:04  <Alberth> resizing is pushed through the widget tree
21:08:44  <Alberth> the leaf widgets know their size and resize properties
21:09:10  <Alberth> the containers control how and where their child widgets should be put
21:09:28  <Rubidium> Zuu: can't you get the 'visible' state of the Window in GetButtonArrangement?
21:10:26  <Alberth> containers are totally free in deciding how they do that
21:10:29  <Zuu> The widgets in the main toolbar are as far as I can see not alligned using the standard procedures.
21:10:45  <Zuu> That is probably why it has a custom container.
21:11:03  <Alberth> eg the newgrf window has a custom container that switches between 2 and 3 columns
21:11:20  <Zuu> That container calculate #of buttons and #of spacers. and allign them up based on amount of width that the container is given.
21:11:40  <Alberth> every container does that
21:12:16  <Rubidium> Zuu: alternatively, can't you assume the 'root' of the widgets is the container?
21:12:17  <Zuu> In the case of the main toolbar the window need to shrink when a widget is made hidden. Otherwise it will look odd.
21:12:45  <Zuu> Rubidium: Possible, if it is easy to find the root widget.
21:13:06  <Alberth> a container can tell its minimal space requirements, and resize steps to its parent; the parent gives it some space, and the container distributes that space to it childs
21:13:34  <Rubidium> Zuu: w->nested_root
21:14:00  <Alberth> it may be easier to let the container find the window?
21:14:48  <Alberth> although I currently fail to see why the toolbar window needs to be involved in child layout of a container
21:15:17  <Zuu> Possible. I've given up for the moment and plays the game instead and wait for more inspiration to figure out how to solve it without doing an over-engineered solution.
21:16:11  <Zuu> Alberth: OnInvalidate is on the window, also I assume the container cannot ask the window to shrink?
21:17:10  <Alberth> hmm
21:17:49  <Alberth> what about a new object that manages what stuff is displayed and issues requests to the window?
21:18:58  <Alberth> although it may be quite the same as having the container manage it, I guess
21:19:13  <Rubidium> Zuu: doesn't w->nested_root give you the right container?
21:19:26  <Rubidium> (or rather this->nested_root)
21:20:01  <Alberth> root is a vertical container iirc
21:20:12  <Zuu> Rubidium: I don't know - I haven't tried yet
21:20:42  <Alberth> so you may  need to go down one more level
21:23:12  <Zuu> Thanks for the hints on where to look for a solution. I hope to continue with it some other day when I feel more motivated.
21:32:16  <Alberth> I solve such puzzles by pondering about them while traveling to and from work.
21:32:35  <Alberth> it takes anything from a few days to a few weeks :)
22:23:05  *** Alberth has left
23:09:59  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk