--- Log opened Wed Oct 05 00:00:57 2016
20161005 00:02:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161005 00:02:17-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds]
20161005 00:02:26-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has quit [Remote host closed the connection]
20161005 00:05:42< matthiaskrgr> vultraz: > create game: crash when selecting same era twice 
20161005 00:05:55< matthiaskrgr> theres still a crash when switching form one to default era
20161005 00:06:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161005 00:06:26< matthiaskrgr> ok it also just crashes when selecting preselected stuff
20161005 00:07:17< matthiaskrgr> age of heros -> age of heros => boom
20161005 00:09:14< matthiaskrgr> http://pastebin.com/jXyGB8wa  
20161005 00:12:35-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 00:16:35-!- travis-ci [~travis-ci@ec2-107-20-122-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20161005 00:16:36< travis-ci> wesnoth/wesnoth#11311 (master - 485e24e : Charles Dang): The build has errored.
20161005 00:16:36< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165102653
20161005 00:16:36-!- travis-ci [~travis-ci@ec2-107-20-122-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20161005 00:17:25< irker506> wesnoth: mattsc wesnoth:master b00e6d5d963f / data/ai/ (lua/ai_helper.lua micro_ais/cas/ca_bottleneck_move.lua): ai_helper.LS_to_triples: fix function name https://github.com/wesnoth/wesnoth/commit/b00e6d5d963ff5f26846ed6b8f375117fd81fb6c
20161005 00:17:27< irker506> wesnoth: mattsc wesnoth:master e38dd8ff16c0 / data/ai/lua/ai_helper.lua: ai_helper: new utility functions to find attackable enemies https://github.com/wesnoth/wesnoth/commit/e38dd8ff16c02dfe909612896b8bed7435d84eb8
20161005 00:17:53< mattsc> ^ that’s the beginning of some work I am doing to fix up the Lua AIs when there are hidden units around.
20161005 00:18:23< mattsc> Just syncing right now so that I can do the test vultraz wants me to do
20161005 00:21:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 00:22:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 00:25:43< mattsc> vultraz: yes, that fixes both issues, the problem with the insanely long waiting times and my artificially created version of bug #25146
20161005 01:02:26-!- prkc [~prkc@46.166.138.134] has quit [Remote host closed the connection]
20161005 01:09:39-!- travis-ci [~travis-ci@ec2-107-20-122-145.compute-1.amazonaws.com] has joined #wesnoth-dev
20161005 01:09:40< travis-ci> wesnoth/wesnoth#11313 (master - e38dd8f : mattsc): The build passed.
20161005 01:09:40< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165109597
20161005 01:09:40-!- travis-ci [~travis-ci@ec2-107-20-122-145.compute-1.amazonaws.com] has left #wesnoth-dev []
20161005 01:15:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 01:20:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20161005 01:29:15-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161005 01:37:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161005 01:59:22< mattsc> Oh.  That’s because ai.check_<action> returns whether it itself changes the gamestate, rather than whether the respective action would change it.
20161005 01:59:28< mattsc> That’s unfortunate.
20161005 02:00:31< celticminstrel> Why would checking change the gamestate?
20161005 02:00:59< mattsc> It wouldn’t.  That’s what I am saying.
20161005 02:02:32< vultraz> matthiaskrgr: again, cannot reproduce :|
20161005 02:02:55< vultraz> matthiaskrgr: there does seem to be a crash when clicking on the dropdown selection quickly and then jerking themouse away
20161005 02:11:04< vultraz> ok, wait, now I see it...
20161005 02:11:19< vultraz> what the fuck :|
20161005 02:11:40< mattsc> you’re so well spoken, vultraz
20161005 02:12:08< vultraz> ah, wait
20161005 02:12:10< vultraz> my change
20161005 02:13:59< vultraz> mattsc: I express appropriate frustration when wesnoth decides to act up :P
20161005 02:17:04< vultraz> celticminstrel: problem, I have. using the scrollbar by hand in the dropdown causes the dialog to close
20161005 02:24:35< vultraz> also, this https://gna.org/bugs/index.php?25153
20161005 02:24:58< vultraz> i can't figure out what's going on with the scrollbar to cause such things..
20161005 02:32:10< vultraz> I can see why the scrollbar would close the dialog though
20161005 02:33:22< vultraz> then again, we intend to remove the scrollbar
20161005 02:44:13-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161005 03:17:28-!- irker506 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161005 03:29:35< shadowm> Surely "we" means entirely fictional people that do not exist.
20161005 03:29:52< vultraz> celticminstrel and I
20161005 03:30:03< shadowm> I think it should tell you something that even your favorite OS keeps scrollbars around.
20161005 03:30:37< shadowm> One important point is that without scrollbars you won't have any indication that some widget is scrollable in the first place.
20161005 03:31:04< vultraz> He intends to introduce new scroll buttons
20161005 03:31:10< shadowm> Also, I really would appreciate it if you kept in mind that scrollwheels can break.
20161005 03:31:10< vultraz> in the header and footer
20161005 03:31:30< vultraz> essentially, wide versions of the scrollbar's repeating buttons 
20161005 03:31:50< shadowm> That doesn't sound very nice.
20161005 03:31:52< vultraz> (which, for the record, I don't really think are necessary to keep in the scrollbar, but that's a whole different matter)
20161005 03:32:16< vultraz> if we keep the scrollbar in the dropdown list as-is, we do need to fix it
20161005 03:32:40< Aginor> I just read the backlog and I have a couple of questions
20161005 03:32:45< shadowm> If we keep Wesnoth around we need to fix it. :)
20161005 03:33:02< Aginor> how does the scrollbar interact with other objects that it's tied to?
20161005 03:33:19< vultraz> It... scrolls it? what do you mean
20161005 03:33:23< vultraz> how does it scroll it?
20161005 03:33:25< vultraz> I don't know. 
20161005 03:33:42< Aginor> is it a scrollable panel or some such, or do you explicitly place a widget and then make it do the right thing yourself?
20161005 03:33:58< vultraz> former
20161005 03:34:40< Aginor> and you want to replace that with something else?
20161005 03:34:52< vultraz> no, just a different type of scrollbar
20161005 03:35:23< Aginor> what do you mean by different type of scrollbar? I think we have different ideas of what a scrollbar means in this context
20161005 03:36:10< vultraz> look, the implementation of scrolling is rather complicated 
20161005 03:36:28< vultraz> the listbox widget defines the scrollbar grids (with the repeating buttons and scrollbar widgets) manually
20161005 03:36:36< vultraz> but the content_grid grid is then swapped for a scrollbar panel
20161005 03:36:41< vultraz> at runtime
20161005 03:37:06< shadowm> vultraz: Did you review UI strings in my PR?
20161005 03:37:21< vultraz> the thing is that right now the scrollbar panel wants a scrollbar widget
20161005 03:37:38< vultraz> for this exercise we would remove that and use just the repeating buttons
20161005 03:37:47< vultraz> (which I still think should be removed from the standard scrollbar)
20161005 03:37:51< vultraz> the buttons are NOT mandatory
20161005 03:37:53< vultraz> but the scrollbar is
20161005 03:37:58< vultraz> by design of the scrollbar_panel
20161005 03:38:26< vultraz> the scrollbar_panel widget as such needs to be updated to work with no scrollbar widget
20161005 03:38:57< vultraz> however, something that does confuse me is that the scrollbar_panel also has its own placement of the scrollbar grids
20161005 03:39:09< Aginor> ok, I don't think I understand how that hangs together
20161005 03:39:16< vultraz> so it's possible I'm wrong and the listbox doesn't use a scrollbar panel internally, at least not entirely
20161005 03:39:31< vultraz> I know it uses it in some respect since it can handle the code for the header/footer....
20161005 03:40:06< vultraz> so we'd need to figure out exactly how the listbox works with the scrollbar_panel and the scrollbars
20161005 03:41:20< vultraz> shadowm: I hadn't extensively 
20161005 03:41:49< shadowm> So how many times do I need to say "review" so that things will be reviewed? :\
20161005 03:42:51< vultraz> I was looking at the code before (yes, yes, no excuse, I know)
20161005 03:44:53< vultraz> I'll go over it again with an explicit eye to the UI strings
20161005 03:53:27< vultraz> shadowm: ok done
20161005 03:54:34-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161005 03:56:38-!- Bonobo [~Bonobo@2001:44b8:254:3200:d41d:235d:593c:c057] has joined #wesnoth-dev
20161005 04:01:39-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161005 04:01:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161005 04:04:55< shadowm> Okay, next time do not request changes to strings that were already there, as part of the PR review.
20161005 04:17:08-!- JyrkiVesterinen [~JyrkiVest@87-100-170-233.bb.dnainternet.fi] has joined #wesnoth-dev
20161005 04:17:12-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev
20161005 04:17:35< celticminstrel> shadowm, vultraz: We're not removing scrollbars in general. I do however want to remove them from menus.
20161005 04:17:46< vultraz> oh yeah
20161005 04:17:50< vultraz> I should have clarified that
20161005 04:17:53< celticminstrel> Aginor: The scrollbar is basically a slider plus a pair of buttons.
20161005 04:17:59< celticminstrel> vultraz: Yes, yes you should have.
20161005 04:18:51< celticminstrel> (Specifically, "repeating buttons", which just means that they continue to trigger if you hold down the mouse button.)
20161005 04:19:02 * celticminstrel flops bed
20161005 04:19:05-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161005 04:26:02-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Quit: Page closed]
20161005 04:26:14< wedge009> zookeeper: You seem to know more about this than I do. From what I recall, I was just filtering on the bit of code that prints out terrain defence listings per unit. What you're describing - is that in the WML or cfg?
20161005 04:33:37-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Remote host closed the connection]
20161005 04:42:07-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161005 04:45:03< vultraz> I wonder if we can actually have a blinking cursor in the text box
20161005 04:45:07< vultraz> of if that's beyond our tech
20161005 04:46:07< vultraz> I can think one one implementation
20161005 04:50:39-!- JyrkiVesterinen [~JyrkiVest@87-100-170-233.bb.dnainternet.fi] has quit [Quit: .]
20161005 04:53:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 04:58:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20161005 05:51:56< Sirp> vultraz: that makes me seriously sadface. :(
20161005 05:56:36< Aginor> I don't think blinking cursors would be too hard
20161005 05:56:48< Aginor> it'll require a bit of refactoring
20161005 05:56:49< Sirp> yeah they shouldn't be.
20161005 05:57:22< Aginor> update state based on blinking time, either render it or not
20161005 06:01:54< vultraz> Sirp: wesnoth's ui api is so incredibly behind anura's that even such simple things are likely difficult 
20161005 06:02:20< Sirp> vultraz: yeah, I know. :-/
20161005 06:03:31< vultraz> we don't even have a multiline textbox :|
20161005 06:03:41< shadowm> vultraz. Please.
20161005 06:04:16< vultraz> yes, there's some framework, but it still has to be put together 
20161005 06:04:19< shadowm> Do we really need to have the 13,000th "boo hoo everything sucks" rant right now?
20161005 06:04:25< vultraz> no
20161005 06:04:35< vultraz> I'm simply making a point
20161005 06:04:48< shadowm> So is 'path' too technical or not?
20161005 06:05:09< vultraz> I don't know
20161005 06:05:12< vultraz> I hoped you did.
20161005 06:05:18< shadowm> How would I know?
20161005 06:05:31< shadowm> I use a desktop environment that is very obviously aimed towards tech-savvy users.
20161005 06:06:02< shadowm> Plus, if I did, I'd have made the right choice at the beginning.
20161005 06:06:23< vultraz> Let's play it safe and stick with Location
20161005 06:06:40< shadowm> Okay then.
20161005 06:06:54-!- irker058 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161005 06:06:54< irker058> wesnoth: Ignacio R. Morelle wesnoth:master ea9d077b89dc / / (7 files in 4 dirs): fs: Add utility functions for the new file dialog https://github.com/wesnoth/wesnoth/commit/ea9d077b89dcefd33bba7aeb2ddee0479ae4fafa
20161005 06:06:54< irker058> wesnoth: Ignacio R. Morelle wesnoth:master f3795467dca9 / src/ (filesystem.hpp filesystem_boost.cpp tests/test_filesystem.cpp): fs: Add nearest_extant_parent() function and tests https://github.com/wesnoth/wesnoth/commit/f3795467dca9c71112aec3150d64c782833c8e2d
20161005 06:06:55< irker058> wesnoth: Ignacio R. Morelle wesnoth:master ff07aecdf09a / src/ (filesystem.hpp filesystem_boost.cpp tests/test_filesystem.cpp): fs: Add three-parameter form of normalize_path() that returns canonical paths https://github.com/wesnoth/wesnoth/commit/ff07aecdf09ac6c1f8808c7bc1340c9f6b8060af
20161005 06:06:57< irker058> wesnoth: Ignacio R. Morelle wesnoth:master d301f8027fe5 / src/ (filesystem.hpp filesystem_boost.cpp): fs: Add root_name() function https://github.com/wesnoth/wesnoth/commit/d301f8027fe5a9ab59730071d8bb0107431db841
20161005 06:07:00< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 6e1f6bb68645 / / (8 files in 5 dirs): gui2/tfile_dialog: Initial port of the filechooser dialog to GUI2 https://github.com/wesnoth/wesnoth/commit/6e1f6bb68645ba23cbc594d10dc2fb1d68f11042
20161005 06:07:03< irker058> wesnoth: Ignacio R. Morelle wesnoth:master fc593270dc0f / src/gui/dialogs/ (file_dialog.cpp file_dialog.hpp): gui2/tfile_dialog: Allow callers to set a custom label for the OK button https://github.com/wesnoth/wesnoth/commit/fc593270dc0f9d85faf9bb9b24ccb22c17542376
20161005 06:07:06< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 409b61f5befb / data/gui/window/file_dialog.cfg: gui2/tfile_dialog: We can delete folders too https://github.com/wesnoth/wesnoth/commit/409b61f5befb34f81cb591d40f5fc7dd26fb34c8
20161005 06:07:09< irker058> wesnoth: Ignacio R. Morelle wesnoth:master ef09ef9e6cb6 / src/gui/dialogs/file_dialog.cpp: gui2/tfile_dialog: Add deletion prompt and fix deleting folders https://github.com/wesnoth/wesnoth/commit/ef09ef9e6cb603460f4f31d2825f6c120d889272
20161005 06:07:12< irker058> wesnoth: Ignacio R. Morelle wesnoth:master c89b7596ec78 / src/gui/dialogs/file_dialog.cpp: gui2/tfile_dialog: Avoid redundant grid pointer retrieval https://github.com/wesnoth/wesnoth/commit/c89b7596ec78a09f0ffbbcfd392a9403afaac1a3
20161005 06:07:15< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 0cd131b53752 / src/ (gettext.hpp gettext_boost.cpp): i18n: Add case-insenstitive icompare() function, document compare() https://github.com/wesnoth/wesnoth/commit/0cd131b537529f71bfd0442436595953b466715f
20161005 06:07:18< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 7b3fdedc855c / src/gui/dialogs/file_dialog.cpp: gui2/tfile_dialog: Sort directory entries ignoring character case https://github.com/wesnoth/wesnoth/commit/7b3fdedc855ce5b71e6a4752e02536deb78b53c0
20161005 06:07:21< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 0f83718965d7 / data/gui/window/file_dialog.cfg: gui2/tfile_dialog: Set maximum dialog height https://github.com/wesnoth/wesnoth/commit/0f83718965d74a144842dee44025e00d00473122
20161005 06:07:24< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 3fa0fc954897 / src/gui/widgets/ (text.cpp text.hpp): gui2/ttext_: Add a public method for setting the selection range https://github.com/wesnoth/wesnoth/commit/3fa0fc954897ed633b354ffe21e9b7508642e9c6
20161005 06:07:27< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 8056d638f17c / src/gui/dialogs/ (file_dialog.cpp file_dialog.hpp): gui2/tfile_dialog: Add support for a filename extension hint https://github.com/wesnoth/wesnoth/commit/8056d638f17c1b1b8564020b7252745323a711a4
20161005 06:07:30< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 285bbe723777 / / (13 files in 6 dirs): gui: Remove GUI1 filechooser https://github.com/wesnoth/wesnoth/commit/285bbe723777b53921075656258ee9fcb8c897c9
20161005 06:07:33< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 2cc1f6692a94 / src/gui/dialogs/file_dialog.hpp: gui2/tfile_dialog: Clarify defaults https://github.com/wesnoth/wesnoth/commit/2cc1f6692a94c684baffd1a82ef8b4f8cd0e2dce
20161005 06:07:36< irker058> wesnoth: Ignacio R. Morelle wesnoth:master ddd3dc726196 / src/preferences_display.cpp: preferences: Make wesnothd search starting point sane, simplify code https://github.com/wesnoth/wesnoth/commit/ddd3dc726196027fbd4ae78a7907126401613833
20161005 06:07:39< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 8c14dc1872cd / src/gui/dialogs/file_dialog.cpp: gui2/tfile_dialog: Make it so the fileview and textbox "share" the focus https://github.com/wesnoth/wesnoth/commit/8c14dc1872cde14b31fe5dfaf851a474da4b5809
20161005 06:07:42< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 95a192fe796a / src/preferences_display.cpp: preferences: Reword part of the file dialog message https://github.com/wesnoth/wesnoth/commit/95a192fe796a81d5329fcbc90a6626cb54736159
20161005 06:07:54< vultraz> \o/
20161005 06:08:01< vultraz> it has arrived!
20161005 06:08:24< shadowm> Now I can finally start working on making it more functional than the GUI1 version.
20161005 06:08:33< vultraz> huge thanks for working on this
20161005 06:08:50< vultraz> honestly, I would never have been able to do it
20161005 06:09:16< shadowm> Why do you say that? I would never have been able to do it without your help in the first place. :p
20161005 06:09:44< vultraz> I understand none of the filesystem workings.
20161005 06:10:31-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161005 06:12:58< shadowm> Hmph.
20161005 06:13:13< shadowm> The Load Map action in the editor also applies to scenarios, doesn't it?
20161005 06:13:25< vultraz> yes
20161005 06:13:38< shadowm> Well, that makes it a bit tricky to shorten the dialog caption.
20161005 06:13:56< shadowm> OTOH if I use "Load Map" then it's the same as the menu item, so... I'll just go with that.
20161005 06:16:26< irker058> wesnoth: Ignacio R. Morelle wesnoth:master d17ded15081c / src/ (editor/map/context_manager.cpp menu_events.cpp): Cleaned up UI strings passed to the file dialog https://github.com/wesnoth/wesnoth/commit/d17ded15081c391c40791cbedae9e12ad3c42c24
20161005 06:22:19< shadowm> vultraz: Remind me how the ToD edit thing uses the file dialog?
20161005 06:22:35< shadowm> What is the user supposed to look for?
20161005 06:22:46< vultraz> it opens to pre-defined directories so the user can pick tod sound, image, and mask
20161005 06:23:03< vultraz> and doesn't allow browsing out of them, I think
20161005 06:25:02< shadowm> The GUI1 filechooser didn't have an interface for limiting the browsing scope.
20161005 06:25:24< shadowm> It also didn't have an option to restrict the search to directories as opposed to files.
20161005 06:25:38< vultraz> ...really?
20161005 06:25:49< vultraz> I'm almost certain it didn't allow browsing out of the directory
20161005 06:26:01< shadowm> Nope.
20161005 06:26:18< shadowm> You can take a look at filechooser.hpp's bottom end on 1.12.
20161005 06:26:58< Aginor> hey, how are colour strings formatted in the wml?
20161005 06:27:07< Aginor> a,r,g,b or r,g,b,a?
20161005 06:27:09< vultraz> apparently I am mistaken
20161005 06:27:14< vultraz> Aginor: rgba
20161005 06:27:41< Aginor> ok...
20161005 06:27:48< shadowm> Aginor: Depends on what WML we're talking about. There's only one place I can think of that uses packed values and it doesn't have alpha.
20161005 06:28:08< Aginor> shadowm: gui2 it seems
20161005 06:28:32< vultraz> gui2 is rgba
20161005 06:28:38< shadowm> I think GUI2 uses a list of channel values (e.g. red, green, blue, alpha), not packed values.
20161005 06:29:21< shadowm> e.g. `color = "188, 176, 136, 255"`
20161005 06:29:23< vultraz> ok you really need to set that restore flag
20161005 06:29:51< shadowm> I told you I won't because it goes against my principles.
20161005 06:29:56< Aginor> thanks
20161005 06:29:58< vultraz> well, I will
20161005 06:29:59< shadowm> You'll have to insert that single line yourself.
20161005 06:30:38< shadowm> Imagine if in Wesnoth's main() we had to call pls_let_other_application_windows_sit_behind_ours_if_they_want() at the start.
20161005 06:30:52< shadowm> Or pls_let_other_applications_run_concurrently_with_us().
20161005 06:31:00< vultraz> I don't like it either
20161005 06:31:05< Aginor> it's terrible
20161005 06:31:07< vultraz> it's been a massive pain to add the flag to every dialog
20161005 06:31:17< vultraz> (almost every)
20161005 06:31:27< vultraz> but Aginor insists it's necessary for now
20161005 06:31:28< shadowm> And what's the purpose of having exceptions to that?
20161005 06:31:34< Aginor> and I'm the one who introduced it because there's no better way to deal with gui1 and gui2 living concurrently
20161005 06:31:57< shadowm> i.e. what would be an objective reason for me to _not_ use the flag?
20161005 06:33:36< Aginor> shadowm: the redraw-flag relies on making a copy of the rendered data into RAM, storing it, and then redrawing it later, taking no account of changes that may have occurred in the meanwhile, causing potential state inconsistensies
20161005 06:33:44< Aginor> furthermore
20161005 06:34:21< Aginor> making a copy from the accellerated surface (when we eventually can have it), will be a substantial performance impact compared to simply re-rendering the affected textures
20161005 06:35:05< Aginor> a better, future proof solution, would be to mark areas as dirty and re-render the affected components within those areas, in the order they should be re-rendered
20161005 06:35:29< irker058> wesnoth: Charles Dang wesnoth:master 93d850faf966 / src/gui/dialogs/file_dialog.cpp: File Dialog: set restore flag https://github.com/wesnoth/wesnoth/commit/93d850faf966245c39b3d1698a460ee5ef22f56c
20161005 06:35:32< irker058> wesnoth: Charles Dang wesnoth:master d72ff82cc6d0 / src/gui/dialogs/file_dialog.cpp: File Dialog: make New Folder and Delete buttons invisible instead of hidden in r https://github.com/wesnoth/wesnoth/commit/d72ff82cc6d03d6ac62e208078542fbceea8d7a9
20161005 06:35:50< vultraz> ^ fixes the empty space in the wesnothd dialog
20161005 06:35:53< Aginor> that however requires there to be an overreaching framework that is responsible for managing the drawn windows/dialogs and knowing their size and location so it can notify the underlying components that they are now dirty
20161005 06:39:44< vultraz> god DAMMIT gui2
20161005 06:39:55< shadowm> hUHuh?
20161005 06:40:03< shadowm> I was fairly sure hidden was the correct one.
20161005 06:40:10< vultraz> https://drive.google.com/file/d/0B-mR9s8FduLLNzEzdHpWM0djcG8/view?usp=sharing
20161005 06:40:20< vultraz> shadowm: hidden reserves space, invisible does not
20161005 06:40:23< shadowm> Okay, yes, invisible is the right one.
20161005 06:40:35< shadowm> I always mistake them for each other. Wonder why? /s
20161005 06:41:00< vultraz> anyway, gui2 is absolutely shitting on itself :|
20161005 06:41:02< shadowm> In CSS, elements that have the display property set to hidden are not added to the layout.
20161005 06:41:28< shadowm> Elements that have the visibility property set to none are invisible, but they may still be in the layout (i.e. take up space) if display != hidden.
20161005 06:41:45< JyrkiVesterinen> CSS has "visibility: hidden" (reserves space) and "display: none" (doesn't reserve space).
20161005 06:41:58< shadowm> Yes, that.
20161005 06:42:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 06:42:09< shadowm> Goes to show I've not touched any CSS for a few months.
20161005 06:42:56< shadowm> I've always wished GUI2's WML had been modeled after CSS instead of... whatever it's currently modeled after.
20161005 06:43:16< shadowm> The GUI2 border property is probably the worst offender.
20161005 06:43:53-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 248 seconds]
20161005 06:44:29< shadowm> ./logging.cpp:55:       set_restore(true); //why is this done manually?
20161005 06:45:22< shadowm> Mystery person was asking the right question. :p
20161005 06:45:51< Aginor> ok, what's a better solution?
20161005 06:46:12< shadowm> I think I'm more curious how many GUI2 dialogs can have stuff changed behind them.
20161005 06:46:27-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has joined #wesnoth-dev
20161005 06:46:37< Aginor> shadowm: resize the window
20161005 06:46:44< shadowm> Oh right. That.
20161005 06:46:45< Aginor> shadowm: have an animation
20161005 06:46:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20161005 06:47:03< shadowm> Not really. Animations don't ever happen behind the dialog's back AFAIK.
20161005 06:47:15< shadowm> Unless it's some implementation detail of the new loading screen in particular.
20161005 06:47:32< Aginor> there's no reason to stop animations that are partially overlapped by a dialog
20161005 06:47:50< shadowm> But we'll keep doing that anyway for the foreseeable future, surely.
20161005 06:48:14< irker058> wesnoth: Charles Dang wesnoth:master bf1c0388826d / data/gui/window/file_dialog.cfg: File Dialog: used fixed-size window instead of dynamic https://github.com/wesnoth/wesnoth/commit/bf1c0388826df5e4499f6e85396f7f88962da9d6
20161005 06:48:25< vultraz> now it won't change size randomly
20161005 06:48:41< shadowm> So yes, I'm essentially wondering why this hack is opt-in rather than opt-out. But I guess there's the window resize argument.
20161005 06:49:41< Aginor> change it, make it on by default then
20161005 06:49:42< shadowm> I guess after so many years of that being broken I just somehow instinctively know to never try to resize the game window when a dialog is being executed. Of course that's bad UX and there's some value in preventing that from causing issues.
20161005 06:50:20< vultraz> (I'm surprised you're not surprised by that commit)
20161005 06:50:34< shadowm> Oh.
20161005 06:50:42< shadowm> Oh my god what a surprise. Why are you doing this?
20161005 06:50:54< vultraz> yay
20161005 06:51:10< shadowm> The last time I tried it I had to give up because I kept hitting border cases where the game would run out of layout space and abort.
20161005 06:51:42< shadowm> That was in 1.9.x/1.10.x wth a Lua-defined dialog, granted.
20161005 06:51:47< vultraz> perhaps i should reduce the width slightly 
20161005 06:51:50< vultraz> for 800x600
20161005 06:52:04< vultraz> or wait, no
20161005 06:52:07< vultraz> we have formulas for that
20161005 06:53:07< shadowm> And formulas is what I was attempting to use at the time, too.
20161005 06:53:30< shadowm> Maybe I just didn't pick the right ~~~~magic~~~~ numbers!
20161005 06:54:02< shadowm> For example, is that 400 intended to be width/2 and/or height/2, or does it have a more obscure significance?
20161005 06:54:41< vultraz> Read the comment
20161005 06:56:19< shadowm> You didn't test that commit.
20161005 06:56:36< vultraz> I did test
20161005 06:56:50< shadowm> With which resolution?
20161005 06:57:10< vultraz> normal one, and yes, I am coming up with a formula for 800x600 now
20161005 06:57:23< shadowm> Yes, that's what I meant.
20161005 06:57:38< shadowm> Border cases.
20161005 06:58:07< shadowm> For the curious: https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161005_035752.png
20161005 06:58:43< vultraz> i should really fix the bug where width/2 doesn't work for some reason
20161005 07:01:39< Aginor> that would be more sensible
20161005 07:03:36< shadowm> I'm going to move those external overwrite prompts into the dialog, so try to not touch anything below line 243 in the .cpp in the meantime.
20161005 07:03:50< shadowm> And line 233 in the .hpp.
20161005 07:05:55< shadowm> Hm, I still missed some redundant OK label overrides.
20161005 07:06:13< shadowm> One at least.
20161005 07:06:23< shadowm> Two.
20161005 07:06:50< shadowm> And hopefully no more than that because I don't know what comes after that.
20161005 07:12:09-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has quit [Remote host closed the connection]
20161005 07:13:06< shadowm> vultraz: The dialog is *far* too large now.
20161005 07:13:36< shadowm> https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161005_041316.png
20161005 07:13:58< vultraz> ok, I'll reduce
20161005 07:14:16-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161005 07:15:36< shadowm> The best solution really would be to default to a small size and let the user drag the borders to resize the dialog but that's obviously too advanced for us.
20161005 07:16:19< vultraz> ahahahaha
20161005 07:16:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 272 seconds]
20161005 07:16:46-!- wedge010 is now known as wedge009
20161005 07:23:06< irker058> wesnoth: Charles Dang wesnoth:master 86ef55ef5d7a / src/gui/widgets/window.cpp: gui2/window: update window_width/window_height variables after calculating w/h https://github.com/wesnoth/wesnoth/commit/86ef55ef5d7a9fbbe1ed1ca043c3dfe6699434af
20161005 07:23:09< irker058> wesnoth: Charles Dang wesnoth:master f7100f2315d7 / data/gui/window/file_dialog.cfg: File Dialog: more sensible size https://github.com/wesnoth/wesnoth/commit/f7100f2315d7321e2f2b78c1994324b7fc86704c
20161005 07:23:34< vultraz> shadowm: ^
20161005 07:23:51< shadowm> "Try to save the map, if it fails we reset the filename." No we don't.
20161005 07:24:13< shadowm> It's always fun when the comments speak of things that do not actually exist or happen.
20161005 07:27:19< JyrkiVesterinen> Yeah. http://stackoverflow.com/a/389723 :D
20161005 07:30:54-!- Nobun [~nobun@host254-21-dynamic.52-82-r.retail.telecomitalia.it] has joined #wesnoth-dev
20161005 07:32:00< Nobun> loonycyborg: About PR #811: as I promised I retyped wrong comments. Now all comments should be 'fixed'
20161005 07:35:32< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 4096097d9958 / src/editor/map/context_manager.cpp: editor: Drop more redundant file dialog button label overrides https://github.com/wesnoth/wesnoth/commit/4096097d99586c8aa0e49ec40c230b79b5699d77
20161005 07:35:35< irker058> wesnoth: Ignacio R. Morelle wesnoth:master ec4dbfb8a442 / src/ (4 files in 3 dirs): gui2/tfile_dialog: Prompt user about overwriting files in save mode https://github.com/wesnoth/wesnoth/commit/ec4dbfb8a44224ff22fb9c435fcfb415b056a2a4
20161005 07:35:35< shadowm> vultraz: Okay. Still too tall for my taste, but better.
20161005 07:35:38< irker058> wesnoth: Ignacio R. Morelle wesnoth:master 8b3bb18eb74e / src/menu_events.cpp: Use show_transient_error_message for displaying Save Map errors in-game https://github.com/wesnoth/wesnoth/commit/8b3bb18eb74eed94fa9e973d6197a2a0c07c4a53
20161005 07:37:39-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161005 07:40:32< shadowm> Hey wha?
20161005 07:40:49< shadowm> The path label _is_ ellipsized when it runs out of space.
20161005 07:41:09-!- atarocch [~atarocch@5.92.196.75] has joined #wesnoth-dev
20161005 07:41:13< shadowm> Just... not in the right place. It'd be preferable to ellipsize it at the start, not the end.
20161005 07:41:20< shadowm> (Or even better, the middle, following path semantics.)
20161005 07:41:30< vultraz> it is, yes
20161005 07:41:34< vultraz> but not when the dialog opens
20161005 07:41:41< shadowm> https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161005_044128.png
20161005 07:42:07< vultraz> is that a freshly opened dialog?
20161005 07:42:10< shadowm> No.
20161005 07:42:23< vultraz> well, then
20161005 07:42:35< shadowm> I'd like to ellipsizisize it at the start.
20161005 07:42:41< shadowm> Ellipsisisize.
20161005 07:42:58< vultraz> possible, perhaps this is not
20161005 07:43:20< vultraz> and we still need to make it work when the dialog opens
20161005 07:43:38< shadowm> The Yodaspeak thing got old approximately 0.0000000000000001 nanoseconds after you started doing it.
20161005 07:43:40< vultraz> because right now it gives the window a scrollbar if the path is too long
20161005 07:43:50< vultraz> and that's bad :|
20161005 07:44:47< shadowm> I should probably write the path ellipsizizizition function and wire it into that label's text then.
20161005 07:45:30< shadowm> The annoying thing is that we have to use character counts.
20161005 07:45:51< shadowm> Glyphs can be as wide or tall as you probably do not expect (see also: Zalgo).
20161005 07:46:07< shadowm> So it's not a faultproof solution.
20161005 07:46:09< vultraz> why don't you fix the problem in gui2 instead?
20161005 07:46:32< shadowm> I am 100% sure I tried.
20161005 07:46:59< shadowm> I don't remember why I gave up, though.
20161005 07:48:01< shadowm> I think I found that two or three of the GUI2 canvas, GUI2 label, or Pango text types were reinventing each other's wheels and that made me ragequit?
20161005 07:48:28< shadowm> It was a long time ago already.
20161005 07:48:33< vultraz> well, also possibly because the demand resize functions weren't ever fully/at all implemented
20161005 07:48:56< vultraz> we'd have to ask mordante
20161005 07:49:30< shadowm> Yes, that is a thing as well. I couldn't find a way to trigger the ellipsiziziation code.
20161005 07:49:53< shadowm> Naturally, forcing a dialog to be fixed-size didn't occur to me at the time.
20161005 07:50:00< vultraz> tcontrol::request_reduce_width
20161005 07:50:21< shadowm> See, that kind of thing obviously looks like an implementation detail.
20161005 07:50:32< shadowm> If I'm a dialog, I shouldn't ever have to touch it.
20161005 07:51:00< vultraz> except it's public
20161005 07:51:04< shadowm> Especially since the whole point of using WML for laying out widgets is defining this stuff in a more descriptive languge.
20161005 07:51:14< vultraz> but again
20161005 07:51:21< vultraz> doesn't work, actually
20161005 07:51:30< vultraz> at least not form pre_show where it matters
20161005 07:51:44< vultraz> some functionality needs to be added either way
20161005 07:51:45< shadowm> It'd not be the first or the last implementation detail in plain sight.
20161005 07:52:12< shadowm> Neither in GUI2, nor Wesnoth in general.
20161005 07:55:05< vultraz> anyway, since I have fixed the bug with manual window placement
20161005 07:55:19< vultraz> we can now do fixed-sized windows!
20161005 07:55:45< vultraz> I wonder if this is useful elsewhere
20161005 07:55:56< shadowm> Load Game.
20161005 07:56:01< shadowm> Preferences.
20161005 07:56:02< Nobun> shadowm: since defining widget layout on WML can be so difficult, why not try to implement it on lua, instead?
20161005 07:56:14< vultraz> Nobun: no better
20161005 07:56:16< shadowm> Nobun: ... I didn't say it was difficult.
20161005 07:56:42< shadowm> Just that there are missing features. Lua is no different because it uses WML too.
20161005 07:58:18< Nobun> understood... I was misunderstooding... I thinked that the tag-system-structure used by WML could be not suitable to correctly script a widget layout
20161005 07:58:38< Nobun> I though you was saying something like that
20161005 07:59:00< shadowm> It fits GUI2 quite well, more than certain people make it out to be.
20161005 07:59:55< vultraz> hm
20161005 08:00:06< vultraz> I seem to recall I did some hacky stuff with unit ... recruit or something
20161005 08:00:08< vultraz> or was it recall?
20161005 08:00:12< vultraz> to deal with window sizes
20161005 08:00:53< vultraz> oh, wait
20161005 08:00:58< vultraz> right*
20161005 08:01:12< vultraz> min widget size in the unit preview pane internal 
20161005 08:01:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161005 08:04:22< irker058> wesnoth: Wedge009 wesnoth:master 4d172d6e1132 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters wesnothd.vcxproj): Update VC project files for update of file menu from GUI1 to GUI2. https://github.com/wesnoth/wesnoth/commit/4d172d6e11320bc8c91bbbd29318ef2421108260
20161005 08:06:01< irker058> wesnoth: Charles Dang wesnoth:master 67d094d06fe9 / src/gui/dialogs/editor/custom_tod.cpp: Custom ToD: use read only mode for the file browser invocations https://github.com/wesnoth/wesnoth/commit/67d094d06fe995bf45a69e27f733522957c619d8
20161005 08:07:53< irker058> wesnoth: Wedge009 wesnoth:master 75278bac025d / src/filesystem_boost.cpp: Avoid performance warning in MSVC compilation. https://github.com/wesnoth/wesnoth/commit/75278bac025d3e8384924b8013b355cd96550dc3
20161005 08:09:25-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20161005 08:10:17< zookeeper> wedge009, uh... both? how can you even have one without the other
20161005 08:10:50< wedge009> I don't know - I know very little about WML.
20161005 08:14:13< wedge009> https://xkcd.com/1742/
20161005 08:14:23< wedge009> (Not related to above)
20161005 08:16:38< vultraz> shadowm: what gives the textboxes pre-ellipsization?
20161005 08:17:05< shadowm> Um.
20161005 08:17:48< shadowm> If the visible range of a textbox does not start at the start of the string, you will get an ellipsis at the start of the visible range. Is that what you 're asking?
20161005 08:18:05-!- atarocch [~atarocch@5.92.196.75] has quit [Ping timeout: 244 seconds]
20161005 08:18:08< vultraz> yes
20161005 08:18:21< shadowm> Or to put it in simpler terms, when the start OCOCOCOCOCOCOCOCof the string isn't visible.
20161005 08:18:24< shadowm> OF
20161005 08:19:33< shadowm> Conversely, if the end isn't visible, the contents get an ellipsis in that direction.
20161005 08:26:17-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev
20161005 08:26:45< benladin> the help command does nothing
20161005 08:28:14< shadowm> vultraz: `x = "((screen_width / 2) - (window_width / 2))"` -- surely WFL follows standard associativity?
20161005 08:28:37< vultraz> hm, good point
20161005 08:28:38< shadowm> i.e. a / b - 3 = (a / b) - 3 
20161005 08:29:38< shadowm> benladin: In what context?
20161005 08:30:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 08:31:01-!- atarocch [~atarocch@176.246.115.252] has joined #wesnoth-dev
20161005 08:33:01< benladin> as in i write /HELP and nothign happens
20161005 08:34:10< shadowm> Where?
20161005 08:34:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161005 08:35:04< irker058> wesnoth: Charles Dang wesnoth:master 147caf83cc6d / data/gui/ (4 files in 2 dirs): GUI2: some formula formatting cleanups https://github.com/wesnoth/wesnoth/commit/147caf83cc6d7deb6d519f66b7ace9ecad66d9d2
20161005 08:35:27< vultraz> I should probably make that formula group a macro, actually
20161005 08:35:41< vultraz> at least for windows
20161005 08:41:43< benladin> i write it where i write ths
20161005 08:41:50< benladin> this*
20161005 08:43:19< shadowm> benladin: Oh, so IRC then. If you aren't using a client that knows about the command (such as freenode's web client) you must use `/quote help` instead.
20161005 08:46:27< vultraz> ok, what gui1 dialogs are left
20161005 08:46:36< vultraz> Storyscreen, Help, Attack Prediction, and Statistics
20161005 08:48:28< vultraz> still a few things to iron out with Staging/Connect
20161005 08:48:32< vultraz> GUI2, that is
20161005 08:49:28< benladin> oh they should tell people this
20161005 08:50:13< benladin> '/quote help'
20161005 08:50:27< benladin> ok lol but i tried it without the quotes first
20161005 08:53:09< vultraz> Note To Self: update the various entries about the gui tasks in EasyCoding and NotSoEasyCoding
20161005 08:53:12< shadowm> The diagnostics for emplace-style functions are absolutely horrid.
20161005 08:56:25-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161005 08:56:43< vultraz> I could probably make the tab_container widget myself
20161005 08:58:32< vultraz> might not even need to be a widget
20161005 08:58:58< shadowm> What would it be otherwise? A variant of horizontal_listbox?
20161005 08:59:35< shadowm> And most of the behavior and styling comes from ttoggle_panel.
20161005 08:59:45< vultraz> hm, true
20161005 08:59:55< vultraz> a widget would allow styling
20161005 09:00:31< vultraz> I probably wouldn't stick the stacked_widget and the listbox in the same widget, though
20161005 09:00:49< vultraz> so it'd probably just be a tab_bar that takes a reference to the stacked_widget
20161005 09:01:10< vultraz> since certain dialogs like Mp Create don't stick the tab bar and stack next to each other
20161005 09:05:37-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has quit [Ping timeout: 244 seconds]
20161005 09:11:31< zookeeper> hooray, building succeeds again.
20161005 09:17:06-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has joined #wesnoth-dev
20161005 09:42:17-!- Jetrel [~Jetrel@2001:558:6014:1e:2422:435:dd84:bbf3] has quit [Read error: Connection reset by peer]
20161005 09:43:06-!- Jetrel [~Jetrel@2001:558:6014:1e:2422:435:dd84:bbf3] has joined #wesnoth-dev
20161005 09:54:26-!- Nobun [~nobun@host254-21-dynamic.52-82-r.retail.telecomitalia.it] has quit [Quit: Salve a tutti]
20161005 09:54:47-!- RatArmy [~RatArmy@om126211120130.13.openmobile.ne.jp] has joined #wesnoth-dev
20161005 09:57:10< vultraz> zookeeper: when did it not
20161005 09:57:12< vultraz> ?
20161005 09:57:40< zookeeper> ever since some boost upgrade earlier this year
20161005 09:58:14< vultraz> whut
20161005 10:02:51-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161005 10:06:53< zookeeper> hrhm. i can't get my new editor option to appear alongside "draw hex coordinates" and "draw terrain codes". the option works via hotkey, but the item in the menu isn't there.
20161005 10:07:19< zookeeper> and i've done everything that those two options do
20161005 10:10:28-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161005 10:10:35< zookeeper> is there some GUI2 stuff that i need to edit? because if there is, it has no connection to those two existing options
20161005 10:11:39< vultraz> not that I know of
20161005 10:14:25< zookeeper> ohh themes/editor.cfg
20161005 10:15:45< zookeeper> perfect
20161005 10:18:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 10:23:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20161005 10:23:49-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161005 10:32:01-!- RatArmy [~RatArmy@om126211120130.13.openmobile.ne.jp] has quit [Quit: Leaving]
20161005 10:40:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161005 10:46:09-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Quit: I'll be back!]
20161005 10:56:09-!- atarocch [~atarocch@176.246.115.252] has quit [Ping timeout: 248 seconds]
20161005 11:08:19< zookeeper> ah, finished. so, i have a new editor menu item to toggle display of how many terrain graphics bitmaps there are per hex, similar to "draw hex coordinates" and "draw terrain codes". a bit niche, but handy for spotting unnecessary bleeding across hex borders if one wants to.
20161005 11:09:28< zookeeper> (also good for educational purposes to illustrate how the terrain drawing system works :p)
20161005 11:13:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 11:17:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20161005 11:26:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161005 11:35:14-!- irker058 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161005 11:37:55-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161005 11:50:57-!- fabi [~fabi@176.5.137.156] has quit [Read error: No route to host]
20161005 12:06:11-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has quit [Ping timeout: 272 seconds]
20161005 12:23:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 12:28:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20161005 12:29:00-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Quit: Page closed]
20161005 12:45:05-!- Bonobo [~Bonobo@2001:44b8:254:3200:d41d:235d:593c:c057] has quit [Ping timeout: 252 seconds]
20161005 12:54:02-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161005 12:55:37-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 248 seconds]
20161005 12:58:59-!- atarocch [~atarocch@host-93-101-8-142.lottomatica.net] has joined #wesnoth-dev
20161005 12:59:00-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161005 13:06:04-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161005 13:10:42-!- Appleman1234 [~Appleman1@KD106154011107.au-net.ne.jp] has quit [Ping timeout: 264 seconds]
20161005 13:10:51-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161005 13:12:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20161005 13:12:32-!- wedge010 is now known as wedge009
20161005 13:23:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161005 13:23:31-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161005 13:27:01-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has joined #wesnoth-dev
20161005 13:32:42-!- irker147 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161005 13:32:42< irker147> wesnoth: mattsc wesnoth:master ac1d8c886c68 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update Xcode project https://github.com/wesnoth/wesnoth/commit/ac1d8c886c683a66dce30661a78ca9eb18f784ea
20161005 13:43:01-!- Appleman1234 [~Appleman1@KD106154002212.au-net.ne.jp] has joined #wesnoth-dev
20161005 13:46:30-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev
20161005 14:05:16-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161005 14:05:29-!- boucman_work [~boucman@fw-alt.idf.smile.fr] has quit [Ping timeout: 248 seconds]
20161005 14:38:54-!- Netsplit *.net <-> *.split quits: AI0867, Jetrel, vultraz, nore
20161005 14:39:02-!- Netsplit over, joins: AI0867
20161005 14:39:08-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161005 14:39:22-!- Netsplit over, joins: Jetrel
20161005 14:39:35-!- Netsplit over, joins: nore
20161005 14:41:59-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161005 14:46:09< zookeeper> i guess no one will mind if i just push the aforementioned thing directly to master...
20161005 14:47:05-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161005 15:02:11-!- ggeneral [~ggeneral@48.175.47.77.pptp.ntu-kpi.kiev.ua] has joined #wesnoth-dev
20161005 15:21:15-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161005 15:22:12< irker147> wesnoth: ln-zookeeper wesnoth:master 5d347bb61be2 / / (16 files in 7 dirs): Added a "Draw Number of Bitmaps" option to the editor https://github.com/wesnoth/wesnoth/commit/5d347bb61be2b00fca7e44f9ca18c6236bb4093c
20161005 15:22:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161005 15:22:47-!- tad_ [~Gregory@173.217.65.103] has joined #wesnoth-dev
20161005 15:23:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Read error: Connection reset by peer]
20161005 15:23:56< zookeeper> finally i have that out of my list of annoying local changes i need to do the stash routine for almost every time i pull
20161005 15:25:17< tad_> Am I doing something wrong, or is the MSVC build of Wesnoth expected to produce a bazilion errors in Boost due to template mistakes, and a bazilion more in our code due to size_t conversion problems (and 2 where vultraz stashes non-pointers into void* for SDL)
20161005 15:25:40< zookeeper> i'd bet on the former
20161005 15:25:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161005 15:27:13< tad_> Which is why I asked. I'm using the VS project, so I'm at a loss what to change to quiet things down.
20161005 15:27:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161005 15:27:57< zookeeper> VC12?
20161005 15:29:28< tad_> Current version. VS15 / MSVC14
20161005 15:36:46-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161005 15:38:04-!- ggeneral [~ggeneral@48.175.47.77.pptp.ntu-kpi.kiev.ua] has left #wesnoth-dev []
20161005 15:54:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161005 15:58:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 15:58:54-!- JyrkiVesterinen [~JyrkiVest@89-166-117-140.bb.dnainternet.fi] has joined #wesnoth-dev
20161005 15:59:24-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20161005 16:05:51< JyrkiVesterinen> tad_: I last built Wesnoth with MSVC yesterday (successfully), but I'm using the 2013 version.
20161005 16:07:29< tad_> I'm checking some things. First guess, IIRC, someone said we can't do 64-bit Windows so I forced the projects to all change to 32-bit (sigh) and now I have to slog through all the linker errors.
20161005 16:08:06< JyrkiVesterinen> At least the project file is set to make 32-bit builds by default. I haven't even tried 64-bit.
20161005 16:08:45< tad_> Probably something I did and didn't even realize when it was updating the project files.
20161005 16:09:00< JyrkiVesterinen> I have MSVC2015 as well, so I'll try building with it too.
20161005 16:10:22< tad_> Finding all the libraries needed was a pain in the $#@$ .. I was fine until Cairo and Pango .. they don't really have windows builds for those projects
20161005 16:11:10< JyrkiVesterinen> I'm using the https://github.com/aquileia/external repository instead of hunting the dependencies for myself.
20161005 16:11:45< JyrkiVesterinen> Are you still set on the idea of sharing a single repository across all the build environments?
20161005 16:11:51-!- atarocch [~atarocch@host-93-101-8-142.lottomatica.net] has quit [Ping timeout: 265 seconds]
20161005 16:12:19< tad_> I might have to do that but it does something strange with the file structure.
20161005 16:14:16< tad_> "set" not really how I'd put it. But it's not a problem to do. I just need to do it. First I want to get VS15 able to compile it then I'll look at linking the repos
20161005 16:16:37< JyrkiVesterinen> Build started. I'm getting a ton of warnings about declarations hiding each other, but no errors yet.
20161005 16:17:51< tad_> No errors .. a bazion 'note' messages having to do with boost templates, and another about size_t conversions, and a couple about SDL using a void* and someone (vultraz?) stashing an int in them
20161005 16:18:40< tad_> Right now I'm trying a rebuild of Boost to fix a linker error about a missing boost lib. Apparently the windows pre-builts as missing a couple.
20161005 16:23:35-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has joined #wesnoth-dev
20161005 16:24:50-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has quit [Remote host closed the connection]
20161005 16:27:02-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has joined #wesnoth-dev
20161005 16:30:10< JyrkiVesterinen> The MSVC2015 build passed.
20161005 16:32:12< JyrkiVesterinen> There is a lot of warnings like
20161005 16:32:14< JyrkiVesterinen> 4>i:\battle for wesnoth\wesnoth\src\map\location.hpp(122): warning C4458: declaration of 'x' hides class member (compiling source file ..\..\src\widgets\scrollbar.cpp)
20161005 16:32:14< JyrkiVesterinen> 4>  i:\battle for wesnoth\wesnoth\src\map\location.hpp(126): note: see declaration of 'map_location::x' (compiling source file ..\..\src\widgets\scrollbar.cpp)
20161005 16:32:36< JyrkiVesterinen> The code is innocent enough IMO.
20161005 16:32:38< JyrkiVesterinen> void add(int x, int y) { this->x += x; this->y += y; }
20161005 16:33:09< JyrkiVesterinen> It's convenient to be able to use these one-character names for both member variables and parameters.
20161005 16:33:22< tad_> yes, forgot about the hiding thing. size_t is special you really can't treat it as an int and be really portable. but it's often misused like that.
20161005 16:33:35< JyrkiVesterinen> Does anyone object to just disabling warning C4458?
20161005 16:33:43< tad_> I do.
20161005 16:34:09< tad_> I'd rather fix it. It is there because it's easy to forget this 'x' is not that 'x'
20161005 16:34:21< JyrkiVesterinen> OK. Then the next option would be renaming the method parameters.
20161005 16:35:30< tad_> gcc should catch those too. so, if someone disabled them for gcc and clang I'd say disable it and file a bug report that is should be turned back on.
20161005 16:39:19< JyrkiVesterinen> Strict Travis builds are done with "-Wall -Werror -Wno-unused-local-typedefs -Wno-deprecated-declarations"
20161005 16:42:21< JyrkiVesterinen> I'll add an underscore to the end of those parameter names. (Reverse of the usual Wesnoth policy of suffixing member variables with it.)
20161005 16:43:26< tad_> Or ignore me and disable the message since gcc seems to not produce it. If it were my project I'd reject simply added _ to make it different.
20161005 16:43:46< tad_> "Not different enough!"
20161005 16:47:47< JyrkiVesterinen> You're right. The parameters have a different meaning than the member variables.
20161005 16:48:04< JyrkiVesterinen> The member variables are location: the parameters are a difference (or a delta).
20161005 16:48:15< JyrkiVesterinen> I'll name the parameters x_diff and y_diff, then.
20161005 16:51:21< tad_> I'm giving up and cloning that external repo maybe he keeps up-to-date enough. I do hate depending on unknown third parties but the cairo/pango people are too lazy and I don't feel up to doing a true Windows build because they won't
20161005 16:53:49< tad_> You know, someday someone should go through and fix all those includes from within the project but from a different directory.
20161005 16:55:47< tad_> -I.. -I../.. is just wrong
20161005 16:56:01< JyrkiVesterinen> Bad news. Some of these C4458 warnings are caused by Boost.
20161005 16:56:59< tad_> JyrkiVesterinen, Leave it. Bugreport it to them; but I expect they know and don't care or will get to it eventually.
20161005 16:57:11-!- mjs-de [~mjs-de@x4e304b80.dyn.telefonica.de] has joined #wesnoth-dev
20161005 16:57:36< tad_> Boost has problems on gcc, we ignore them there, too.
20161005 16:57:59< JyrkiVesterinen> Well, by far the majority of the warnings was caused by two functions in location.hpp.
20161005 16:58:16< JyrkiVesterinen> Merely fixing them brings the warning count down a lot.
20161005 16:59:35< tad_> Just so it's a manageable list you can reasonably scan and go 'Yep, ignore that' .. the problem with such a huge list is it's so easy to not see something important in the storm of meaningless junk
20161005 17:02:20< tad_> And we all know how good C++ is at producing meaningless junk, especially when you misuse Boost like we do.
20161005 17:03:38< JyrkiVesterinen> Indeed. I think C4458 is an overly aggressive warning, which is why I initially suggested disabling it instead of trying to fix it.
20161005 17:05:41< tad_> I start from the proposition the compiler designers have a good and valuable reason for the warnings and try to respect that whenever possible. While we can question that when it comes to Microsoft (how often does stuff like that purely for religious reasons), it is definitely true when it comes to gcc that those warnings really should be paid attention to
20161005 17:05:50-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161005 17:07:26< JyrkiVesterinen> https://msdn.microsoft.com/en-us/library/thxezb7y.aspx
20161005 17:07:41< JyrkiVesterinen> "/W4 displays level 1, level 2, and level 3 warnings, and all level 4 (informational) warnings that are not turned off by default. We recommend that you use this option only to provide lint-like warnings. However, for a new project, it may be best to use /W4 in all compilations; this will ensure the fewest possible hard-to-find code defects."
20161005 17:08:13< JyrkiVesterinen> We are using /W4. Microsoft itself recommends against it to some extent.
20161005 17:09:07< tad_> I'd go the other way. Use /W4 for dev builds. Only use a lesser level for RTM builds.
20161005 17:09:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 17:11:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 17:16:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161005 17:16:16-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20161005 17:20:18-!- mjs-de [~mjs-de@x4e304b80.dyn.telefonica.de] has quit [Remote host closed the connection]
20161005 17:20:33-!- prkc [~prkc@46.166.138.134] has joined #wesnoth-dev
20161005 17:22:22-!- gfgtdf [~chatzilla@x4e36ac54.dyn.telefonica.de] has joined #wesnoth-dev
20161005 17:24:45< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/master/src/playturn.cpp#L135-L141
20161005 17:25:04< JyrkiVesterinen> Interesting. MSVC2015 says that the latter "msg" hides the former one.
20161005 17:25:23< JyrkiVesterinen> From what I can tell, the former "msg" shouldn't even be in scope in line 141.
20161005 17:28:16< JyrkiVesterinen> In fact, it says that "msg" in line 285 hides the one in line 135, too.
20161005 17:29:43< tad_> Oh. That. I'd have to check but I think that's a standards-compliance issue. MSVC is warning you that you used msg in each of those if blocks but it's possible on older compilers that they would mask each other.
20161005 17:30:35< tad_> It's debatable whether it's better to ignore that error or use a different 'msg' name for each local context. msg_for_this, msg_for_that, etc.
20161005 17:31:38-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161005 17:31:56< tad_> So a casual reader does not get confused. And because, IIRC, to not redefine each other you need to read the TRs and not just the standards.
20161005 17:42:39-!- gfgtdf_ [~chatzilla@x4e32b082.dyn.telefonica.de] has joined #wesnoth-dev
20161005 17:43:43-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20161005 17:44:40< tad_> So, I checkout that external project and it does not include Boost? But it includes all the SDL/Cairo/Pango junk pre-built?
20161005 17:45:23-!- gfgtdf [~chatzilla@x4e36ac54.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20161005 17:45:33-!- gfgtdf_ is now known as gfgtdf
20161005 17:45:52< gfgtdf> JyrkiVesterinen: msvc is correct, the scope of teh variable declared in the if conditions ends after the else block.
20161005 17:46:07< gfgtdf> JyrkiVesterinen: i wonder why i dfont get that warning though since i use msvc 2015 aswell
20161005 17:47:31< tad_> gfgtdf /W3 or less?
20161005 17:51:04< gfgtdf> tad_: i use /W3
20161005 17:51:40< tad_> gfgtdf, That is why you don't see the warning. Use /W4 (and stand back)
20161005 17:52:29< gfgtdf> tad_: nah, knowing why i don't get the warning is enough, no need to test it.
20161005 17:53:17< tad_> gfgtdf, The VS projects use different /W and other settings depending on the target you selected. Most likely you are just building a release target?
20161005 17:55:48< gfgtdf> tad_: i always use release target, if i need to debug a specific cmplex code i temprarily add a a "pragma optimize off " at the top of that file. copy. I also copied the vs projectfiels when i frist cloned the repo which is > 2 years ago and updated it manually since then.
20161005 17:56:05-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Quit: Page closed]
20161005 17:56:40< gfgtdf> (which happens rareley since for most cases the debugging capability of the release build is enough.)
20161005 17:58:01< tad_> I'm struggling through the incorrect, outdated and misleading instructions to get Wesnoth to compile on VS 2015. I wasted yesterday trying to go to the original sites only to find that we use Cairo and Pango and they don't produce Windows binaries.
20161005 17:59:10< tad_> And, yes, I'm writing an up-to-date HOWTO once I figure out the cleanest, quickest way from Square 1 to "Wow, it works!"
20161005 17:59:40< JyrkiVesterinen> You can ask me for help if you want. I have followed the instructions in the wiki for the most part.
20161005 18:01:31< tad_> Well, I've got the clones of wesnoth and external and updated the VS projects to VC14 and now I get that there are no Boost libraries. So .. first, I'm trying the Boost pre-built and of that won't work I guess it's the ol'by-hand and wait method
20161005 18:02:46< JyrkiVesterinen> Hmm. The existing VS project should already be set to use Boost from the external directory.
20161005 18:03:02< JyrkiVesterinen> Do you have external next to wesnoth (not inside it)?
20161005 18:03:43< tad_> Yes. Is easy. Clone it and take the defaults. VS puts it in the right place if you don't dick with the defaults.
20161005 18:05:52< tad_> I checked the external repo and no boost. readme.md has instructions for the ol'by-hand method. Boost has pre-builts which would be faster and easier if they work so checking those first
20161005 18:06:53< JyrkiVesterinen> Ah. You're in the wrong branch in the external repository.
20161005 18:07:03< JyrkiVesterinen> You need to check out the VC14 branch.
20161005 18:07:51< tad_> OK.
20161005 18:12:27< tad_> NP. I'll fix that in a minute when Boost finishes installing. I'm leaving it in so I have 'vanilla' Boost from the source installed if I ever decide to use it. It's just bytes on the disk and I've go LOTS of those available.
20161005 18:22:14-!- irker147 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161005 18:25:06< tad_> JyrkiVesterinen, Are you doing a PR or merging the fixes for those warnings?
20161005 18:25:20< JyrkiVesterinen> I'm planning to push directly.
20161005 18:25:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 18:26:05< tad_> OK. Can you add the following define to the project files for preprocessing: _WIN32_WINNT=0x0501
20161005 18:26:26< tad_> That tells Boost we're running Windows XT, or later, and it does not need to worry about Window 3.1
20161005 18:27:30< tad_> It's a project-file-only change. Boost assumes it if it's not there.
20161005 18:27:43< JyrkiVesterinen> That's a bit hard to do at the moment. Remember, I'm using MSVC2015 right now.
20161005 18:28:01< JyrkiVesterinen> As the wiki instructs, I created a copy of project files for it.
20161005 18:28:22< JyrkiVesterinen> The changes I'd make to project files wouldn't affect the real (versioned) project files.
20161005 18:30:42< tad_> OK. Well, maybe someday then.
20161005 18:36:27< tad_> Ah. I see the problem with the project files. The wiki assumes you're fine with fiddling before you start VS but the best way to get here is using VS .. so I need to tell how to hack Wesnoth using VS _before_ you open the project.
20161005 18:49:25-!- mjs-de [~mjs-de@x4e304b80.dyn.telefonica.de] has joined #wesnoth-dev
20161005 18:54:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 18:59:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161005 19:05:32-!- gfgtdf [~chatzilla@x4e32b082.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20161005 19:06:20-!- gfgtdf [~chatzilla@x4e32b082.dyn.telefonica.de] has joined #wesnoth-dev
20161005 19:08:25-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20161005 19:09:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161005 19:10:54-!- mjs-de [~mjs-de@x4e304b80.dyn.telefonica.de] has quit [Remote host closed the connection]
20161005 19:13:57-!- gfgtdf_ [~chatzilla@x4e32b082.dyn.telefonica.de] has joined #wesnoth-dev
20161005 19:14:15-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161005 19:16:00-!- gfgtdf [~chatzilla@x4e32b082.dyn.telefonica.de] has quit [Ping timeout: 265 seconds]
20161005 19:16:07-!- gfgtdf_ is now known as gfgtdf
20161005 19:17:10< vultraz> tad_: the MSVC files are not my area
20161005 19:17:14-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 252 seconds]
20161005 19:17:14-!- wedge010 is now known as wedge009
20161005 19:18:01-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161005 19:18:14< tad_> But stuffing an int into a void* for SDL ... maybe not your doing but poor form.
20161005 19:18:50< vultraz> eh?
20161005 19:18:52< vultraz> where?
20161005 19:19:30-!- ancestral [~ancestral@8.42.164.20] has joined #wesnoth-dev
20161005 19:19:36< celticminstrel> ???
20161005 19:20:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 19:20:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 19:20:58< JyrkiVesterinen> For the record, I have been wading through the MSVC2015 warnings quite long at this point, and I'm yet to see any warnings other than declaration hiding.
20161005 19:20:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 19:29:20< tad_> c:\users\lundberg\source\repos\external\include\boost\bind\placeholders.hpp(54): note: see reference to class template instantiation 'boost::arg<9>' being compiled
20161005 19:29:42< tad_> I see a lot, more complex, but that is one of the more clear examples.
20161005 19:30:16< vultraz> celticminstrel: so, I'm working on a tab_bar widget, having a design problem... I figured for this, it'd kinda be a wrapper, and still keep [definition] and [data] tags and forward their contents to the listbox widget at build time.
20161005 19:30:26< vultraz> celticminstrel: not sure how one would do this, though
20161005 19:30:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161005 19:31:04< vultraz> I assume child widgets are dealt with in init_grid... perhaps manually editing the resolution config?
20161005 19:31:43< celticminstrel> I don't really get why you're asking me...
20161005 19:31:46< wedge009> tad_: JyrkiVesterinen: I've wondered about those scope warnings too, but I just thought they came from existing code and since there were dozens and dozens of those warnings I didn't try to touch it. If it mostly comes from boost, well, that's another thing.
20161005 19:31:59< celticminstrel> Or what you're asking me, even.
20161005 19:33:17< tad_> wedge009, There are some SO comments about them. Those in our code we can fix (dunno how) most are from Boost but if you track down the chain they start from our code. So dunno if we caused them or Boost. Needs research.
20161005 19:33:32< wedge009> SO?
20161005 19:33:33< vultraz> trying to figure out a way to move tags from one tag's wml at the call site to a child widget's wml in the widget definition wml
20161005 19:33:39< vultraz> or even if that's a good idea
20161005 19:33:40< tad_> Stack Overflow
20161005 19:33:49< wedge009> Right.
20161005 19:34:08< celticminstrel> vultraz: Is this like tinstance and treplacements?
20161005 19:34:32< wedge009> I'll have a closer look next time I compile, then.
20161005 19:34:38< JyrkiVesterinen> wedge009: Nearly all of scope warnings come from our code.
20161005 19:34:54< wedge009> Okay.
20161005 19:35:09< JyrkiVesterinen> I mentioned the Boost ones simply because it's not possible to fix all the scope warnings as long as even one of them comes from Boost.
20161005 19:35:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 19:35:17< wedge009> I wouldn't write stuff that way, but I thought that's just a convention here.
20161005 19:35:28< vultraz> pretty sure I'm calling tcontainer_::init_grid...
20161005 19:35:47< vultraz> which takes a grid_builder_ptr and calls its build member
20161005 19:36:05< vultraz> build does have an overload that deals with treplacements
20161005 19:36:08< vultraz> but idk what treplacements is
20161005 19:36:13< vultraz> and it's not called here.
20161005 19:36:14< JyrkiVesterinen> In addition, some of the scope warnings are pretty hard to fix. For example, scope logging macros create a named local parameter. If you use two of them in the same scope, you get a warning.
20161005 19:36:36< JyrkiVesterinen> I'll fix just the easy ones.
20161005 19:37:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 19:37:50< vultraz> hmmmm
20161005 19:37:55< vultraz> "	 * Certain widgets need to build a part of themselves upon instantiation
20161005 19:37:56< vultraz> 	 * but at the time of the definition it's not yet known what exactly. By
20161005 19:37:58< vultraz> 	 * using and `[instance]' widget this decision can be postponed until
20161005 19:37:59< vultraz> 	 * instantiation."
20161005 19:38:07< vultraz> this sounds like what I need
20161005 19:38:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 19:38:23< celticminstrel> I think only the matrix widget uses it currently.
20161005 19:38:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 19:39:39< vultraz> ahhh
20161005 19:40:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 19:40:55-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161005 19:41:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 19:43:42< vultraz> why does the matrix have a tcontrol_NEW class...
20161005 19:50:29-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161005 19:51:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 19:52:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 19:52:46-!- ancestral [~ancestral@8.42.164.20] has quit [Quit: i go nstuf kthxbai]
20161005 20:24:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 20:25:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 20:26:10< vultraz> hm
20161005 20:26:20< vultraz> where exactly is the matrix build function called
20161005 20:26:22< vultraz> from
20161005 20:28:08< vultraz> oh, no
20161005 20:28:22< vultraz> so the builder build function
20161005 20:28:33< vultraz> calls... the tmatrix build function
20161005 20:28:53< vultraz> ...
20161005 20:29:55< vultraz> celticminstrel: I don't understand this :|
20161005 20:31:43< vultraz> how is tbuilder_matrix::build calling tmatrix::build (which is static) which constructs a new tmatrix and then builds the widget in the constructor different from doing everything in tbuilder_matrix::build
20161005 20:33:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 20:36:43< celticminstrel> I don't really know.
20161005 20:36:51< celticminstrel> I don't understand the [instance] stuff either.
20161005 20:36:53< celticminstrel> Ask mordante?
20161005 20:40:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 20:40:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 20:41:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 20:57:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 21:03:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 21:12:30-!- irker413 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161005 21:12:30< irker413> wesnoth: Jyrki Vesterinen wesnoth:master af733360a814 / src/ (69 files in 28 dirs): Fix a bunch of MSVC2015 compiler warnings about hiding declarations https://github.com/wesnoth/wesnoth/commit/af733360a81405505673687b935a637ddedae861
20161005 21:16:35< vultraz> ermeghard
20161005 21:17:04-!- Bonobo [~Bonobo@2001:44b8:254:3200:e484:ecdc:5f1e:4455] has joined #wesnoth-dev
20161005 21:17:36< vultraz> cleanup! \ o /
20161005 21:22:56< matthiaskrgr> o.o
20161005 21:32:57-!- JyrkiVesterinen [~JyrkiVest@89-166-117-140.bb.dnainternet.fi] has quit [Quit: Going to bed]
20161005 21:37:18< tad_> Yea!
20161005 21:38:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 21:47:01-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161005 21:47:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161005 21:47:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 21:51:27< tad_> Something is obviously not right. VS15 building wesnothd: error LNK2019: unresolved external symbol __imp__PathIsRootW@4
20161005 21:52:59< wedge009> tad_: I fixed that in VC12 project files. You might need to reflect it in your own VC14 build.
20161005 21:53:07< wedge009> Need to link Shlwapi.lib
20161005 21:53:25< tad_> OK. How recently? Today?
20161005 21:53:27< wedge009> JyrkiVesterinen: Thanks for that, I'll give it a try after work.
20161005 21:54:03< wedge009> tad_: Last night for me... 08:04 UTC if you must now.
20161005 21:54:10< wedge009> *know
20161005 21:54:13-!- travis-ci [~travis-ci@ec2-54-146-40-21.compute-1.amazonaws.com] has joined #wesnoth-dev
20161005 21:54:14< travis-ci> wesnoth/wesnoth#11330 (master - af73336 : Jyrki Vesterinen): The build has errored.
20161005 21:54:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165361097
20161005 21:54:14-!- travis-ci [~travis-ci@ec2-54-146-40-21.compute-1.amazonaws.com] has left #wesnoth-dev []
20161005 21:56:07< tad_> OK. Thanks.
20161005 21:57:52< gfgtdf> JyrkiVesterinen: did you test that is all still works? whne you change codes like 'config *active = get_node(cfg_, namespace_);' to 'active = get_node(cfg_, namespace_);' you do change behaviour if 'active' is used outside that scope.
20161005 21:58:56< gfgtdf> JyrkiVesterinen: also i dont think changes like 'unit* unit = luaW_tounit(L, arg, true);' and then changing all later 'unit' to '::unit' makes things easier to read.
20161005 22:09:21< wedge009> exit
20161005 22:09:27< wedge009> Bah, wrong window. >.<
20161005 22:27:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 22:29:02< celticminstrel> Why does tfile_dialog::confirm_overwrite never actually check that the file exists? Where is that check done? It doesn't show the confirmation even if the file doesn't exist, does it?
20161005 22:32:56< tad_> wedge009, So what do I have to do? I copied all of VC12 to VC14 and still get the link error
20161005 22:33:48< wedge009> tad_: Shouldn't have needed to do that. Just add Shlwapi.lib to the Linker -> Input section of the wesnoth and wesnothd VC projects.
20161005 22:37:07< matthiaskrgr> game is broken 
20161005 22:37:23< matthiaskrgr> "error loading the core with named id" 
20161005 22:37:30< matthiaskrgr> error loading core data 
20161005 22:37:54< matthiaskrgr> it even crashes while trying to exit :< 
20161005 22:39:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 22:40:29< tad_> wedge009, schema_generator does not need to be compiled? I get the error in it, too, and adding Shlwapi.lib didn't fix it.
20161005 22:41:16< celticminstrel> schema_generator does not need to be compiled, no.
20161005 22:41:19< tad_> wesnothd built. wesnoth will be an hour or so
20161005 22:42:00< vultraz> an *hour*??
20161005 22:42:13< tad_> Maybe more
20161005 22:42:27< vultraz> why!
20161005 22:42:34< wedge009> I don't know what you have set-up in your projects. schema_generator doesn't look like it refers to filesystem_boost, so don't know why it's including shlwapi.h
20161005 22:43:09< tad_> me? my project is sync master, copy vc12 to vc14 and try it.
20161005 22:43:50< tad_> been at it for a day or so now and still can't get a working wesnoth.
20161005 22:45:34< vultraz> ok, I need to figure out how to pass the list_data from the widget to the builder..
20161005 22:46:05< vultraz> I'm using an [instance] for the toggle_panel...
20161005 22:46:10< vultraz> 's internals
20161005 22:46:24< tad_> As to 'an hour or so' it has to compile everything because the project changed.
20161005 22:47:04< vultraz> tad_: yes, but... an hour? I can do a full rebuild in ~20 mins
20161005 22:48:31< tad_> vultraz, well, for me it takes an hour or two. I've been getting plenty of naps.
20161005 22:51:13< vultraz> hmmm
20161005 22:51:20< vultraz> is config::find_child recursive...
20161005 22:51:30< celticminstrel> Probably not?
20161005 22:51:40< celticminstrel> Check for yourself though.
20161005 22:52:52< vultraz> hm
20161005 22:53:02< vultraz> can't really tell but it looks like not?
20161005 22:53:55< celticminstrel> If it's recursive, it would be calling itself. :P
20161005 22:54:12< celticminstrel> So it should be easy to tell.
20161005 22:54:16< vultraz> ah
20161005 22:54:17< vultraz> no
20161005 22:54:34< vultraz> really not sure what to do, then..
20161005 22:54:44< celticminstrel> Why do you need a recursive find?
20161005 22:55:02 * celticminstrel notes that it's not all that hard to implement one using find_child()
20161005 22:55:08< vultraz> I was thinking merge the widgets' [tab_data] config into the widget definition's listbox's list_data tag
20161005 22:55:41< vultraz> since list_data needs to be present at build time
20161005 22:55:50< vultraz> there's no function to populate a list from it
20161005 22:56:10< vultraz> unless..
20161005 22:56:10< celticminstrel> Why does that require a recursive find?
20161005 22:56:14< vultraz> I manually use add_row..
20161005 22:56:27< celticminstrel> Don't you know exactly where to find the [tab_data] in the config?
20161005 22:56:47< celticminstrel> If it's not directly in the config, just use a chain of child() calls.
20161005 22:57:19< vultraz> yes, I know where it is
20161005 22:57:30< vultraz> hmm
20161005 22:57:37< vultraz> there's set_list_builder..
20161005 22:57:59< vultraz> but that's called by the listbox's build
20161005 22:58:39< vultraz> ugh
20161005 22:58:48< vultraz> why should this be so complicated
20161005 23:01:49< celticminstrel> I don't really get why it needs to be a new widget.
20161005 23:02:29< celticminstrel> What's the difference between a "tab bar" and a "horizontal listbox", in terms of behaviour?
20161005 23:03:19-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161005 23:03:34< vultraz> the tab bar would also control the tab behavior
20161005 23:03:44< vultraz> and allow visual styling
20161005 23:03:49-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161005 23:03:57< vultraz> I suppose one could use a new listbox definition, but that seems... meh...
20161005 23:04:06< celticminstrel> Why?
20161005 23:04:12< vultraz> plus this method would reduce the amount of WML needed]
20161005 23:04:37< celticminstrel> Oh, so like not requiring a [list_definition] or whatever?
20161005 23:05:03< vultraz> it would, but it'd only contain the data within the [toggle_panel]
20161005 23:06:03< vultraz> so instead of [list_definition] [row] [column] [toggle_panel] [grid] [row] [stuff]
20161005 23:06:10< vultraz> you'd just have [tab_definition] [stuff]
20161005 23:07:39< vultraz> the alternative to a widget is a helper class that then would need to be in every dialog that uses tabs
20161005 23:07:42< vultraz> and a macro
20161005 23:07:44< vultraz> for the wml
20161005 23:07:49< vultraz> i felt that's a bit messy
20161005 23:08:47< celticminstrel> So you're trying to build your tab bar over the horizontal listbox widget?
20161005 23:08:52< vultraz> yes
20161005 23:08:57< vultraz> it's essentially a wrapper
20161005 23:09:02< celticminstrel> Is there any reason not to instead just use the generator directly, as the horizontal listbox does?
20161005 23:09:27< vultraz> I had considered that..
20161005 23:09:47< celticminstrel> I'm not sure if it would be any easier, mind you...
20161005 23:09:53< vultraz> but then we lose all listbox functionality
20161005 23:10:07< vultraz> or
20161005 23:10:08< vultraz> hm
20161005 23:10:11< celticminstrel> I suppose both ways of doing it are about the same.
20161005 23:10:14< vultraz> actually, no, some of that is in the generator
20161005 23:10:27< celticminstrel> You need to build a child widget, right?
20161005 23:10:43< vultraz> yes
20161005 23:11:03< vultraz> the thing I'm trying to figure out is how to initialize the listbox with the provided data
20161005 23:11:22< celticminstrel> I get the feeling that you're doing things in the wrong order.
20161005 23:11:49< celticminstrel> The config passed to the listbox builder should already have the [list_definition] and [list_data] in it.
20161005 23:12:04< vultraz> yes
20161005 23:12:06< vultraz> that's the problem
20161005 23:12:12< vultraz> so say you have a dialog
20161005 23:12:15< celticminstrel> Why is that a problem?
20161005 23:12:23< vultraz> and you have [tab_bar] [data]
20161005 23:12:47< celticminstrel> You can use the [tab_definition] and [tab_data] to construct a valid [horizontal_listbox] config.
20161005 23:12:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 23:13:02< vultraz> that's not how the build process works :|
20161005 23:13:20< celticminstrel> The builder takes a config in the constructor, right?
20161005 23:13:29< vultraz> they all do
20161005 23:13:44< vultraz> but you don't manually call child widget builders
20161005 23:14:24< celticminstrel> Well, calling them isn't the problem here.
20161005 23:14:37< celticminstrel> You need the config when constructing the child widget builder, not when calling it.
20161005 23:15:41< celticminstrel> (For the record, most of the horizontal listbox behaviour is either in the generator or in the scrollbar container, I believe. So you probably could directly use the generator if you want.)
20161005 23:15:55< vultraz> or I could make parse_list_data public
20161005 23:16:05< vultraz> and just use add_ro
20161005 23:16:07< vultraz> w
20161005 23:16:27< celticminstrel> What's the current visibility of parse_list_data?
20161005 23:16:42< celticminstrel> Actually, come to think of it...
20161005 23:16:46< vultraz> static implementation function
20161005 23:17:07< celticminstrel> Visibility is "public", "private", or "protected".
20161005 23:17:26< vultraz> it's not in the interface 
20161005 23:17:41< celticminstrel> You mean it's not in the class?
20161005 23:17:47< vultraz> yes
20161005 23:17:52< celticminstrel> You could have just said that.
20161005 23:17:54< celticminstrel> Okay.
20161005 23:18:07< celticminstrel> So, what is different between horizontal listbox and tab bar, besides the WML?
20161005 23:18:26< vultraz> the tab bar also controls the selected layer of a provided stacked_widget
20161005 23:18:29< celticminstrel> Should tab bar have things that horizontal listbox doesn't? Does horizontal listbox have things that tab bar shouldn't?
20161005 23:18:52< celticminstrel> Uhh.
20161005 23:19:21< celticminstrel> I'm not sure that I like the idea of the link between tab bar and stacked widget being baked into the tab bar.
20161005 23:19:29< celticminstrel> But setting that aside...
20161005 23:19:37< vultraz> somewhere I'll add an interface to specify an id or something of a stack
20161005 23:19:43< celticminstrel> If I recall correctly...
20161005 23:19:53< celticminstrel> The tlistbox class works for all three listboxes, right?
20161005 23:20:03< vultraz> yes
20161005 23:20:13< vultraz> and tabs can either be horizontal or vertical..
20161005 23:20:17< celticminstrel> So...
20161005 23:20:26< vultraz> (I haven't even figured out how to make THAT work, yet :| )
20161005 23:20:29< celticminstrel> Could you not just write a fourth listbox builder?
20161005 23:20:31< vultraz> (different definitions, maybe)
20161005 23:20:43< vultraz> ... what?
20161005 23:20:55< celticminstrel> BTW, for vertical tabs we need a vertical label.
20161005 23:21:09< vultraz> what?
20161005 23:21:20< celticminstrel> If you want vertical tabs, you need a vertical label.
20161005 23:21:22< vultraz> no?
20161005 23:21:25< celticminstrel> Yes?
20161005 23:21:30< vultraz> the sidebar in prefs is a vertical tab bar
20161005 23:21:36< celticminstrel> That's not a tab bar.
20161005 23:21:45< vultraz> yes it is..
20161005 23:21:53< celticminstrel> Not really.
20161005 23:22:07< vultraz> none of what we use is a "tab bar"!
20161005 23:22:20< vultraz> that's the point of this
20161005 23:22:23< celticminstrel> The horizontal ones could reasonably be described as one though.
20161005 23:22:36< vultraz> to have a standard wrapper around listboxes that control a stack with tabbed behavior
20161005 23:22:53< celticminstrel> I think maybe you're approaching this all wrong.
20161005 23:22:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 23:23:07< vultraz> then what would you propose!
20161005 23:23:25< celticminstrel> Rather than creating a "tab bar" widget that wraps a listbox, shouldn't you instead be creating a "tabbed widget" that wraps the stacked widget?
20161005 23:23:45< vultraz> ...no?
20161005 23:23:46< celticminstrel> And bakes in a listbox with it.
20161005 23:23:53< vultraz> remember
20161005 23:24:06< celticminstrel> This is related to what I just said:
20161005 23:24:07< vultraz> the stack and the tab have no set position
20161005 23:24:07< celticminstrel> [Oct 05@7:19:21pm] celticminstrel: I'm not sure that I like the idea of the link between tab bar and stacked widget being baked into the tab bar.
20161005 23:24:33< vultraz> the tab bar could be on any side of the stack
20161005 23:24:38< vultraz> or even not next to the stack!
20161005 23:24:42< vultraz> (like in mp create)
20161005 23:24:46< celticminstrel> True.
20161005 23:24:57< celticminstrel> I forgot about the MP create one.
20161005 23:25:17< vultraz> in game stats and prefs, the tab bar is under the stack
20161005 23:25:23< vultraz> also in prefs, to the left of the stack
20161005 23:25:28< vultraz> in game version, above the stack
20161005 23:25:58< vultraz> there is no extra interface needed for the stack
20161005 23:26:28< vultraz> all you need is a select_page call
20161005 23:26:29< celticminstrel> I haven't heard any evidence that the tab bar needs any extra interface either.
20161005 23:26:36< vultraz> the place with the redundant wml and c++ is the tab bar handling
20161005 23:26:56< vultraz> every dialog that has a tab needs to handle the select_page thing
20161005 23:27:10< celticminstrel> If you're only worried about redundant WML, you should be able to write a builder that eliminates that.
20161005 23:27:24< celticminstrel> ie, a builder that builds a listbox from different WML.
20161005 23:28:06-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20161005 23:28:44< vultraz> there's a problem with that
20161005 23:28:47< vultraz> the toggle panel
20161005 23:28:57 * celticminstrel wonders if there's precedent for something like this - a widget whose sole purpose is to control a different widget.
20161005 23:29:03< celticminstrel> I fail to see how that's a problem?
20161005 23:29:34< celticminstrel> The builder only has WML for input. It can do whatever it wants with that WML.
20161005 23:29:50< vultraz> here's the wml for the proposed tab_bar widget http://pastebin.com/djcJ9z2R
20161005 23:30:15< vultraz> essentially, you're saying the listbox would need to insert the toggle_panel
20161005 23:30:21< vultraz> in its builder
20161005 23:30:23< vultraz> into the config
20161005 23:30:29< celticminstrel> Basically.
20161005 23:30:42< vultraz> I don't like it
20161005 23:30:48< celticminstrel> Well, maybe it can be done in the definition. I dunno.
20161005 23:31:14< vultraz> I don't understand the internals of that enough to do that
20161005 23:31:42< vultraz> and i doubt it would even work
20161005 23:31:55< celticminstrel> Looking at that, I kinda understand now why you have a problem with the list data.
20161005 23:32:31< celticminstrel> BTW, does it actually work already like that? Apart from the list data problem.
20161005 23:32:40< celticminstrel> eg, if you use add_row manually, does it work?
20161005 23:32:48< celticminstrel> (Not that I'm recommending using add_row manually.)
20161005 23:32:55< vultraz> I have not tried
20161005 23:33:14< vultraz> because I need to get it to handle the data :|
20161005 23:34:08< celticminstrel> You've mentioned some ways of making it handle the data (like making something public or using add_row), so do one of those and see if it works. Then you can think about handling the data in a more proper way.
20161005 23:34:37< vultraz> a problem with making parse_row_data public..
20161005 23:34:43< vultraz> what do I use for req_cols :|
20161005 23:34:50< celticminstrel> What's req_cols?
20161005 23:34:58< vultraz> VALIDATE(static_cast<unsigned>(cols.size()) == req_cols, _("'list_data' must have the same number of columns as the 'list_definition'."));
20161005 23:35:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 23:35:25< celticminstrel> It should be the number of [column]s in the [tab_definition],
20161005 23:35:56< celticminstrel> (Speaking of which, that right there is another reason not to use parse_list_data in the final version - the error message would be wrong.)
20161005 23:36:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 23:36:50< vultraz> that can easily be fixed
20161005 23:37:06< vultraz> "Data must have the same number of columns as the definition"
20161005 23:38:44< celticminstrel> That's not how I'd fix it.
20161005 23:38:49< celticminstrel> I'd pass the tag name as a parameter.
20161005 23:38:54< vultraz> also, you're wrong
20161005 23:38:55< celticminstrel> Tag names, even.
20161005 23:39:00< vultraz> [10:35:23]	celticminstrel	It should be the number of [column]s in the [tab_definition],
20161005 23:39:16< vultraz> remember, that is validating the columns in *[list_definition]*
20161005 23:39:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161005 23:39:35< celticminstrel> That's not what the error message says?
20161005 23:39:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161005 23:39:45< vultraz> ie,[list_definition] [row] [column]
20161005 23:40:16< vultraz> but for the tab bar, our data will be in [list_definition][row][column][toggle_panel][grid][row][column]
20161005 23:40:53< vultraz> so acutually, our data formatting might be different! :
20161005 23:42:17< vultraz> probably just
20161005 23:42:23< vultraz> [row] [widget]
20161005 23:42:25< vultraz> no column
20161005 23:42:38< celticminstrel> One column.
20161005 23:43:05< celticminstrel> Probably.
20161005 23:43:36< vultraz> we might need our own data parser here
20161005 23:44:01< vultraz> the listbox one looks for a 1-1 parity with between definition and data columns
20161005 23:44:47< celticminstrel> Okay, so if parse_list_data has problems, what about add_row?
20161005 23:45:03< celticminstrel> Remember, the goal is to get something that basically works so you can start testing it.
20161005 23:45:18< celticminstrel> Then you can figure out a better way to do it if necessary.
20161005 23:45:26< vultraz> add_row is either string_map or map<string, string_map>
20161005 23:46:23< vultraz> I think I'll make  custom data parser here
20161005 23:46:37< vultraz> a*
20161005 23:46:55< vultraz> so the syntax would be like
20161005 23:47:33 * celticminstrel sighs.
20161005 23:47:39< celticminstrel> Fine, do whatever you want.
20161005 23:47:51< celticminstrel> (Though I do recommend talking to others about the design.)
20161005 23:47:58< vultraz> [tab_data] [tab] [widget]
20161005 23:48:13< vultraz> one [tab] per entry
20161005 23:57:25< matthiaskrgr> can someone plz fix the game starting? :| 
20161005 23:57:38< matthiaskrgr> (or rather, not starting)
20161005 23:59:11< vultraz> latest master?
20161005 23:59:41< matthiaskrgr> yes
--- Log closed Thu Oct 06 00:00:06 2016