--- Log opened Sat Oct 17 00:00:07 2015
20151017 00:05:30-!- Appleman1234 [~Appleman1@KD118156250145.au-net.ne.jp] has joined #wesnoth-dev
20151017 00:12:22-!- durp [47c717ed@gateway/web/freenode/ip.71.199.23.237] has joined #wesnoth-dev
20151017 00:24:51-!- neverEnough [~nEnough@host73-2-dynamic.117-80-r.retail.telecomitalia.it] has joined #wesnoth-dev
20151017 00:30:21-!- durp [47c717ed@gateway/web/freenode/ip.71.199.23.237] has quit [Quit: Page closed]
20151017 00:51:16-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20151017 00:54:56-!- joet [~joet@host86-163-223-158.range86-163.btcentralplus.com] has joined #wesnoth-dev
20151017 01:11:12< neverEnough> i'm new to git, i just committed to my github wesnoth's cloned fork and asked for a pull
20151017 01:11:41< neverEnough> i'm unsure if it went correctly
20151017 01:12:10-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20151017 01:13:33< shadowm> Hm. It's "tab completion", not "tab completition".
20151017 01:13:57< neverEnough> ouch -.-'
20151017 01:14:56< neverEnough> hm should i revert the commit? (if it is even possible..)
20151017 01:16:26< shadowm> The PR and commit itself looks fine, except that: 1) the subject line is a subject line, so you don't need (and in fact, shouldn't use) a stop at the end of the sentence; 2) some `git status`-style output wound up in the commit message itself for some reason (the "On branch master\nChanges to be committed" cruft).
20151017 01:16:44< shadowm> (1) is minor observation but (2) is more important.
20151017 01:16:47< shadowm> *is a
20151017 01:17:34< shadowm> The code itself looks fine.
20151017 01:18:26-!- Appleman1234 [~Appleman1@KD118156250145.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20151017 01:19:00< shadowm> A couple things missing though: since this is (as far as I'm aware, correct me if I'm wrong) your first contribution, you should add yourself to the game credits under the Miscellaneous Contributors section in data/core/about.cfg (alphabetical order please); also, this is a user-visible feature, so it warrants changelog entries both in /changelog and /players_changelog.
20151017 01:19:36< neverEnough> oh nice!
20151017 01:19:50< neverEnough> yes it's my first one
20151017 01:20:00< shadowm> For the changelog entries you can and should use a separate commit, since those are conflict-prone files.
20151017 01:20:08< neverEnough> ok
20151017 01:20:12< shadowm> Same PR, though.
20151017 01:20:20< neverEnough> PR = ?
20151017 01:20:25< shadowm> Pull request.
20151017 01:20:31< neverEnough> ok
20151017 01:20:38< neverEnough> is pull request reversible?
20151017 01:20:40< shadowm> You should be able to push commits to the same repository and branch you pushed your original commit to, and they will be added to the PR automatically.
20151017 01:21:00< neverEnough> ok
20151017 01:21:04< shadowm> Likewise, removing or rewriting the original commit and pushing will update the PR as well.
20151017 01:21:42< neverEnough> about the 2) : where did i mistake?
20151017 01:22:02< shadowm> If you are using the command-line version of Git, a simple way to rewrite the last commit in the current branch is to use `git commit --amend`.
20151017 01:22:16< neverEnough> yes i'm on cli
20151017 01:22:36< shadowm> neverEnough: As I said, at the end of the message there's a line "On branch master" and other stuff following it, which is normally part of the `git status` output and also the commit message template.
20151017 01:23:03< shadowm> In the template those lines are only included for reference purposes and they are commented out with a # so that they shouldn't normally end up in the real message.
20151017 01:23:45< neverEnough> ah ok
20151017 01:26:05< shadowm> (Also, if you do use --amend to rewrite the commit, Git will refuse to push to the same remote branch unless you use `git push -f`. This is a safety measure to prevent accidents where you would unintentionally overwrite changes in the remote repository, but since this is your personal fork you know that that is exactly what you want to do.)
20151017 01:28:57< neverEnough> shadowm, about updating contributors: should i edit only data/core/about.cfg or also the other 2?
20151017 01:29:29< shadowm> Only data/core/about.cfg holds the game credits.
20151017 01:29:34< neverEnough> ok 
20151017 01:36:00< celticminstrel> Hmm.
20151017 01:36:37< celticminstrel> And now you have to rebase.
20151017 01:36:50< celticminstrel> Actually, no, probably better to reset.
20151017 01:36:58< celticminstrel> And then just redo the credits add.
20151017 01:37:14< celticminstrel> git reset --hard f35f3e3
20151017 01:37:21< celticminstrel> neverEnough: ^
20151017 01:37:31< neverEnough> yo
20151017 01:37:36< celticminstrel> Then git commit --amend
20151017 01:38:00< celticminstrel> And remove everything after your description (the "On branch master" and such).
20151017 01:38:17< celticminstrel> Then deal with the credits and changelogs.
20151017 01:38:19< celticminstrel> And finally:
20151017 01:38:21< celticminstrel> git push --force
20151017 01:39:12< neverEnough> yay thank you very much, i was a bit lost
20151017 01:39:26< neverEnough> now commit message should be fixed
20151017 01:39:28< celticminstrel> Good, looks like you've fixed it. :)
20151017 01:39:43< celticminstrel> Now you just have to deal with the credits and changelog.
20151017 01:40:02< celticminstrel> Actually you could cherry-pick the credits probably... if you can find the hash...
20151017 01:40:09< celticminstrel> Probably easier to just redo it though.
20151017 01:41:26< celticminstrel> I'm guessing you tried "git push" and then followed the instructions when it errored, ie "git pull".
20151017 01:41:47< celticminstrel> Usually that's the right thing to do, but not always. :)
20151017 01:43:27< neverEnough> ehehe you got it right :)
20151017 01:43:55< neverEnough> i just read some short notes about git to get this done, still have to read the manual :)
20151017 01:44:25< neverEnough> ok guys, glad to be an official contrib :) Sleep time now, see you soon
20151017 01:44:33< neverEnough> (and thanks for support)
20151017 01:45:02-!- neverEnough [~nEnough@host73-2-dynamic.117-80-r.retail.telecomitalia.it] has quit [Quit: Sto andando via]
20151017 01:45:11< celticminstrel> He forgot the changelogs. Oh well.
20151017 01:46:55-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 252 seconds]
20151017 01:57:18-!- Shackra [~Jorge@186.177.2.148] has joined #wesnoth-dev
20151017 02:03:52< shadowm> Who wrote [store_relative_direction]?
20151017 02:15:28-!- Appleman1234 [~Appleman1@KD111239016171.au-net.ne.jp] has joined #wesnoth-dev
20151017 02:34:59-!- joet [~joet@host86-163-223-158.range86-163.btcentralplus.com] has quit [Ping timeout: 264 seconds]
20151017 02:36:30-!- Appleman1234 [~Appleman1@KD111239016171.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20151017 03:05:33-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 256 seconds]
20151017 03:07:57-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151017 03:09:21-!- Portaljacker [~Portaljac@modemcable081.139-178-173.mc.videotron.ca] has joined #wesnoth-dev
20151017 03:22:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20151017 03:22:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20151017 03:32:47-!- Appleman1234 [~Appleman1@KD118156244128.au-net.ne.jp] has joined #wesnoth-dev
20151017 03:33:45< fabi> rofl :-)
20151017 03:35:00< shadowm> fabi: Hi.
20151017 03:36:28< fabi> yeah, hi
20151017 03:37:27< shadowm> fabi: Forum account?
20151017 03:37:41< fabi> I don't mind.
20151017 03:37:55< shadowm> Yes, sure, but you need to tell me what the correct email address is.
20151017 03:38:08< fabi> I won't use it anymore.
20151017 03:38:17< fabi> Everything is fine.
20151017 03:38:21< shadowm> Oh. Okay then.
20151017 03:38:33< fabi> You can even delete it.
20151017 03:38:53< shadowm> We don't delete accounts without a good reason, especially not accounts with more than 10 mosts.
20151017 03:39:01< shadowm> Posts.
20151017 03:39:04< fabi> I have heard about some secret plan in ##shadowsomething about removing low and the editor.
20151017 03:39:11< fabi> I don't mind. 
20151017 03:39:16< fabi> just go on
20151017 03:39:23< shadowm> Oh ahahaha. Wow.
20151017 03:39:26< celticminstrel> ............
20151017 03:39:41< shadowm> You know that if I was speaking seriously that would've happened ages ago.
20151017 03:40:17< shadowm> And depending on the exact conversation, LoW is actually on the same list as HttT and NR.
20151017 03:40:32< fabi> please no
20151017 03:40:44< fabi> I do not want to talk to you.
20151017 03:40:56< shadowm> On the other hand, if I had to choose between playing HttT and LoW I'd certainly choose LoW.
20151017 03:41:05< fabi> no
20151017 03:41:08< fabi> no
20151017 03:41:09< fabi> and no
20151017 03:41:13< fabi> go away
20151017 03:41:23< shadowm> I'm sorry? I can't go away.
20151017 03:41:41< shadowm> On the other hand, if you don't want to talk to me you are perfectly free to leave.
20151017 03:41:47< shadowm> I'd just like to know why.
20151017 03:42:09< fabi> shadowm: do what you want, don't address me again
20151017 03:42:18-!- mode/#wesnoth-dev [+o shadowm] by ChanServ
20151017 03:42:18< celticminstrel> That's harsh.
20151017 03:42:20< fabi> I am finished with you
20151017 03:42:26-!- mode/#wesnoth-dev [+b *!*@wesnoth/developer/fendrin] by shadowm
20151017 03:42:26<@shadowm> So am I.
20151017 03:42:28-!- fabi [~quassel@wesnoth/developer/fendrin] has left #wesnoth-dev [requested by shadowm (fabi)]
20151017 03:42:39< celticminstrel> :|
20151017 03:42:49-!- mode/#wesnoth-dev [-o shadowm] by shadowm
20151017 03:45:46-!- Kwandulin [~Miranda@p5B00868E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151017 03:50:25< shadowm> For the sake of transparency:
20151017 03:50:27< shadowm> 06:45:21 <shadowm> I'd like to suggest shelving the scenario editor crap for 1.13.x but need to come up with nice words for it.
20151017 03:51:04< shadowm> What I didn't mention then and there, because all possible listeners *supposedly* knew the context, is that the reasoning for this is that it's unmaintained and nowhere near completion.
20151017 03:52:09< shadowm> There does not seem to be any interest on it either, seeing as how nobody has ever asked why there doesn't seem to be much in the way of progress in 1.13.x.
20151017 03:52:37< celticminstrel> I don't think I would ever use the scenario editor in its present state for two reasons: 1) It doesn't write an enclosing base tag (either [multiplayer] or [scenario]). 2) It writes everything it knows of even when it's pointless, such as generated unit IDs.
20151017 03:53:35< celticminstrel> The first point is probably fairly easily changed. The second point might not be.
20151017 03:53:44< celticminstrel> I think it's not a bad thing to keep it around though.
20151017 03:53:46< shadowm> I'm not interested in it personally because all my scenarios deal with events and macros and other actual code that the editor will never learn to deal with.
20151017 03:54:06< celticminstrel> Oh, also 3) It writes the map inline in the scenario definition.
20151017 03:54:49< shadowm> I don't feel a *need* to remove it for code complexity reasons (although I only had a very shallow look at the editor code I'll admit), but it seems odd that most of the editor's visible features deal with this unfinished feature and are accordingly disabled by default.
20151017 03:55:32-!- horrowind1 [~Icedove@2a02:810a:8b00:1c54:21b:fcff:fee3:c3ff] has quit [Quit: horrowind1]
20151017 03:55:39< celticminstrel> It's a bit weird that half the tools are labelled "not implemented", I guess, or are only enabled if you select "new scenario" instead of "new map".
20151017 03:56:55< celticminstrel> Actually I think point 2 is probably very difficult to solve. Might need a separate WML parser. Maybe not worth it.
20151017 03:57:05< shadowm> The scenario/map mode separation makes it plainly evident that the whole endeavor is only held together by duck tape and glue.
20151017 03:58:34< shadowm> (Of course, before *seriously* considering scraping it (and the point that fabi missed is that most of the stuff I say in there is not serious or official) I'd obviously scan the add-ons server for existing content that has obviously been made using the scenario editor functionality.)
20151017 04:00:13< shadowm> celticminstrel: One thing, though (2) is much better now than it was for the first few releases.
20151017 04:00:46-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20151017 04:01:28-!- Portaljacker [~Portaljac@modemcable081.139-178-173.mc.videotron.ca] has quit [Quit: Leaving]
20151017 04:01:29< shadowm> For example, this is the scenario I spent about an hour crafting in the editor for the 1.12 release announcement screenshot: http://pastebin.com/NSDQ2KC6
20151017 04:02:31< celticminstrel> I think that looks comparable to what I got when I tried it, though...
20151017 04:02:36< shadowm> In 1.11.10 or so those [unit] blocks would've included the whole unit type-derived serialization, including things such as the movetype stats and unit description.
20151017 04:02:40< celticminstrel> Mind you, that was in 1.12.
20151017 04:02:44< celticminstrel> Ahh.
20151017 04:03:21< shadowm> So atm I think only the auto unit ids are an annoyance.
20151017 04:03:30< celticminstrel> Maybe auto names.
20151017 04:03:45< shadowm> Oh yes, auto names too.
20151017 04:03:49< celticminstrel> The other annoyance (for me) is the schedule.
20151017 04:03:56< shadowm> Didn't realize those were there since they aren't even marked as translatable.
20151017 04:04:26< shadowm> Which is par for the course, considering they are the name generator's output.
20151017 04:07:18< shadowm> The thing I'm genuinely concerned about is that people will break the scenario editor more than it already was in 1.12.x later, if they don't get into the habit of testing it.
20151017 04:07:27< shadowm> Think whiteboard.
20151017 04:07:42< shadowm> (Whiteboard as in the Planning Mode feature, not whiteboard as in an actual whiteboard.)
20151017 04:08:07< celticminstrel> That makes sense...
20151017 04:08:16< shadowm> And odds are we'll only find out mid-stable series, say, 1.14.x, since it's neglected that much.
20151017 04:09:09< shadowm> So it's either force people to test a thing that less than 5% of content creators use (probably), or at shelf it until we can actually commit to making it a first-class citizen of the codebase.
20151017 04:09:32< shadowm> (And by "shelf it", I don't necessarily mean "remove it entirely".)
20151017 04:10:01< celticminstrel> I see.
20151017 04:10:53< shadowm> I'm not even sure what I'd have to look for in the server. I forgot that it indeed doesn't store all unit attributes anymore.
20151017 04:11:31< shadowm> Maybe `extra_recruit=""`, since I doubt many people use that feature in practice, much less with an empty list.
20151017 04:12:03< celticminstrel> Server?
20151017 04:12:12< shadowm> Yes, add-ons server.
20151017 04:12:41< shadowm> 0:58:36 <shadowm> (Of course, before *seriously* considering scraping it [...] I'd obviously scan the add-ons server for existing content that has obviously been made using the scenario editor functionality.)
20151017 04:12:49< celticminstrel> Ohhh.
20151017 04:14:02< shadowm> addons-unpacked/1.12/MyModMapPack_byvie77/scenarios/battleofthesea_v5.cfg:              extra_recruit=""
20151017 04:14:19< celticminstrel> Hmm. The main differences I can see between editor-created scenarios and a typical normal scenario...
20151017 04:14:21< shadowm> Lots of matches from that add-on alone.
20151017 04:14:47< celticminstrel> 1. The ID and name end with ".cfg". In fact I think they would exactly match the filename normally, but maybe not if you later renamed the file.
20151017 04:14:52-!- Appleman1234 [~Appleman1@KD118156244128.au-net.ne.jp] has quit [Ping timeout: 272 seconds]
20151017 04:14:58< celticminstrel> 2. The map data is inline instead of in a separate file.
20151017 04:15:13< celticminstrel> 3. The schedule definitions are inline rather than inserted with macros.
20151017 04:15:18< celticminstrel> 4. turns=-1
20151017 04:15:40< celticminstrel> 5. And last but not least: there is no root tag ([scenario] or [multiplayer]).
20151017 04:16:23< celticminstrel> That add-on calls itself a map pack, so I wouldn't be too surprised if it has editor-created scenarios...
20151017 04:16:35< shadowm> It looks like the author did use the scenario editor but then had to hand-edit the output anyway.
20151017 04:17:30< shadowm> I figure that without the root tag there's very little you can do with these scenarios unless you drop them into the editor dir yourself anyway. :p
20151017 04:19:17< shadowm> I also got a few spurious matches from Trinity, Saving Elensefar, and Valley of the Ancients.
20151017 04:20:17< shadowm> So, in conclusion, only MyModMapPack_byvie77 (title "MyModMapPack") appears to have been made using the scenario editor's unit placing functionality, at least not without heavy hand-editing that'd make the empty extra_recruit="" attributes disappear.
20151017 04:34:27< tMynd> Why so many changes to The Human Alliance in 1.13??
20151017 04:36:16-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 04:39:02-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20151017 04:45:37< shadowm> What's the Human Alliance?
20151017 04:47:32< vultraz> Low S14 I think
20151017 05:08:15< tMynd> Right
20151017 05:27:28-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 05:27:30-!- Appleman1234 [~Appleman1@KD118156244128.au-net.ne.jp] has joined #wesnoth-dev
20151017 05:35:42-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20151017 05:36:46-!- mjs-de [~mjs-de@31.10.152.75] has joined #wesnoth-dev
20151017 05:42:11-!- irker494 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20151017 05:42:11< irker494> wesnoth: Ignacio R. Morelle wesnoth:1.12 744dd6cd39e8 / / (9 files in 3 dirs): editor: Add Recent Files menu with recently loaded/saved files http://git.io/vC569
20151017 05:42:14< irker494> wesnoth: Ignacio R. Morelle wesnoth:1.12 cb7b2173aad8 / data/advanced_preferences.cfg src/editor/editor_preferences.cpp: editor: Make Recent Files limit customizable and increase default to 10 http://git.io/vC56H
20151017 05:42:17< irker494> wesnoth: Ignacio R. Morelle wesnoth:1.12 80dedf7cbcfb / src/hotkey/command_executor.cpp: hotkeys: Use a matching arrow icon style for submenus http://git.io/vC56Q
20151017 05:42:20< irker494> wesnoth: Ignacio R. Morelle wesnoth:1.12 f136c87210ea / / (11 files in 5 dirs): Merge branch 'feature/editor-mru-1.12' into 1.12 http://git.io/vC567
20151017 05:42:23< irker494> wesnoth: Ignacio R. Morelle wesnoth:1.12 7ce73bd30205 / changelog: Update changelog http://git.io/vC565
20151017 05:45:44-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 05:49:18-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20151017 05:58:26 * vultraz wonders what other GUI2 dialogs he could now deploy
20151017 05:59:52-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 06:03:52-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20151017 06:10:03-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20151017 06:10:15< Aginor> hi fabi
20151017 06:10:23< Aginor> you pinged me the other day
20151017 06:12:51< Aginor> celticminstrel: we should fix/modify the osx builds so that all sources are inside src and that cmake can build and run the game too without me having to make local fixes
20151017 06:16:18-!- Shackra [~Jorge@186.177.2.148] has quit [Ping timeout: 260 seconds]
20151017 06:16:33-!- mjs-de [~mjs-de@31.10.152.75] has quit [Remote host closed the connection]
20151017 06:17:34< celticminstrel> Aginor: So basically... moving SDLmain.m or whatever?
20151017 06:19:36< Aginor> celticminstrel: yes, and figure out how to make cmake compile that on OSX
20151017 06:19:41< Aginor> and scons :)
20151017 06:25:47-!- mode/#wesnoth-dev [+o shadowm] by ChanServ
20151017 06:25:50-!- mode/#wesnoth-dev [-o shadowm] by shadowm
20151017 06:33:11< vultraz> Ok, I'll work on enabling the GUI2 Create Unit dialog next
20151017 07:04:06-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20151017 07:07:23-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20151017 07:07:23-!- wedge010 is now known as wedge009
20151017 07:10:19-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20151017 07:10:19-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20151017 07:11:20-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20151017 07:13:33< wedge009> Aginor: Have you seen bug #21887? Looks like an SDL2 bug, possibly fixed in 2.0.4 release?
20151017 07:22:19< Aginor> wedge009: I am pretty sure I've tested that, is it a windows only issue?
20151017 07:22:38< wedge009> Yes, it's Windows-specific. I confirm it's not an issue in Linux.
20151017 07:22:44< Aginor> ok
20151017 07:22:56< Aginor> that would explain why I haven't come across it
20151017 07:22:58< wedge009> So there's nothing we can do at our end, really, is there?
20151017 07:23:27< Aginor> nope :/
20151017 07:23:41< wedge009> That's fine, didn't want to waste time looking into something that's not our problem.
20151017 07:23:44< Aginor> it might still work after my rewrite, it depends on the internals
20151017 07:23:54< wedge009> I was using the sdl2 branch to test it.
20151017 07:24:10< Aginor> still an issue?
20151017 07:24:15< wedge009> Unfortunately, yes.
20151017 07:25:40< Aginor> ok, thanks
20151017 07:26:03< Aginor> I think the solution there is to simply firm up the version dependency to 2.0.4 if it's fixed there
20151017 07:28:53< shadowm> The fact that there are SDL 2 bugs that concern us is what motivates me to look into moving to C++11 anyway, since the distribution (mostly Linux) support argument ceases to be valid.
20151017 07:29:58< shadowm> Still, although I plan to look into it, I'd only do so after the SDL 2 transition so as to minimize future merge conflicts.
20151017 07:30:00< Aginor> shadowm: I don't follow, can you please explain?
20151017 07:30:16< Aginor> what's the greater context?
20151017 07:30:34< celticminstrel> I think the only support issue for C++11 would be MSVC.
20151017 07:30:53< celticminstrel> ...
20151017 07:30:57-!- celticminstrel is now known as celmin|sleep
20151017 07:31:26< Aginor> https://msdn.microsoft.com/en-us/library/hh567368.aspx
20151017 07:31:27< shadowm> Basically, the last time we discussed the possibility of moving to C++11 (which was back in 2013 or 2014 before C++14 was finished), the only real concern we had was that some of our potential target distributions still didn't have compilers that supported some of the most useful compiler and library features in C++11.
20151017 07:31:41< shadowm> For example, Debian stable (wheezy at the time, now jessie).
20151017 07:32:49< shadowm> (wheezy's default was GCC 4.7, jessie's is GCC 4.9. stretch, which is currently the testing distribution and slated for feature freeze on December 2016, will have either GCC 5.1 (current) or one of its successors as default.)
20151017 07:33:43< shadowm> But if we consider that for Wesnoth 1.14 we want to make SDL 2 mandatory, and there's evidence of upstream bugs that affect us, we can't aim any lower than distributions that already ship with the minimum SDL 2 version we need.
20151017 07:34:41< shadowm> So that means we can (theoretically) raise the compiler/C++ standard library requirements without inconveniencing anyone who isn't already inconvenienced by the increased SDL version requirements.
20151017 07:35:32< Aginor> indeed
20151017 07:35:45< shadowm> And that'd allow us to make C++11 or even C++14 mandatory.
20151017 07:36:35< shadowm> There's still a lot in C++11 and C++14 I don't personally know, but I'm mostly interested in the benefits that move semantics (performance/memory footprint) and "uniform" initialization syntax (code) could bring us.
20151017 07:36:38< Aginor> shadowm: I don't think c++14 is a good idea at this stage. SDL2.0.3 has isseues in VS2015 and that's the only version of Visual Studio that has any c++14 support
20151017 07:37:23< shadowm> (Also, compiler lambdas and range-for would make for far more readable code, which is exactly what we need right now.)
20151017 07:37:37< Aginor> shadowm: I don't see a strong win in that myself, I've been profiling wesnoth and the biggest performance hits are our time processing bitmaps
20151017 07:37:41< shadowm> (If used wisely.)
20151017 07:38:25< shadowm> Aginor: How about memory?
20151017 07:39:40< shadowm> It's not so much about memory usage (hopefully we don't keep redundant copies of data around for long), but rather about minimizing unnecessary copy operations.
20151017 07:39:51< Aginor> shadowm: I haven't looked at that much
20151017 07:40:57< Aginor> I've found a bug in the config parser
20151017 07:40:58< Aginor> http://pastebin.com/PgPMMC52
20151017 07:41:30< shadowm> Regarding MSVC++, I am not interested in supporting old versions unless any of our (*active*) developers really depends on them.
20151017 07:41:58< shadowm> And I don't mean depend as in "I'm too lazy to upgrade", I mean depend as in "my machine will explode/my ISP will terminate my connection if I download and install this".
20151017 07:42:25< Aginor> or "I need this version for my day job"?
20151017 07:42:40< shadowm> That falls into the latter category, yes.
20151017 07:43:36< shadowm> The reason I don't care about users in this regard is because Windows users do not compile Wesnoth from source. :p
20151017 07:43:50< shadowm> This is unlike 90% of the Linux and BSD crowd.
20151017 07:44:46< Aginor> I think most of the actual end users use whatever comes with their distributions
20151017 07:45:13< shadowm> Yeah, but their distributions have to compile Wesnoth with their default compiler.
20151017 07:45:48< shadowm> So for example, if Wesnoth 1.12 required GCC 5, it wouldn't be buildable on Debian stable atm, or shippable on the official backports repository.
20151017 07:46:35< Aginor> yes?
20151017 07:46:47< Aginor> but isn't that simply a matter of stable vs. development branches?
20151017 07:47:00< Aginor> only fix bugs in stable, change stuff in dev
20151017 07:47:01< shadowm> Because Debian stable shipped with GCC 4.9 as its default and it doesn't ship GCC 5.
20151017 07:47:27< shadowm> Well, yes, obviously I'm not proposing to change our reqs in the 1.12 branch. That'd be lunacy.
20151017 07:47:49< shadowm> That was just a didactic example.
20151017 07:47:55< Aginor> https://gcc.gnu.org/projects/cxx1y.html
20151017 07:48:39-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20151017 07:48:40< Aginor> I don't think gcc is quite ready to heavily rely on c++14 yet
20151017 07:49:14< shadowm> C++11 was mostly okay with GCC 4.9 though.
20151017 07:49:52< shadowm> Well, *fully* okay, actually: https://gcc.gnu.org/projects/cxx0x.html
20151017 07:50:33< Aginor> yes
20151017 07:51:01< Aginor> presumably the c libraries they ship will be sane too
20151017 07:51:02< shadowm> Not entirely sure about library features, which I haven't researched that much other than the fact that the GCC 5 version of libstdc++ broke the ABI (and compatibility with clang, boo) to honor some C++11 requirements about std::string.
20151017 07:51:49< shadowm> (Which is why I won't be able to build Wesnoth with clang on Linux for a good while, oops.)
20151017 07:52:34< shadowm> Anyway, as I said: early-planning phase, haven't moved to research phase, I don't plan on proposing it or forcing it onto anyone until we have sorted out SDL 2.
20151017 07:53:07< shadowm> What I do know is that we've been building Wesnoth with --std=c++11 for over a year and it seems to run tests fine.
20151017 07:53:59< shadowm> e.g. https://travis-ci.org/wesnoth/wesnoth/jobs/85801741
20151017 07:54:53< shadowm> -std=c++0x I mean.
20151017 07:55:10-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20151017 07:55:12< shadowm> Same effect as -std=c++11 IIRC, it's just kept for compatibility.
20151017 07:55:16< Aginor> yes, but that's running ubuntu, which is a bit more recent than debian stable I think
20151017 07:55:25< vultraz> But we haven't been using c++ features, have we?
20151017 07:55:27< shadowm> Yes, I know. :)
20151017 07:55:28< Aginor> not that I have been comparing :)
20151017 07:55:49< Aginor> vultraz: we're relying on some boost features that have been folded into the language instead
20151017 07:55:58< shadowm> But the point is that by the time we release Wesnoth 1.14 we'll have Debian stretch on the way, which will have GCC 5 as default as I said.
20151017 07:56:04< Aginor> so we can use std:: instead of boost:: for a few things
20151017 07:56:27< shadowm> (That's my hope, anyway. That we won't miss the December 2016 freeze.)
20151017 07:56:35< Aginor> indeed
20151017 07:56:36< vultraz> so, can we use nullptr?
20151017 07:56:42< wedge009> Partially related question: what's the minimum Windows version we currently support? Is it still Windows XP?
20151017 07:56:42< shadowm> No, not yet.
20151017 07:57:01< vultraz> wedge009: theoretically
20151017 07:57:05< shadowm> nullptr and nullptr_t are both C++11 features and we still aim for C++03.
20151017 07:57:06< Aginor> I think we should only support supported versions of windows.
20151017 07:57:15< vultraz> I agree
20151017 07:57:22< shadowm> wedge009: Windows XP.
20151017 07:57:27< Aginor> I do not want to encourage people at all to keep using versions that are not getting security updates
20151017 07:57:32< wedge009> That's the official line, then. Thanks.
20151017 07:57:37< vultraz> I'm totally fine with dropping XP support
20151017 07:57:58< shadowm> Wesnoth 1.13.1 and earlier theoretically run on Windows 2000, but I added some code that'll break that with 1.13.2.
20151017 07:58:17< vultraz> In fact, even if still still "works" on XP, I recommend we drop mention of it from the wiki
20151017 07:58:28< shadowm> I would not drop XP support unless a library we depend on does first.
20151017 07:58:45< shadowm> Mostly because we do not need to.
20151017 07:59:01< vultraz> So you would say keep it mentioned on the wiki?
20151017 07:59:15< shadowm> Anyway, Aginor, if I understand valgrind's dump correctly, the issue is on config::add_child()?
20151017 07:59:43< shadowm> vultraz: We don't even mention it in the wiki.
20151017 08:00:08< vultraz> EditingWesnoth mentions userdata paths for 2000 and XP
20151017 08:00:10< vultraz> "Windows 2000/XP: My Documents\My Games\Wesnoth<version>"
20151017 08:00:17< Aginor> shadowm: yes, but I can't see how that's going wrong to be honest
20151017 08:00:24< shadowm> vultraz: Okay, and that's correct.
20151017 08:00:45< shadowm> The contents of that page should not be construed as a declaration of intent of support anyway.
20151017 08:00:50< vultraz> Ok
20151017 08:01:17< wedge009> vultraz: I was looking at that as part of bug #21891, which seems to be more of a feature request than an actual bug.
20151017 08:01:24< shadowm> Furthermore, if people want to stick to an unsupported version because their favorite game does not require them to upgrade (as opposed to require that specific version), that's their problem, not ours.
20151017 08:02:07< shadowm> We're here to write a game, not become IT security evangelists. If you really want to motivate people to upgrade, go tell Google and Mozilla to drop XP support themselves instead. :p
20151017 08:02:09< Aginor> I can only devote another hour or so to this before I need to go and pack and go to bed. I'm going on a holiday for ~1 week
20151017 08:02:30< vultraz> oo, vacation 
20151017 08:02:39< vultraz> :D
20151017 08:02:50< shadowm> (The logic here being that video games are a luxury and web browsers a necessity.)
20151017 08:03:29< wedge009> Personally, I think it's fine to keep supporting XP, officially or unofficially, until and unless something comes up that requires *us* to use something more recent.
20151017 08:04:39< shadowm> Aginor: It doesn't look like this has changed recently, but still: does config.cpp:694 contain this for you too?  `v.push_back(new config());`
20151017 08:05:18< Aginor> yes
20151017 08:05:32< shadowm> ==4591==    by 0x13BC92C: sdl_blit(surface const&, SDL_Rect*, surface&, SDL_Rect*) (utils.hpp:113)
20151017 08:05:33< Aginor> that's the line valgrind complains about
20151017 08:05:44< shadowm> Well, I'm not sure how anything from a config object would make it to that point. :\
20151017 08:05:57< Aginor> I suspect it's text to be drawn
20151017 08:06:09< Aginor> or supposed to be
20151017 08:06:28< shadowm> Two surface references and a SDL_Rect.
20151017 08:06:45< wedge009> Is that the choose faction window?
20151017 08:06:51< Aginor> wedge009: yes
20151017 08:07:08< Aginor> I am trying to fix the bug before I leave
20151017 08:07:18< Aginor> although I'm not too optimistic
20151017 08:07:19< shadowm> The thing is their contents are all independent of any config object that might've had uninit memory before.
20151017 08:07:55< Aginor> shadowm: I'll instrument and see if any dodgy text points are being rendered to a surface
20151017 08:08:21< shadowm> Basically what I'm saying is that the "Uninitialised value was created by a heap allocation" trace seems spurious.
20151017 08:09:03< shadowm> Unless someone is storing a SDL_Surface* in a config object that was somehow badly constructed.
20151017 08:09:30< shadowm> The SDL_Rects, though...
20151017 08:10:12< Aginor> they look sensible when I've inspected them in the debugger
20151017 08:11:01< wedge009> Don't stress about it if you can't fix it. Enjoy your break and come back refreshed. (:
20151017 08:13:11< shadowm> I think it could be that SDL itself is using an uninitialized allocation of its own that somehow happens to match the address of one of our own allocations, but that'd imply that there's heap corruption going on. :\ Meaning you wouldn't get much farther than that before seeing everything go south.
20151017 08:13:44< shadowm> Or two incompatible allocators stomping over each other.
20151017 08:14:12< shadowm> That's a too far-fetched possibility, of course.
20151017 08:15:36< shadowm> Plus valgrind is supposed to magically catch that kind of stuff before it gets worse.
20151017 08:16:09< Aginor> I don't :)
20151017 08:16:38< Aginor> there's something going horribly wrong with that particular dialog though
20151017 08:17:13< shadowm> Which dialog is this again?
20151017 08:18:42< Aginor> choosing side when joining a network game
20151017 08:23:08< shadowm> -- Found SDL2: /usr/lib/x86_64-linux-gnu/libSDLmain.a;/usr/lib/x86_64-linux-gnu/libSDL2.so;-lpthread (found suitable version "2.0.2", minimum required is "2.0.0")
20151017 08:23:14< shadowm> Is the minimum version still correct?
20151017 08:23:44< shadowm> Also uh eh I forgot I need to point it to my custom build.
20151017 08:24:48< Aginor> shadowm: that's arguable
20151017 08:25:12< Aginor> I think wedge009 was advocating 2.0.4 when it's released
20151017 08:25:37< wedge009> shadowm: It happens when attempting to join a MP game across the network. It brings up the choose faction screen which promptly crashes on SDL_BlitSurface() most of the time and shows a corrupted display when it doesn't.
20151017 08:26:17< Aginor> wedge009: I think it's an SDL bug, but it's odd that it's only manifesting itself there
20151017 08:26:44< shadowm> I'd suspect memory corruption of some sort.
20151017 08:26:58< wedge009> Regarding SDL version, I was only pointing out that the SDL bug report linked from our bug #21887 implies ALT-key hot-keys will be fixed with SDL 2.0.4.
20151017 08:27:04< Aginor> yes, that's why I'm running valgrind :)
20151017 08:27:08< shadowm> I mean duh. That sounded less dumb in my head.
20151017 08:27:53< shadowm> What I mean is that odds are that it happens with SDL 1.2 too and it just somehow doesn't hurt anything important.
20151017 08:28:24< shadowm> Unless it's the library itself doing something wrong, which I wouldn't rule out.
20151017 08:29:54< shadowm> Still, it's a good sign that this kind of stuff is being caught before the branch is even merged. We have a rather disappointing track record for bugs like this.
20151017 08:30:56< Aginor> shadowm: wedge009 has been doing a lot of work testing and helping me, he's been invaluable to the sdl2 effort
20151017 08:31:19< shadowm> Good to hear that. :)
20151017 08:32:07< wedge009> Aww, thanks. I really only fixed a few of the basic stuff, Aginor does all the stuff that makes my head hurt. XD
20151017 08:32:10< shadowm> Welp, the SDL 2 branch crashes on me as soon as the window is created.
20151017 08:32:28< Aginor> shadowm: you're doing it wrong? :D
20151017 08:32:39< Aginor> get me a backtrace pelase
20151017 08:32:40< wedge009> As soon as the game starts?
20151017 08:32:59< shadowm> So I only get to see a flash of black on the screen.
20151017 08:33:03< Aginor> shadowm: are you force-loading any libraries?
20151017 08:33:07< shadowm> Aginor: http://pastebin.com/gTHiY9g6
20151017 08:33:12< Aginor> LD_PRELOAD
20151017 08:33:21< shadowm> No, not really. Is that important?
20151017 08:33:45< Aginor> I have had issues when I've preloaded SDL2 onto SDL1 builds and other fun things like that
20151017 08:33:53< Aginor> it causes crashes in silly places
20151017 08:34:15< shadowm> Oh, I wouldn't even suggest doing that. That's just asking for trouble (ABI and API differences!).
20151017 08:34:53< Aginor> yes. setting environment variables and forgetting about it causes weird bugs
20151017 08:35:11< Aginor> shadowm: I suspect your crash is that I'm investigating at the moment
20151017 08:35:43< shadowm> When I want to force library versions I just make sure to install them in different places and use LD_LIBRARY_PATH instead, although this is not the case here, because I pointed cmake to them instead.
20151017 08:36:06< wedge009> It's the same sdl_blit() call that was related to the window resize and choose faction crash. If there's another situation where it happens, we need to reproduce it.
20151017 08:36:36< shadowm> My crash is avoided with valgrind.
20151017 08:36:50< Aginor> shadowm: making it timing related :/
20151017 08:37:45< shadowm> Oh, I got a crash further down the loading stage now.
20151017 08:38:38< shadowm> So I guess that flash of black happened over the course of a minute with valgrind instead.
20151017 08:39:34< shadowm> Even though there is progress bar activity preceding the crash on valgrind... It gets to the final step, "Loading title screen".
20151017 08:39:36< Aginor> hmm
20151017 08:39:53< shadowm> That normally takes several seconds, so I'm not sure it's the same crash as the flash of black.
20151017 08:39:57< Aginor> so it crashes when blitting the logo in the dump you sent me
20151017 08:40:10< Aginor> I think your new one is different
20151017 08:40:27< wedge009> How to reproduce? (The bug, I mean.)
20151017 08:40:37< shadowm> The valgrind crash: http://pastebin.com/C30cKU8G
20151017 08:41:13< shadowm> I just started my build of the SDL 2 branch, linked and compiled against SDL 2.0.3, and started Wesnoth with my current settings (including a 1920x1025 window).
20151017 08:41:53< shadowm> An -O0 (CMAKE_BUILD_TYPE=Debug) build with no other custom settings.
20151017 08:41:54< Aginor> shadowm: you're seeing completely different bugs from me
20151017 08:42:22< shadowm> :(
20151017 08:42:51-!- irker494 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20151017 08:42:58< wedge009> You're on Debian, right?
20151017 08:43:07< wedge009> Bye irker.
20151017 08:43:26< shadowm> Yes, Debian stretch (testing).
20151017 08:43:31< Aginor> shadowm: will take the sensible approach of ignoring your bugs until I've fixed the MP dialog crash
20151017 08:43:45< shadowm> GCC 5 and a custom SDL 2.0.3 build.
20151017 08:44:20< shadowm> I mean it's my own build, not that it has custom settings (just `./configure --prefix=/home/shadowm/local/SDL2-2.0.3`).
20151017 08:44:40< shadowm> Aginor: Okay, sure, that makes sense.
20151017 08:46:02< wedge009> Hmm, I'm just using GCC 4.9 and SDL 2.0.2. Off Ubuntu repositories. I didn't even realise I was using 2.0.2 until I checked!
20151017 08:46:16< shadowm> I really just wanted to reproduce the dialog crash but then this got in the way.
20151017 08:46:20-!- Kwandulin [~Miranda@p5B00868E.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151017 08:47:47< Aginor> shadowm: yeah, it's a bit annoying
20151017 08:48:46-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 08:50:37< shadowm> Maybe I should build SDL without optimizations to check this.
20151017 08:51:17< shadowm> gdb seems unable to retrieve any information about the variables involved once the trace leaves Wesnoth land.
20151017 08:52:05< shadowm> Anyway, that's all from me for the moment.
20151017 08:52:15< Aginor> it might be a good idea, just make sure you still have SDL use its own loop unrolling stuff
20151017 08:57:13< zookeeper> it seems :help doesn't explain what the DS commands are. it explains D, N and A, but there's a lot of commands marked DS, and while the D stands for debug, S is not explained anywhere.
20151017 08:57:25-!- irker850 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20151017 08:57:25< irker850> wesnoth: Wedge009 wesnoth:1.12 5bd79efa8b61 / src/hotkey/hotkey_item.cpp: More corrections for hot-key detection in SDL1.2 http://git.io/vC5AR
20151017 08:57:26< shadowm> wedge009: Sorry it took me forever to review this.
20151017 09:00:06< wedge009> zookeeper: I had no idea what they meant either.
20151017 09:00:12< wedge009> shadowm: No worries.
20151017 09:00:35< shadowm> Everything works fine for me, we'll have to see if anyone notices issues on OS X (or Windows, but I think that was already covered?).
20151017 09:01:09< Aginor> shadowm: is the choose fraction dialog populated by data that comes from the network?
20151017 09:01:37< shadowm> Aginor: Yes, pretty sure.
20151017 09:02:08< shadowm> Or maybe not. Actually, let me check.
20151017 09:03:54< shadowm> Aginor: Yes, just tested.
20151017 09:04:26< shadowm> (By forcing two clients to have different definitions of the same area. The host client's definition overrules the joining clients'.)
20151017 09:06:06< shadowm> You might want to make sure NETWORK_USE_RAW_SOCKETS isn't defined at build time, by the way.
20151017 09:07:26< shadowm> I don't think it is (or that the option is even available with CMake), but just in case: it makes Wesnoth break policy and assume a lot of things about SDL_net's internals that may or may not differ between the SDL 1.2 and 2.0 versions of the library.
20151017 09:07:40< Aginor> I wonder if it's getting corrupt data over the network
20151017 09:08:30< shadowm> Hm, might want to avoid USE_POLL too.
20151017 09:09:12< shadowm> Actually you want to avoid every single thing that references the _TCPsocket type in src/network_worker.cpp and I fear some of those things are actually enabled by default.
20151017 09:09:44< shadowm>     src/network_worker.cpp:220:2: error: #error USE_POLL is defined
20151017 09:09:49< shadowm> Oh my god.
20151017 09:10:05< shadowm> Aginor: Just something to consider which I probably should've mentioned long in advance. -.-
20151017 09:11:15< Aginor> I'm out of time tonight, I'll have to quiz you about this when I get back
20151017 09:11:40< shadowm> Okay, have fun.
20151017 09:11:47< shadowm> With your vacation, I mean.
20151017 09:11:51< Aginor> thanks
20151017 09:11:59< Aginor> disabling those settings made no difference
20151017 09:12:13< shadowm> I doubt USE_POLL is disable-able.
20151017 09:12:45< shadowm> Or USE_SELECT. These look like compile-time-defined feature macros.
20151017 09:13:42< shadowm> My original assessment was that nothing of this was relevant for client code, but I'm starting to think I overlooked a load of things.
20151017 09:15:30< shadowm> loonycyborg: Any news about wesnothd-asio?
20151017 09:15:56< shadowm> asio_wesnothd I mean.
20151017 09:17:07< loonycyborg> shadowm: I'm busy with other stuff lately, just need to wrap it up so I could focus on it properly
20151017 09:17:19< loonycyborg> on asio_wesnothd that is
20151017 09:18:33< shadowm> On further inspection, unless the type sizes or struct alignment changed (!), our violation of protocol shouldn't be a cause for issues. The latest SDL_net version of the _TCPsocket type matches ours in signature.
20151017 09:19:12< shadowm> Well, the struct members' type sizes on our side obviously have to match SDL_net's because they are public types.
20151017 09:19:59< shadowm> But yeah, that is at thing we do and that nobody has ever properly documented.
20151017 09:21:00< shadowm> Even though it's a recipe for horror tale-type disasters.
20151017 09:22:19< shadowm> Not entirely sure how we'd even go about documenting it. "Hey, we snoop into opaque types and this might break horribly in a future version of SDL_net".
20151017 09:32:25-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 240 seconds]
20151017 10:12:18-!- Kwandulin [~Miranda@p5B00868E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151017 10:24:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20151017 10:29:37< zookeeper> master (or week old master, anyway) has an annoying thing where it selects a unit at scenario start, i think the unit which last spoke
20151017 10:39:33-!- horrowind1 [~Icedove@2a02:810a:8b00:1c54:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20151017 11:22:40-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151017 11:56:50< shadowm> vultraz: Since the GUI2 Load Game dialog became default when I wasn't even looking, some initial observations:
20151017 11:57:36< shadowm> 1) This is GUI2, so it should be really easy to make the save name label on the preview pane get line-wrapped ([label] wrap=yes, [scroll_label] does this by default) instead of ellipsized.
20151017 11:58:34-!- irker850 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20151017 11:59:03< shadowm> 2) The listbox headers are scrolled along with the list contents. If this dialog had more columns with non-trivial meaning, this would be an important usability regression. (And yes, I'm aware that the issue is intrinsic to GUI2 listbox widgets in general.)
20151017 11:59:38< shadowm> 3) The listbox headers look static, meaning there's no hover animation unlike other clickable widgets (toggle buttons, push buttons, etc.) and their own GUI1 counterpart.
20151017 12:00:30< shadowm> (Not sure if the widget used for those supports the hover state, otherwise we might need to write a new one or extend the existing one.)
20151017 12:00:45< shadowm> 4) What happened to the nice column arrangement we had for the checkboxes on the bottom?
20151017 12:00:45-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151017 12:01:02< shadowm> 5) The Delete button is sitting in a row of its own, wasting space.
20151017 12:01:30< vultraz> 3) they're toggle buttons
20151017 12:01:32< shadowm> 6) I think we also lost the ability to gray out checkbox options that do not apply to the current save.
20151017 12:01:54< shadowm> (Well, not the *ability* per se, just the code. Of course disabling a GUI2 toggle button is trivial.)
20151017 12:02:19< shadowm> vultraz: Okay then I think I can look into adding a proper hover state to them.
20151017 12:02:31< shadowm> i.e. should be just a matter of editing the WML.
20151017 12:02:42< vultraz> Right
20151017 12:02:56< vultraz> 5) I will deal with this
20151017 12:03:27< vultraz> 1) I wonder if that label should be the name of the scenario the save is for
20151017 12:03:29< shadowm> 7) I removed the "Choose the game to load" label in the GUI1 version ages ago because it does nothing but waste space by stating the obvious (as if the dialog didn't have "PICK A SAVE" written all over it already).
20151017 12:03:35< vultraz> (and wrapped, of course)
20151017 12:03:42< shadowm> I didn't touch the GUI2 version out of laziness I believe.
20151017 12:03:53< vultraz> 7) will remove
20151017 12:04:15< shadowm> vultraz: If it's possible to retrieve the scenario name (not id) from the save, sure.
20151017 12:04:29< shadowm> Actually, we are in a development cycle, so even if that's not already possible we can just go and make it possible. :p
20151017 12:04:34< vultraz> right
20151017 12:05:57< shadowm> Deleting a save seems to sometimes (not sure why or how) select a completely different save next instead of one visually next to the deleted item.
20151017 12:07:24< shadowm> Deleted an AtS save from a bunch (starting with "A"), got a different save selected (starting with "2"), then I deleted another AtS save, got one starting with "D" (DW) selected instead.
20151017 12:07:42-!- julian [~quassel@x4d0454b5.dyn.telefonica.de] has joined #wesnoth-dev
20151017 12:07:55-!- julian is now known as Guest54809
20151017 12:08:05< shadowm> I had saves sorted by name then, resorted them by date and the selection-after-delete logic is still wrong.
20151017 12:16:32-!- irker049 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20151017 12:16:32< irker049> wesnoth: Charles Dang wesnoth:master d87a5fc0c515 / data/gui/default/window/unit_create.cfg: Unit Create: specified max height http://git.io/vCdzX
20151017 12:16:32< irker049> wesnoth: Charles Dang wesnoth:master 497a82d7cc8c / data/gui/default/window/unit_create.cfg: Unit Create: move gender selection below listbox http://git.io/vCdz1
20151017 12:16:33< irker049> wesnoth: Charles Dang wesnoth:master 83a3d3680bda / data/gui/default/window/game_load.cfg: Game Load: removed unnecessary instruction text http://git.io/vCdzM
20151017 12:16:35< irker049> wesnoth: Charles Dang wesnoth:master a8fdbeda1075 / data/gui/default/window/game_load.cfg: Game Load: move Delete button into same row as first checkbox http://git.io/vCdzD
20151017 12:26:16< vultraz> yeah this selection thing is weird...
20151017 12:30:30< vultraz> I tried adding an explicit 		list.select_row(index);
20151017 12:30:37< vultraz> but it doesn't work properly
20151017 12:32:18< vultraz> ....huh
20151017 12:32:25< vultraz> it works when sorted by date
20151017 12:32:29< vultraz> but not by name
20151017 12:35:09< vultraz> I'm gonna run out of saves to delete >_>
20151017 12:36:18-!- joet [~joet@host86-163-223-158.range86-163.btcentralplus.com] has joined #wesnoth-dev
20151017 12:39:55< vultraz> hm... no, doesn't work by date
20151017 12:39:57< vultraz> bleh
20151017 12:40:20-!- joet [~joet@host86-163-223-158.range86-163.btcentralplus.com] has quit [Remote host closed the connection]
20151017 12:54:08< tMynd> Is there a feature I can work on?  I made a 1.12 pr for a couple of bug reports this week
20151017 12:56:00< vultraz> have you checked out http://wiki.wesnoth.org/EasyCoding ?
20151017 12:56:03-!- Guest54809 [~quassel@x4d0454b5.dyn.telefonica.de] has quit [Remote host closed the connection]
20151017 12:58:30-!- julian__ [~quassel@x4d0454b5.dyn.telefonica.de] has joined #wesnoth-dev
20151017 13:02:08< tMynd> sweet
20151017 13:02:21< tMynd> Do I need to claim one somehow?
20151017 13:02:38< tMynd> So that other people know I'm working on it
20151017 13:03:30< tMynd> Nvm I need to read stuff
20151017 13:11:28-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20151017 13:24:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20151017 13:24:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20151017 13:54:20< irker049> wesnoth: Ignacio R. Morelle wesnoth:master cb9d8739551a / data/gui/default/widget/toggle_button_listbox_header.cfg: gui2/ttoggle_button: Add hover/selection bg color to listbox header variant http://git.io/vCdHo
20151017 13:54:56< shadowm> Unfortunately, this is a case where the cell margins mess with this kind of thing.
20151017 13:56:00-!- gfgtdf [~chatzilla@f054049080.adsl.alicedsl.de] has joined #wesnoth-dev
20151017 13:56:08< gfgtdf> vultraz: are your wokrin gon the gui2 loadgame dialog ?
20151017 13:56:23< vultraz> gfgtdf: yes
20151017 13:56:49< gfgtdf> vultraz: you have a plan on how you will fix the resize on selection issue ?
20151017 13:56:50-!- Appleman1234 [~Appleman1@KD118156244128.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20151017 13:57:09< vultraz> gfgtdf: yes. ttp://git.io/vCQOt
20151017 13:57:14< vultraz> http://git.io/vCQOt
20151017 13:58:05< gfgtdf> vultraz: i i didn't know it was that easy, will test it somtime.
20151017 13:58:32< gfgtdf> vultraz: are there other issues left ?
20151017 13:58:58< vultraz> gfgtdf: see logs, shadowm listed a  few about an hour ago
20151017 13:59:02< vultraz> I already dealt with 2
20151017 13:59:07< vultraz> he just did one
20151017 13:59:12< vultraz> s/2/two
20151017 14:00:02< vultraz> shadowm cell margins being why it can't extend to the edge of the header?
20151017 14:01:51< gfgtdf> vultraz: i actualyl reccomaned jus not to use [header] and instead add the header nanually with a [row] where teh listbox is in teh decond [row]
20151017 14:02:22< gfgtdf> vultraz: there is also a bugreport already about listbx headers
20151017 14:02:44< vultraz> gfgtdf: yes, the scrollbars
20151017 14:03:13< gfgtdf> vultraz: gna.org/bugs/?23752
20151017 14:03:39< gfgtdf> vultraz: so you sy teh soring potion is also borken ?
20151017 14:03:41< gfgtdf> say*
20151017 14:04:03< shadowm> vultraz: Yes,.
20151017 14:04:11< vultraz> gfgtdf: no it works, but if it's sorted and you delete a save the row that gets selected may not be the next one
20151017 14:04:41< gfgtdf> vultraz: so it just selects teh 'next one' in teh internal order (by date) ?
20151017 14:04:49< gfgtdf> the*
20151017 14:08:42< vultraz> seems so
20151017 14:08:43< vultraz> yes
20151017 14:09:58< vultraz> shadowm: for some damn reason I can't get the details label to wrap >_> it just cuts off 
20151017 14:10:02< vultraz> even with wrap=true
20151017 14:11:21< gfgtdf> vultraz: the code that must be uüpdates to fix teh order thing s mostlikley this one: https://github.com/wesnoth/wesnoth/blob/829d51792f1897f18c51141ea7d9fea0edcb6708/src/gui/widgets/generator.cpp#L81
20151017 14:14:07< shadowm> vultraz: I think you just explained why.
20151017 14:14:24< vultraz> >
20151017 14:14:26< vultraz> ?
20151017 14:14:30< shadowm> 10:57:14 <vultraz> http://git.io/vCQOt
20151017 14:14:41< irker049> wesnoth: gfgtdf wesnoth:gfgtdf-patch-1 cdf68f17e7a9 / src/gui/widgets/generator.cpp: fix selected item after deletion in a ordered list http://git.io/vCddm
20151017 14:15:18 * shadowm raises eyebrow.
20151017 14:15:42< gfgtdf> vultraz: here is  made a commit https://github.com/wesnoth/wesnoth/commit/cdf68f17e7a9c49d6eda5b966ea8187adca9bef7 to fix that issue (untested github webinterface commit)
20151017 14:16:15< vultraz> will test
20151017 14:17:37-!- gfgtdf [~chatzilla@f054049080.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 41.0.2/20151014143721]]
20151017 14:18:36< vultraz> that works
20151017 14:18:58< vultraz> shadowm: can you merge that 
20151017 14:19:17-!- Kwandulin [~Miranda@p5B00868E.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151017 14:19:35< shadowm> Yes but then gfgtdf won't appear as the committer. :p
20151017 14:19:37< celmin|sleep> zookeeper: I think that S might be explained in the code.
20151017 14:20:01< shadowm> So unless i's urgent to have it in master before he gets back...
20151017 14:20:11< vultraz> ok, just wait
20151017 14:20:32< vultraz> gfgtdf: it works please merge
20151017 14:24:02< shadowm> The problem with listbox headers is that it makes sense to scroll them with the listbox *horizontally*, not *vertically*.
20151017 14:24:13< vultraz> gfgtdf: btw it seems if you delete an item from the end of the list the list area will end up with an empty space where the row was 
20151017 14:24:31< vultraz> gfgtdf: is it possible to have the list go 'down' to fill that
20151017 14:24:47< vultraz> without waiting for the scroll event
20151017 14:24:51< shadowm> And I suspect that making a special case for horizontal vs. vertical scrolling would be a lot of work.
20151017 14:25:32< vultraz> shadowm: do we even support dialogs with listboxes with both horizontal and vertical listboxes?
20151017 14:25:45< shadowm> Yes, in GUI2.
20151017 14:25:50< vultraz> bleh
20151017 14:26:13< shadowm> Which is the whole point, really.
20151017 14:26:59< vultraz> I have an idea
20151017 14:28:25< shadowm> Yes?
20151017 14:28:52< vultraz> We can move the header row out of the scope of the vertical scrollbar but not the horiz one
20151017 14:29:58< shadowm> I did read gfgtdf's suggestion above of having two separate grids and no, that's nt a valid solution, that's a hack.
20151017 14:31:02< shadowm> I mean, it'd be valid if we were desperate for a cheap and immediate solution (deadline constraints and such), but we are not.
20151017 14:31:59< shadowm> Now, if a similar principle can be applied within the listbox widget implementation, that's a different thing and we should consider it.
20151017 14:32:15< vultraz> you mean you want the header and footer inside "_content_grid"?
20151017 14:32:25< shadowm> The grid has a name?
20151017 14:32:32< vultraz> yes
20151017 14:32:48< vultraz> look at listbox_default.cfg
20151017 14:32:51< shadowm> Oh huh.
20151017 14:33:04< shadowm> I assumed all this was done internally.
20151017 14:33:29< vultraz> no reason we can't have an external grid with the header, a content grid (with the content and v scrollbar), and the footer and h scrollbar
20151017 14:33:38< shadowm> They are already in the _content_grid, you mean outside surely.
20151017 14:35:25< shadowm> Yeah, that might be doable actually. As I said, I assumed it was all done internally in the C++ along with the magic scrollbar incantations, so I was wrong about that.
20151017 14:35:40< vultraz> 1 grid with 4 rows of 1 column each, except the second row with 2 columns
20151017 14:35:43< vultraz> I'm testing now
20151017 14:35:57< vultraz> few layout issues but I think I can get it working...
20151017 14:36:40< shadowm> We'll need to test four base cases: listbox without scrolling, listbox w/vertical scrolling, listbox w/horizontal scrolling, listbox w/vertical *and* horizontal scrolling.
20151017 14:37:04< shadowm> Then expand that to consider with and without header/footer.
20151017 14:37:13< shadowm> (And both.)
20151017 14:38:06< shadowm> We really could use a general GUI2 test dialog with every widget imaginable, really.
20151017 14:38:35-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 256 seconds]
20151017 14:38:53< vultraz> Well, someone would need to figure out what the matrix widget is
20151017 14:43:55< vultraz> dammit this isn't working
20151017 14:53:38-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151017 14:54:11-!- Appleman1234 [~Appleman1@KD111239014084.au-net.ne.jp] has joined #wesnoth-dev
20151017 15:01:00-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20151017 15:01:39-!- Kwandulin [~Miranda@p5B008454.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151017 15:20:12< vultraz> .... well this is weird
20151017 15:21:25< vultraz> ok, got it
20151017 15:22:01-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 15:23:06-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Read error: Connection reset by peer]
20151017 15:27:28-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 272 seconds]
20151017 15:28:17-!- gfgtdf [~chatzilla@x55b17686.dyn.telefonica.de] has joined #wesnoth-dev
20151017 15:28:19< gfgtdf> 20151017 14:24:13< vultraz> gfgtdf: btw it seems if you delete an item from the end of the list the list area will end up with an empty space where the row was 
20151017 15:28:39< gfgtdf> vultraz: is this new with my commit or was this also teh case before. Also is this alo te case with unsotred listboxes ?
20151017 15:28:47< vultraz> gfgtdf: happened before
20151017 15:29:07< vultraz> gfgtdf: yes it happens with unsorted
20151017 15:29:18< gfgtdf> vultraz: i'll merge my commit then
20151017 15:29:35< vultraz> gfgtdf: it probably just needs an update size action or something
20151017 15:30:17-!- julian__ [~quassel@x4d0454b5.dyn.telefonica.de] has quit [Remote host closed the connection]
20151017 15:32:23< irker049> wesnoth: gfgtdf wesnoth:master cdf68f17e7a9 / src/gui/widgets/generator.cpp: fix selected item after deletion in a ordered list http://git.io/vCddm
20151017 15:32:25< irker049> wesnoth: gfgtdf wesnoth:master df3c4df5e846 / src/gui/widgets/generator.cpp: Merge pull request #531 from wesnoth/gfgtdf-patch-1 http://git.io/vCFtP
20151017 15:34:12-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151017 15:37:39-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20151017 15:39:13-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 256 seconds]
20151017 15:49:07-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151017 15:53:02< irker049> wesnoth: Charles Dang wesnoth:master 88faaac46e26 / data/gui/default/widget/listbox_default.cfg: Experimental fix for GUI2 listbox headers outside vertical scroll area http://git.io/vCFOd
20151017 15:53:04< vultraz> gfgtdf: ^
20151017 15:54:38< vultraz> hm... something occurred to me...
20151017 15:55:56< vultraz> er...
20151017 15:55:57< vultraz> dammit
20151017 15:59:42< vultraz> yeah, fuck that doesn't work like I expected
20151017 16:00:47< vultraz> concept sound, but the C++ still screws with it
20151017 16:00:49< vultraz> FML
20151017 16:05:57-!- Shackra [~Jorge@186.177.2.148] has joined #wesnoth-dev
20151017 16:10:11< vultraz> gfgtdf: yeah my solution doesn't work :(
20151017 16:13:04< gfgtdf> vultraz: becasue of horizonal scrollbars or is there another problem?
20151017 16:13:12< vultraz> horizontal scrollbars
20151017 16:13:18< vultraz> they break bc of my commit
20151017 16:13:43-!- Aginor [~andreas@unaffiliated/aginor] has quit [Remote host closed the connection]
20151017 16:14:04< vultraz> it turns our scrollbars are linked to grids
20151017 16:14:25-!- travis-ci [~travis-ci@ec2-54-90-90-58.compute-1.amazonaws.com] has joined #wesnoth-dev
20151017 16:14:26< travis-ci> wesnoth/wesnoth#7652 (gfgtdf-patch-1 - cdf68f1 : gfgtdf): The build has errored.
20151017 16:14:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/85906124
20151017 16:14:26-!- travis-ci [~travis-ci@ec2-54-90-90-58.compute-1.amazonaws.com] has left #wesnoth-dev []
20151017 16:15:22< vultraz> gfgtdf: my idea was to remove the header from the scope of the vertical scrollbar but not the horiz one
20151017 16:15:35< vultraz> but that ended up not working because BOTH scrollbars affect a single grid
20151017 16:15:36< vultraz> :(
20151017 16:15:49< vultraz> if I creat e a sub-grid I get an assert
20151017 16:16:02< gfgtdf> vultraz: yes it currently rather complicated: the lisbox class inherits from the scrollbar class
20151017 16:17:16< vultraz> gfgtdf: if we could create a parent class for the scrollbars that gets passed a grid id from two subclasses (one each for horiz and vert scrollbars) I think it could work
20151017 16:17:19< celmin|sleep> ...that doesn't make any sense whatsoever.
20151017 16:17:33< celmin|sleep> The scrollbar is a component of the listbox, not a parent.
20151017 16:18:03< vultraz> celmin|sleep: the scrollbar is actually a grid with three rows
20151017 16:18:11< vultraz> celmin|sleep: the second row has the scrollbar widget
20151017 16:18:19< vultraz> so it's not a componant of the listbox
20151017 16:18:33< vultraz> it's used WITh the listbox to affect a grid of a hardcoded id
20151017 16:18:44< vultraz> in this case, "_content_grid
20151017 16:18:45< vultraz> "
20151017 16:18:55< celmin|sleep> Oh right. Still, it shouldn't be a parent of the listbox either.
20151017 16:19:53< vultraz> so...maybe we should pass seperate grids?
20151017 16:19:55< vultraz> separate 
20151017 16:20:22< vultraz> except...
20151017 16:20:38< vultraz> then maybe the vert scrollbar will scroll along with the horiz one
20151017 16:21:12< vultraz> ok... so
20151017 16:21:26< vultraz> I guess we need a grid with the header and list
20151017 16:21:34< vultraz> and the vert scrollbar outside that grid
20151017 16:22:05< vultraz> and the list has to be in another grid
20151017 16:22:13< vultraz> so grid 2 is scrolled by scrollbar V
20151017 16:22:20< vultraz> er, scrollbar H
20151017 16:22:25< vultraz> and scrollbar V does grid 1
20151017 16:23:43-!- gfgtdf [~chatzilla@x55b17686.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 41.0.2/20151014143721]]
20151017 16:25:09< vultraz> why the hell are the scrollbars so complicated :|
20151017 16:27:31< vultraz>  * Base class for creating containers with one or two scrollbar(s).
20151017 16:27:33< vultraz>  *
20151017 16:27:34< vultraz>  * For now users can't instanciate this class directly and needs to use small
20151017 16:27:36< vultraz>  * wrapper classes. Maybe in the future users can use the class directly.
20151017 16:41:45-!- Kwandulin [~Miranda@p5B008454.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151017 16:44:27-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151017 16:54:18-!- julian [~quassel@x4d0454b5.dyn.telefonica.de] has joined #wesnoth-dev
20151017 16:54:32-!- julian is now known as Guest77418
20151017 17:01:57-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 256 seconds]
20151017 17:16:36-!- mjs-de [~mjs-de@f049075159.adsl.alicedsl.de] has joined #wesnoth-dev
20151017 17:22:15< vultraz> I really don't know how to go about this
20151017 17:24:11< vultraz> scrollbar_container.cpp:740 has the hardcoded grid value
20151017 17:39:08-!- Nobun [~nobun@5.170.81.152] has joined #wesnoth-dev
20151017 17:51:03-!- travis-ci [~travis-ci@ec2-54-221-48-155.compute-1.amazonaws.com] has joined #wesnoth-dev
20151017 17:51:04< travis-ci> wesnoth/wesnoth#7655 (master - 88faaac : Charles Dang): The build was broken.
20151017 17:51:05< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/85917684
20151017 17:51:05-!- travis-ci [~travis-ci@ec2-54-221-48-155.compute-1.amazonaws.com] has left #wesnoth-dev []
20151017 17:55:34< vultraz> grrrrrr
20151017 17:55:39< vultraz> 20151018 04:53:47 error gui/layout: tgrid [] place: Failed to place a grid, we have 353,571 space but we need 982,123 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'savegame_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid'...
20151017 17:55:41< vultraz> ...in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'game_load'.
20151017 17:59:54-!- gfgtdf [~chatzilla@x55b17686.dyn.telefonica.de] has joined #wesnoth-dev
20151017 18:00:22< gfgtdf> vultrazy i made the error message a little more precise becasue that asertion seemed to fail rather often
20151017 18:01:53< vultraz> ah
20151017 18:02:27< gfgtdf> vultraz: 'N4gui25tgridE' shudol be read as 'gui::tgrid'
20151017 18:03:32< vultraz> ok so I guess basically the dialog cannot calculate size if the header/footer are outside the scroll grid :|
20151017 18:03:37< vultraz> for horiz listboxes
20151017 18:03:38< vultraz> er
20151017 18:03:41< vultraz> horiz scrollbars
20151017 18:04:16< gfgtdf> vultraz: well this is an assertion failure and an assertion failue always means an error in teh c++ code.
20151017 18:04:44< vultraz> it happens just with my last commit
20151017 18:04:47< vultraz> no C++ changes
20151017 18:05:52< gfgtdf> vultraz: yes i know, still its the c++ code that's wrong becasue ti cannot handle that wml code. But i dont think fuixing this is easy
20151017 18:07:10< celmin|sleep> So you used typeid.
20151017 18:07:26< celmin|sleep> I recognize the Itanium(?) ABI format.
20151017 18:08:33< vultraz> I'll try to do more tomorrow
20151017 18:08:42< celmin|sleep> Would be nice if you could just strip it down to the main portion (eg twindow), but it'd need a separate MSVC case... I guess it doesn't matter that much anyway.
20151017 18:10:23< celmin|sleep> What's the actual assertion?
20151017 18:11:02< gfgtdf> celmin|sleep: https://github.com/wesnoth/wesnoth/commit/cd0b12387b4df61178afc1e4ed0a2bc8280f10db
20151017 18:11:50< celmin|sleep> Hmmm.
20151017 18:12:42< celmin|sleep> Why is it a problem for best_size to be greater than size? Could it not simply be clipped in that event?
20151017 18:13:18< celmin|sleep> Or am I misunderstanding something?
20151017 18:13:22-!- celmin|sleep is now known as celticminstrel
20151017 18:15:22-!- Nobun [~nobun@5.170.81.152] has quit [Quit: Salve a tutti]
20151017 18:15:38< gfgtdf> celticminstrel: i dont know how that work exactly
20151017 18:16:05< gfgtdf> celticminstrel: i just added the error message before that assert(fals)
20151017 18:16:18< celticminstrel> Yeah, I realize.
20151017 18:17:07< celticminstrel> But it seems like it would be worth trying to use size.x instead of best_size.x when the latter is larger (and the same with y).
20151017 18:18:05< gfgtdf> celticminstrel: but iir the game call (request_)reduce_width/height before place it calles and i think that thats teh reason why it assumes thats it fits.
20151017 18:18:13< gfgtdf> calls
20151017 19:04:06-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20151017 19:07:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20151017 19:07:30-!- wedge010 is now known as wedge009
20151017 19:14:07-!- horrowind1 [~Icedove@2a02:810a:8b00:1c54:21b:fcff:fee3:c3ff] has quit [Remote host closed the connection]
20151017 19:21:58-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20151017 19:22:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20151017 19:30:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20151017 19:37:39-!- midzer [~quassel@p4FFCE1F9.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151017 19:37:42-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151017 19:48:54-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 268 seconds]
20151017 21:10:54-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151017 21:27:14-!- framling [~user@104.200.154.63] has joined #wesnoth-dev
20151017 21:41:14-!- neverEnough [~nEnough@host73-2-dynamic.117-80-r.retail.telecomitalia.it] has joined #wesnoth-dev
20151017 21:58:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds]
20151017 22:05:48< neverEnough> ok my pull request should be correct now (tab completion thingy)
20151017 22:07:18-!- mjs-de [~mjs-de@f049075159.adsl.alicedsl.de] has quit [Remote host closed the connection]
20151017 22:11:06-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151017 22:20:37-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit []
20151017 22:24:02-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20151017 22:35:59-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20151017 22:40:59-!- ancestral_ [~ancestral@209.181.254.220] has joined #wesnoth-dev
20151017 22:41:37-!- ancestral [~ancestral@63.92.240.233] has quit [Ping timeout: 250 seconds]
20151017 22:41:37-!- ancestral_ is now known as ancestral
20151017 22:46:01< shadowm> neverEnough: "Updated credits and changelogs" is a much better commit subject than "Updated <list of files>", for future reference (there's no need to fix it right now, though).
20151017 22:46:26< shadowm> The reason being that the list of files can be easily retrieved by a tool from the commit diff itself.
20151017 22:48:00< neverEnough> ok
20151017 22:48:35< neverEnough> i know i gotta learn conventions, good to know
20151017 22:49:29< neverEnough> i just noticed an old feature request asked for such a tab upgrade, it mentioned also friend list
20151017 22:49:40< neverEnough> which i didn't consider
20151017 22:49:51< neverEnough> may i work next to add also FL to tabbing?
20151017 22:50:42< neverEnough> (though i won't work on it for a few days, other projects running)
20151017 22:50:47< shadowm> neverEnough: Sure, that's one of the EasyCoding tasks in fact.
20151017 22:51:24< neverEnough> ok thx
20151017 22:52:21< neverEnough> i got already interest on a bigger feature request, but atm i avoid starting tasks which i'm not sure to be able to get done
20151017 22:53:02< irker049> wesnoth: neverEnough wesnoth:master 6280229562c3 / src/ (display_chat_manager.cpp display_chat_manager.hpp play_controller.cpp): Tab-completion added for in-game whispers. http://git.io/vCbrY
20151017 22:53:04< irker049> wesnoth: neverEnough wesnoth:master 58c78e2c5eaf / changelog data/core/about.cfg players_changelog: updated data/core/about.cfg; /changelog; /players_changelog http://git.io/vCbrO
20151017 22:53:06< irker049> wesnoth: Ignacio R. Morelle wesnoth:master 4346856ed28b / / (6 files in 3 dirs): Merge pull request #529 from niegenug/master http://git.io/vCbr3
20151017 22:53:33< shadowm> neverEnough: Thanks for yours first contribution! :)
20151017 22:54:51< neverEnough> yay! :0D
20151017 22:54:54< neverEnough> :-D
20151017 22:55:56< neverEnough> a github question: will my fork stay automatically up to date with wesnoth?
20151017 22:56:11< neverEnough> right now i read: This branch is 16 commits behind wesnoth:master. 
20151017 22:57:38< celticminstrel> No.
20151017 22:58:49< neverEnough> hm.. can't find a "sync" button in github :D
20151017 22:58:58< shadowm> One thing you did which isn't a very good idea was to push your commits to the master branch of your fork, instead of a dedicated feature branch.
20151017 22:59:00< neverEnough> maybe i had to locally clone the git directly from wesnoth?
20151017 22:59:23< neverEnough> ooh
20151017 22:59:43< neverEnough> a new branch for just a dozen lines of code?
20151017 22:59:49< shadowm> Using dedicated feature branches would allow you to manage multiple PRs more easily in the future.
20151017 22:59:50< celticminstrel> That's what git pull is for.
20151017 23:00:20< celticminstrel> And yeah, making a separate branch can be a good idea.
20151017 23:01:17-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20151017 23:01:46< neverEnough> celticminstrel, i type "git pull" on my local git to stay up to date with niegenug/wesnoth. But what about github fork? (i mean relation between niegenug/wesnoth <> wesnoth/wesnoth
20151017 23:02:01< shadowm> (I'll let celticminstrel explain the rest, because I'm not very good at explaining basic Git in general.)
20151017 23:02:13< celticminstrel> git pull <URL> master
20151017 23:02:36< celticminstrel> You can also add a nice symbolic name so you can do something like git pull main master
20151017 23:02:59< celticminstrel> I think you can do it with git remote add somehow.
20151017 23:03:24< celticminstrel> (You could also replace master with any other branch, if you wanted to.)
20151017 23:04:03< neverEnough> this will sync local git with wesnoth/wesnoth. What about niegenug/wesnoth?
20151017 23:05:15< celticminstrel> That's just git pull, right?
20151017 23:05:19< celticminstrel> With no arguments.
20151017 23:05:22-!- Guest77418 [~quassel@x4d0454b5.dyn.telefonica.de] has quit [Ping timeout: 272 seconds]
20151017 23:05:23< celticminstrel> Unless you changed something.
20151017 23:05:32< neverEnough> u are right
20151017 23:06:25< neverEnough> but git pull URL shold update the local with wesnoth, leaving niegenug older.. or i'm misunderstanding?
20151017 23:06:43< celticminstrel> Oh, yeah, once you've pulled you then push.
20151017 23:06:50< celticminstrel> git push
20151017 23:06:53< celticminstrel> No arguments.
20151017 23:06:59< celticminstrel> That'll update your fork.
20151017 23:07:05< celticminstrel> (Unless you change settings, of course.)
20151017 23:07:07< neverEnough> oh then local is supposed to be the bridge between wensoth and niegenug
20151017 23:07:15< celticminstrel> You can think of it that way.
20151017 23:07:26< celticminstrel> (I actually never bother updating master on my fork.)
20151017 23:07:31< neverEnough> pretty tricky :/ 
20151017 23:07:34< celticminstrel> (But I pull from main frequently.)
20151017 23:07:42< neverEnough> anyway ok, i'll try it that way
20151017 23:07:58-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20151017 23:08:02< celticminstrel> ...well, actually my master is currently a PR, so I couldn't update it even if I wanted to.
20151017 23:08:29< neverEnough> you are kinda in a frozen state?
20151017 23:08:49< celticminstrel> Because I used it for a PR, I can't update it with the lasted from wesnoth/wesnoth.
20151017 23:09:35< neverEnough> oh that's why i'm supposed to write code in branches?
20151017 23:09:44< celticminstrel> More or less. :)
20151017 23:09:49< celticminstrel> You don't have to.
20151017 23:10:00< celticminstrel> But it's more convenient if you end up working on more than one thing.
20151017 23:10:18< celticminstrel> Since a PR is always updated when you push to its source branch.
20151017 23:11:04< neverEnough> i'm not so much active, and my commit will be always small. Anyway thanks for explain
20151017 23:13:10< neverEnough> n8 guys
20151017 23:13:17-!- neverEnough [~nEnough@host73-2-dynamic.117-80-r.retail.telecomitalia.it] has quit [Quit: Sto andando via]
20151017 23:15:20< shadowm> vultraz: What's the status of PR #509?
20151017 23:51:01-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
--- Log closed Sun Oct 18 00:00:40 2015