IRC logs for #openttd.dev on OFTC at 2012-11-03
⏴ go to previous day
04:23:19 *** FLHerne has joined #openttd.dev
07:25:35 *** andythenorth has joined #openttd.dev
07:25:35 *** ChanServ sets mode: +v andythenorth
08:02:42 *** andythenorth has joined #openttd.dev
08:02:42 *** ChanServ sets mode: +v andythenorth
08:40:53 *** Zuu has joined #openttd.dev
09:33:11 *** Alberth has joined #openttd.dev
09:33:11 *** ChanServ sets mode: +v Alberth
10:39:21 *** Eagle_Rainbow has joined #openttd.dev
10:39:21 *** ChanServ sets mode: +v Eagle_Rainbow
10:40:38 <Eagle_Rainbow> Is it somehow possible to make an WWT_TEXT aligned to the right in its bounding box?
10:41:30 <Zuu> Not sure. Try to think of an example that can be looked up how it is implemented.
10:41:41 <Zuu> Another option is to use a panel and draw the text yourself.
10:42:15 <Eagle_Rainbow> Mmh... also an option...
10:42:21 <Eagle_Rainbow> Will have a look
10:42:58 <Zuu> In eg. the infrastructure maintanaince window, there are a matrix of panels to get spacing rigth, but IIRC all texs is then drawn in the OnDraw method.
10:43:11 <Zuu> Or OnPaint or what the name now is in OpenTTD.
10:44:34 <Zuu> Mind that if a RTL language is used you probably want to revert thet align.
10:45:20 <Zuu> There are examples of special handling of RTL when manual drawing on panels is used.
10:45:36 <Eagle_Rainbow> do you have one in your mind?
10:45:50 * Eagle_Rainbow is just clicking through all screens to find one where right alignment is used
10:45:53 <Zuu> I think the infra maintanence does it.
10:46:22 <Zuu> Not sure if it dose right align, but IIRC it has special handling of RTL
10:46:32 <Zuu> Another thing may be the economy window.
10:46:48 <Zuu> There probably the economy figures are aligned to the right
10:46:59 <Eagle_Rainbow> I just found the "detailed performance rating" screen
10:47:08 <Eagle_Rainbow> there values are right aligned at least...
10:50:08 <Eagle_Rainbow> Ah, I found what you meant: company_gui.cpp:1718
10:51:18 <Eagle_Rainbow> which is strange..
10:51:46 <Eagle_Rainbow> Wouldn't the places of the element swap its position as well?
10:55:11 <Zuu> Just checked, the infra mainatanence doesn't right align the numbers even if numbers really should be right aligned for readability.
10:56:56 <Zuu> My guess is that the widget system make widget swap left-right order when you switch to a RTL-language. But I have't read up enough to find a proof for that guess.
10:58:32 <Eagle_Rainbow> ok... if I am using a panel then, it should work out, if I am doing the same padding trick as with the Infrastructure Maint screen
10:59:29 <Eagle_Rainbow> Uh... well, this gonna become ugly...
10:59:57 <Eagle_Rainbow> (in the coding); on the other hand, the current state is ugly on the UI - so what's better ;)
11:00:36 *** frosch123 has joined #openttd.dev
11:00:36 *** ChanServ sets mode: +v frosch123
11:03:44 <Zuu> Yes, panels are somewhat dirty to work with rather than just plopping a widget.
11:04:22 <frosch123> do you want to put the WWT_TEXT to the right side of its container? or do you want to right-align the text in the WWT_TEXT widget?
11:04:54 <Eagle_Rainbow> I want to right align its text...
11:05:00 <Zuu> hmm, I was just starting to wonder if you could tell the WWT_TEXT to not grow to fill its space and then ask the WWT_TEXT to right align itself in its container.
11:05:10 <Eagle_Rainbow> Or perhaps there is a better idea, lemme explain my problem in general
11:05:42 <Eagle_Rainbow> I have swapped out the player's name from the network game list screen to a query string.
11:05:54 <frosch123> currently WWT_TEXT only allows rtl alignment
11:06:03 <frosch123> neither force_right or center
11:06:24 <Eagle_Rainbow> Instead, I have reused the existing WWT_TEXT to not just read "Player name:", but to read "Player name: {RAW_STRING}"
11:06:58 <Eagle_Rainbow> However, due to this, the GUI framework either reserves a huge gap (for the rest of the RAW_STRING), if I set SetResize
11:07:27 <Eagle_Rainbow> or it does not rerenders the screen when the name gets longer (and abbreviates it with ...)
11:07:48 <Eagle_Rainbow> My current approach right now is to go for the first approach but make it right-aligned...
11:07:58 <Eagle_Rainbow> or can I enforce to redo the layouting?
11:08:15 <frosch123> you could, but resizing the window would look weird when changing the name :p
11:08:36 <Zuu> There is a window callback that allow you to specify min sizes of widgets.
11:09:19 <Eagle_Rainbow> Zuu, Thought so as well, but that callback doesn't seem to be called when String parameters change...
11:09:42 <Eagle_Rainbow> frosch123, yeah, that also sounds like overkill to me...
11:09:42 <frosch123> it is only called when the window is resized, or reinitialised
11:10:01 <frosch123> but why don't you want to just left align the name?
11:10:23 <frosch123> to align it with the server details panel?
11:10:54 <frosch123> wouldn't that look better? instead of some floating "Player name:" ?
11:11:01 <Eagle_Rainbow> Well, it looks quite ugly...
11:11:22 <Eagle_Rainbow> as the variable value apparently can get quite huge...
11:11:28 <Eagle_Rainbow> where can I upload it?
11:11:55 <frosch123> we have no pastebin for images yet
11:12:01 <Zuu> I think you might be able to invalidate the window when the player name changes and in OnInvalidate force a size update.
11:12:17 <frosch123> Zuu: that would change the size of the whole window
11:12:25 <frosch123> which will look silly
11:12:43 <Zuu> frosch123: Yes if the available space is too low, the window would resize yes.
11:13:01 <Eagle_Rainbow> Well, space seems to be available...
11:13:17 <Eagle_Rainbow> But still, sounds like a workaround to me :-|
11:13:41 *** andythenorth has joined #openttd.dev
11:13:41 *** ChanServ sets mode: +v andythenorth
11:14:25 <Zuu> The OpenTTD GUI isn't really that much atomic widgets as one may guess a GUI would be built of. Instead often you need to add window-level code in window callbacks to fix things up.
11:16:39 <frosch123> ah, so you do not align it with the panel
11:16:42 <Zuu> I think you can in the widget list tell that your left part (filter) will grow and use the available space.
11:16:49 <frosch123> since it is too long
11:17:26 <Eagle_Rainbow> Zuu, yeah, that's clear, but the player's name is the problem...
11:17:47 <Eagle_Rainbow> frosch123, yep... the player's name may get huge :(
11:17:59 <Zuu> Obviously the right part need to inform the widgetsystem somehow how large its minmum width is.
11:18:31 <frosch123> well, i guess there are two options then
11:18:35 <Zuu> Eg. so that the filter text box shrink when the player name grows.
11:18:47 <Zuu> If that is a desirable gui.
11:18:50 <frosch123> 1) either add a new widget attribute for WWT_TEXT to make stuff reverse-aligned
11:19:06 <frosch123> 2) or use a WWT_EMPTY and use custom drawing in DrawWidget
11:19:30 <Eagle_Rainbow> ok, 2) reassembles to what Zuu already suggested - but then we get into trouble with RTL languages
11:19:53 <Eagle_Rainbow> and 1) is another overkill, as this would be then the "sub-sub" patch for the network filter thingy :)
11:19:59 <frosch123> DrawString handles such stuff on its own
11:20:24 <Eagle_Rainbow> ah, you mean as we have only one label that we have to print...
11:20:34 <Eagle_Rainbow> ... sorry, draw....
11:20:59 <frosch123> just define a size for the WWT_EMPTY in the UpdateWidgetSize, and then pass the whole widget bounds to DrawString in DrawWidgets
11:21:13 <frosch123> you can tell DrawString to draw the string reverse-aligned
11:21:19 <frosch123> i.e. right for ltr and left for rtl
11:21:55 <Eagle_Rainbow> mmmh.. in combination with the button next to it, this could look ugly in RTL languages
11:22:11 <Eagle_Rainbow> but you are right... this sounds like the smallest issue...
11:22:21 <frosch123> for rtl the button is on the left border of the window, and the playername would be left aligned next to it
11:22:24 <frosch123> it just looks the same
11:22:43 <Eagle_Rainbow> so, the GUI framework also mirrors all widgets? wow....
11:23:07 <frosch123> if you haven't seen it, you should switch to arabic or hebrew for once :)
11:23:29 <frosch123> though you should remember where the language dropdown is, else you might have a hard time to switch back :p
11:23:30 <Eagle_Rainbow> That I'll do sometime - even if it's just for entertainment...
11:23:44 <Eagle_Rainbow> or rm openttd.cfg
11:24:32 <Eagle_Rainbow> Then I'll try that one... You'll see my results for sure ;)
12:34:16 *** fonsinchen has joined #openttd.dev
12:34:17 *** ChanServ sets mode: +v fonsinchen
14:19:09 *** andythenorth has joined #openttd.dev
14:19:09 *** ChanServ sets mode: +v andythenorth
15:12:40 *** Knogle has joined #openttd.dev
15:38:17 *** LordAro has joined #openttd.dev
15:38:17 *** ChanServ sets mode: +v LordAro
15:48:03 *** Lord_Aro has joined #openttd.dev
15:48:03 *** LordAro is now known as Guest4351
15:48:03 *** ChanServ sets mode: +v Lord_Aro
15:48:03 *** Lord_Aro is now known as LordAro
15:51:00 * LordAro doesn't like wireless connections
15:53:05 <LordAro> ... and that was the wwrong channel, but meh
15:54:14 <frosch123> it compiles and does not crash for me
15:54:21 <frosch123> but i wonder whether that works with every compiler :o
16:34:54 *** Zuu has joined #openttd.dev
16:35:33 *** Knogle has joined #openttd.dev
17:22:57 *** andythenorth has joined #openttd.dev
17:22:57 *** ChanServ sets mode: +v andythenorth
17:32:01 *** Zuu has joined #openttd.dev
17:55:03 *** LordAro has joined #openttd.dev
17:55:03 *** ChanServ sets mode: +v LordAro
18:01:41 *** Supercheese has joined #openttd.dev
18:38:35 <Alberth> is that something I should try?
18:39:52 <frosch123> nah, i just wondered whether someone knows by heart whether the specs define any initialisation order on static variables
18:41:07 <frosch123> or maybe someone has a better idea how initialize a static const-ish map with items :)
18:42:40 <Alberth> use of the comma operator does not seem ideal indeed :)
18:43:15 <Alberth> I would hide it in a function, and initialize on first access
18:43:33 <frosch123> yeah, might try that
18:51:30 *** andythenorth has joined #openttd.dev
18:51:31 *** ChanServ sets mode: +v andythenorth
19:31:42 *** FLHerne has joined #openttd.dev
19:48:55 *** Eagle_Rainbow has joined #openttd.dev
19:48:55 *** ChanServ sets mode: +v Eagle_Rainbow
19:49:33 <Eagle_Rainbow> I think, I stumbled over something where an additional set of eyes could be helpful.
19:51:07 <Eagle_Rainbow> I just debugged an issue with a flickering scrollbar in the network game list when I had to set a breakpoint in the Scrollbar::SetCount() method. Having ensured that it is not being called by some *Tick() method, still I was bombarded with triggered breakpoints continously. Even later, when receiving the responses from all servers on their game information, the breakpoint was reached countlessly making debugging close
19:51:48 <Eagle_Rainbow> Digging a bit deeper from where this came, I stumbled over void Window::InvalidateData(int data, bool gui_scope) in window.cpp:2720.
19:52:10 <Eagle_Rainbow> void Window::InvalidateData(int data, bool gui_scope)
19:52:10 <Eagle_Rainbow> this->SetDirty();
19:52:10 <Eagle_Rainbow> if (!gui_scope) {
19:52:10 <Eagle_Rainbow> /* Schedule GUI-scope invalidation for next redraw. */
19:52:13 <Eagle_Rainbow> *this->scheduled_invalidation_data.Append() = data;
19:52:17 <Eagle_Rainbow> this->OnInvalidateData(data, gui_scope);
19:52:23 <Alberth> i'd expect you get a zillion updates on running servers
19:52:30 <Eagle_Rainbow> which I think is bad
19:52:31 <Alberth> please use a pastebin next time
19:53:57 <frosch123> what is your question?
19:54:40 <Eagle_Rainbow> a) if we are not in gui_scope, we still call OnInvalidateData() immediately, which then later on is repeated due to method void Window::ProcessScheduledInvalidations()
19:54:42 <frosch123> the metaserver connection will trigger InvalidateData whenever there is something new
19:55:17 <frosch123> Window::OnInvalidateData can evaluate gui_scope and skip stuff
19:55:25 <Eagle_Rainbow> b) redundant calls to InvalidateData may add redundant entries in the SmallVector this->scheduled_invalidation_data, causing that no aggregation of calls is happening (even for the same value of data)
19:55:51 <frosch123> aggregation might be very wrong in some cases
19:56:39 <frosch123> some windows have do to stuff in command scope, while other stuff must not be done in command scope
19:56:46 <frosch123> it is up to the window to know what it may do when
19:56:57 <Eagle_Rainbow> mmh... not very self-explanatory to me, but ok
19:58:09 <frosch123> take a look at the documentation of InvalidateWindowData()
19:58:31 <frosch123> the other places link to that, or at least some
19:59:17 <Alberth> as I understand it, commands send updates to the window, which may in turn perform commands. The latter may break due to a command being in progress. the invalidate is broken in two pieces to prevent that from happening
20:00:09 <frosch123> anyway, for the server window the difference is quite mood
20:00:21 <frosch123> you can just do everything in gui_scope there
20:00:29 <frosch123> and just do "if (!gui_scope) return"
20:01:28 <frosch123> but current NetworkGameWindow::OnInvalidateData only sets a bit flag anyway
20:02:00 <Eagle_Rainbow> yeah, but I need to go in there as well... but it's ok that I'll execute it only on gui_scope = true
20:02:52 <frosch123> mind that "this->servers.ForceRebuild();" only sets a flag, that rebuilding is needed
20:02:56 <frosch123> it is not done immediately
20:43:44 <Eagle_Rainbow> frosch123, concerning the GUI Rearragement: Is there already a clear understanding which setting belongs to which category (basic/adv./expert)?
20:44:06 <Eagle_Rainbow> I mean, something like a list?
20:44:52 <frosch123> that will likely take multiple iterations
20:45:05 <frosch123> there are some examples on the wiki
20:45:15 <frosch123> to give a general idea, but there is nothing beyond that
20:45:31 <Eagle_Rainbow> what about that I start creating a first draft proposal which then can be debated?
20:46:09 <Eagle_Rainbow> what do you think - directly into the wiki?
20:46:38 <Eagle_Rainbow> or should we keep it offline, first of all...
20:46:39 <frosch123> or directly as diff
20:46:43 <frosch123> might be a bit long on the wiki
20:47:26 <Eagle_Rainbow> well, if it's a matter of debate anyhow, it's always hard to do that directly in code...
20:47:46 <Eagle_Rainbow> but I don't mind also going to coding directly...
20:48:21 <frosch123> well, for the helptexts we also had the code first, and then polished the actual texts
20:48:48 <Eagle_Rainbow> again, I see, it's a matter of taste :)
20:49:39 <frosch123> well, there are lots of settings
20:49:55 <Eagle_Rainbow> ok, I'll go for the code...
20:49:57 <frosch123> classifying them all is quite boring, transfering the classfication between wiki and code even more :p
20:50:34 <Eagle_Rainbow> BTW: on the wiki there's something contradicting (at least in my view): ' "Expert settings" would replace the current "all settings". ' vs. 'Expert settings" should be those settings which usually noone wants to see or change'
20:50:41 *** andythenorth has left #openttd.dev
20:50:59 <frosch123> the filters are meant to be inclusive
20:51:11 <frosch123> "basic" would display only basic
20:51:18 <Eagle_Rainbow> ah..., so all adv. would include basic
20:51:20 <frosch123> "advanced" would display basic plus some more
20:51:26 <frosch123> "expert" would display all
20:51:42 <Eagle_Rainbow> Then, I'll think we will add that sentence to the wiki :)
20:56:27 <Eagle_Rainbow> damn.... I think I fell into the same trap as michi_cc with the Wiki... I have an underscore in my login :-(
22:22:25 *** Alberth has left #openttd.dev
23:29:50 <Eagle_Rainbow> good night everyone.
23:43:30 *** MinchinWeb has joined #openttd.dev
continue to next day ⏵