Times are UTC Toggle Colours
12:33:26 *** fonsinchen has quit IRC 12:34:09 *** fonsinchen has joined #openttd.dev 12:40:55 *** fonsinchen has quit IRC 12:41:09 *** fonsinchen has joined #openttd.dev 12:43:52 *** fonsinchen has quit IRC 12:44:09 *** fonsinchen has joined #openttd.dev 12:47:58 *** fonsinchen has quit IRC 12:48:09 *** fonsinchen has joined #openttd.dev 12:51:39 *** fonsinchen has quit IRC 12:52:09 *** fonsinchen has joined #openttd.dev 12:52:09 *** ChanServ sets mode: +v fonsinchen 14:51:05 *** ntoskrnl has joined #openttd.dev 15:36:39 *** ntoskrnl has quit IRC 15:36:43 *** ntoskrnl has joined #openttd.dev 16:26:23 *** frosch123 has joined #openttd.dev 16:26:23 *** ChanServ sets mode: +v frosch123 17:22:54 *** Alberth has joined #openttd.dev 17:22:54 *** ChanServ sets mode: +v Alberth 17:33:04 *** ntoskrnl has quit IRC 17:38:24 *** Zuu has joined #openttd.dev 17:38:24 *** ChanServ sets mode: +v Zuu 17:42:11 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25396 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://devs.openttd.org/~zuu/goal-gui/64.4-qs-changelog.patch 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 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 #openttd.dev 23:09:59 *** Zuu has quit IRC