Config
Log for #openttd.dev on 3rd November 2012:
Times are UTC Toggle Colours
00:20:51  *** LordAro has quit IRC
04:23:20  *** FLHerne has joined #openttd.dev
04:33:53  *** FLHerne has quit IRC
06:39:20  *** Supercheese has quit IRC
07:25:35  *** andythenorth has joined #openttd.dev
07:25:35  *** ChanServ sets mode: +v andythenorth
08:02:25  *** andythenorth has quit IRC
08:02:42  *** andythenorth has joined #openttd.dev
08:02:42  *** ChanServ sets mode: +v andythenorth
08:40:53  *** Zuu has joined #openttd.dev
08:40:53  *** ChanServ sets mode: +v Zuu
09:33:11  *** Alberth has joined #openttd.dev
09:33:11  *** ChanServ sets mode: +v Alberth
10:17:30  *** andythenorth has quit IRC
10:39:21  *** Eagle_Rainbow has joined #openttd.dev
10:39:21  *** ChanServ sets mode: +v Eagle_Rainbow
10:39:41  <Eagle_Rainbow> Hi everyone
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:44:54  <Eagle_Rainbow> argl...
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:09  <Eagle_Rainbow> ??
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:47  <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:59  <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:43  <Eagle_Rainbow> frosch123, yeah, that also sounds like overkill to me...
11:09:43  <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:06  <frosch123> ok :p
11:11:19  <frosch123> have a screenshot?
11:11:22  <Eagle_Rainbow> as the variable value apparently can get quite huge...
11:11:24  <Eagle_Rainbow> yep...
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:15:31  <Eagle_Rainbow> Here's a screenshot: http://postimage.org/image/l82ucoc57/
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:52  <frosch123> not really
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:25  <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:45  <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:11:10  *** andythenorth has quit IRC
14:18:14  *** fonsinchen has quit IRC
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:34:03  *** Eagle_Rainbow has quit IRC
15:38:17  *** LordAro has joined #openttd.dev
15:38:17  *** ChanServ sets mode: +v LordAro
15:41:06  *** andythenorth has quit IRC
15:41:59  *** Zuu has quit IRC
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:48:10  *** Guest4351 has quit IRC
15:51:00  * LordAro doesn't like wireless connections
15:53:05  <LordAro> ... and that was the wwrong channel, but meh
15:54:08  <frosch123> http://paste.openttdcoop.org/show/1880/ <- ProfileValues is a SmallMap
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:45  *** Knogle has quit IRC
16:34:54  *** Zuu has joined #openttd.dev
16:34:54  *** ChanServ sets mode: +v Zuu
16:35:33  *** Knogle has joined #openttd.dev
16:39:44  *** LordAro has quit IRC
16:57:24  *** Zuu has quit IRC
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:32:01  *** ChanServ sets mode: +v Zuu
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:09  *** andythenorth has quit IRC
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:32:27  *** FLHerne has quit IRC
19:48:55  *** Eagle_Rainbow has joined #openttd.dev
19:48:55  *** ChanServ sets mode: +v Eagle_Rainbow
19:49:10  <Eagle_Rainbow> Good evening!
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:07  <Eagle_Rainbow>  to impossible.
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:05  <Eagle_Rainbow> It reads:
19:52:10  <Eagle_Rainbow> void Window::InvalidateData(int data, bool gui_scope)
19:52:10  <Eagle_Rainbow> {
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:15  <Eagle_Rainbow>         }
19:52:17  <Eagle_Rainbow>         this->OnInvalidateData(data, gui_scope);
19:52:19  <Eagle_Rainbow> }
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:52:54  <Eagle_Rainbow> ok...
19:53:58  <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:57  <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:44  <frosch123> nope
20:44:52  <frosch123> that will likely take multiple iterations
20:44:57  <Eagle_Rainbow> yes, sure...
20:45:05  <frosch123> there are some examples on the wiki
20:45:12  <Eagle_Rainbow> saw them.
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:45:58  <frosch123> sounds fine
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:51:00  <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 :-(
21:00:04  <planetmaker> @logs
21:00:05  <DorpsGek> planetmaker: http://irclogs.qmsk.net/channels/openttd
22:22:25  *** Alberth has left #openttd.dev
23:07:30  <frosch123> night
23:07:33  *** frosch123 has quit IRC
23:07:53  *** LordAro has quit IRC
23:29:50  <Eagle_Rainbow> good night everyone.
23:30:01  *** Eagle_Rainbow has quit IRC
23:43:30  *** MinchinWeb has joined #openttd.dev

Powered by YARRSTE version: svn-trunk