--- Log opened Sun Jan 31 00:00:33 2016
20160131 00:02:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160131 00:02:33< neverEnough> sic transit gloria mundi *sigh*
20160131 00:03:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160131 00:05:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160131 00:06:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160131 00:10:09-!- Appleman1234 [~Appleman1@KD119104003111.au-net.ne.jp] has quit [Read error: Connection reset by peer]
20160131 00:12:34< gfgtdf> if i have 2 [item]s with the same images on the same hex but for different teamnames is there a way to remove only teh item for teamname 1 ?
20160131 00:14:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160131 00:24:21< zookeeper> gfgtdf, apparently not
20160131 00:25:04< zookeeper> ...unless you encoded the difference with dummy IPF's
20160131 00:25:27< zookeeper> or at least i assume it compares the whole path, not just the filename.
20160131 00:26:21< gfgtdf> zookeeper: y i did that in an other addon. It worked but i thougth there migth be an easier solution
20160131 00:26:48< gfgtdf> zookeeper: i think i'll add a id=<id> key to [item] that has no effect but can be used to delete the item
20160131 00:27:12< zookeeper> yeah that sounds ok
20160131 00:27:24< Ravana_> not even effect that prevents others with same id?
20160131 00:27:54< zookeeper> ...what? rephrase needed
20160131 00:28:00< Ravana_> like event ids
20160131 00:28:07< zookeeper> oh, i see
20160131 00:29:07< zookeeper> i dunno. it'd be more consistent with other uses of id's elsewhere, but it also sounds like something that'd be more likely to just get in your way?
20160131 00:30:30< gfgtdf> Ravana_: hmm i could doo that too, at least on lua level it shouldnt be to hard to implement, the other option ois that i call it 'name' or seomthing which doesnt make people assume that is is uniquie
20160131 00:31:04< Ravana_> I believe that there is no need to add unique constraint, just some other key than id might be better
20160131 00:31:50< Ravana_> name is good, that is already used for objects filtering
20160131 00:32:32< Ravana_> (oh right, we discussed it already, it isn't)
20160131 00:33:17< Ravana_> though same way, custom key should work
20160131 00:33:25< gfgtdf> it isnt good ypu mean?
20160131 00:34:03< Ravana_> for objects at least I learned that any random key can be added and used for filtering https://wiki.wesnoth.org/DirectActionsWML#.5Bobject.5D
20160131 00:34:46< gfgtdf> Ravana_: how do you filter object? ar there any tags teh accpet a standartObjectFiler or seomthing ?
20160131 00:35:07< Ravana_> iterating over them I guess
20160131 00:35:25< gfgtdf> Ravana_: you mean as wml tables ?
20160131 00:36:07< Ravana_> like https://github.com/ProditorMagnus/Ageless-for-1-11/blob/master/data/IE_data/abilities/rune_macros.cfg
20160131 00:36:35< gfgtdf> Ravana_: hmm ok but i don'T see how that related to [item]s
20160131 00:37:00< Ravana_> I believe there is way to get list of all objects
20160131 00:37:05< Ravana_> I believe there is way to get list of all items
20160131 00:37:16< Ravana_> noticed it in lua reference I think
20160131 00:37:52< gfgtdf> Ravana_: hmm so?
20160131 00:37:52< Ravana_> making whatever you get there read/write shoud work for changing items
20160131 00:39:14< gfgtdf> Ravana_: well there is [store_item]s but that won't let you modify those items
20160131 00:39:28< Ravana_> or making wml [store_items] have corresponding [unstore_item]
20160131 00:40:32< gfgtdf> Ravana_: that coudl also wokr but its rather ineffectove sicne it reclaculates all items
20160131 00:41:07< Ravana_> how so? it would unstore single item, just like unstore_unit
20160131 00:43:45< gfgtdf> Ravana_: hmm that would be just the same as [item] (execpt that it takes a variablename instead of direct values) and wouldnt solve the problem,
20160131 00:44:53< Ravana_> from [store_items] documentation I read that it has all keys that the originally used [item]
20160131 00:45:14< Ravana_> so using any random key should show up in result of store_items
20160131 00:45:20< gfgtdf> Ravana_: yes
20160131 00:45:35< gfgtdf> Ravana_: but you still cvannot use those keys to remove an item
20160131 00:47:44< Ravana_> I think I understand... might be better to just add new key like you originally suggested indeed
20160131 00:48:48< gfgtdf> Ravana_: actually i just looked at the code and it seems like [store_items] will not retuirns all keys that were originally put in  [item] becaue teh content is copied here: https://github.com/wesnoth/wesnoth/blob/master/data/lua/wml/items.lua#L14
20160131 00:50:15< Ravana_> indeed, won't work this way
20160131 00:50:30< Ravana_> unlike units there can't be find_vacant=no anyways
20160131 00:55:32-!- _trewe [~trewe@bl20-16-246.dsl.telepac.pt] has joined #wesnoth-dev
20160131 00:58:48-!- trewe [~trewe@bl20-23-201.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
20160131 01:00:24< vultraz> [07:05:17]	gfgtdf	vultraz: hmm why doesn id_folded here: https://github.com/wesnoth/wesnoth/commit/0d424e9d5dae9f3ed330108800dc2f263bf4ff53#diff-255ebc5ec0800339c02358939074318bR220 return the 'new state' ? thought you set the state a few lined ablow in toggle_->set_value
20160131 01:00:52< vultraz> gfgtdf: hm you're right... it's weird because in signal_handler_left_button_click I had to use the case backwards
20160131 01:00:58< vultraz> must have messed up
20160131 01:03:19< vultraz> shadowm: draft looks good, but I would say "Due to the sheer number of disruptive changes and a lack of sufficient manpower to help manage the spam"
20160131 01:03:47< vultraz> shadowm: also thanks for the formatter.hpp tip, that's exactly what I neded
20160131 01:11:56< vultraz> celticminstrel: hm.. still can't get the precision stuff to work :/
20160131 01:13:00< celticminstrel> Oh dear.
20160131 01:14:41< vultraz> for example, the function is returning "1.000000"
20160131 01:15:00< vultraz> and what's saved to preferences is just a "1"
20160131 01:15:21< vultraz> so it takes that 1 and adds....6 decimals places 
20160131 01:17:52-!- prkc [~prkc@54001BD3.dsl.pool.telekom.hu] has quit [Ping timeout: 250 seconds]
20160131 01:18:48< celticminstrel> If you say so...
20160131 01:19:24< vultraz> gfgtdf: weird... if I change those lines to if(is_folded()) in fold() and !is_folded() in unfold()then then nodes don't open :( maybe I can't use these functions in signal_handler_left_button_click
20160131 01:19:33< vultraz> celticminstrel: I do
20160131 01:19:46< vultraz> at least
20160131 01:19:59< vultraz> that's what I observe in console
20160131 01:21:19< gfgtdf> vultraz: i'd add private finction fold_impl(), unfold_impl() that doesnt so these checks so that they are then used by fold()/unfold() and by signal_handler_left_button_click
20160131 01:21:35-!- prkc [~prkc@54001BD3.dsl.pool.telekom.hu] has joined #wesnoth-dev
20160131 01:21:36< vultraz> gfgtdf: good idea
20160131 01:21:42< gfgtdf> vultraz: so that fold()/unfold() only do the is_folded check and call thoe functions
20160131 01:22:26< vultraz> celticminstrel: it seems to work if I make every number two decimal places and add setprecision(2)
20160131 01:22:47< celticminstrel> setprecision is <iomanip>, right?
20160131 01:23:03< vultraz> yes
20160131 01:23:11< celticminstrel> Putting the extra zeroes on the end of the integers is a bit ugly in my opinion.
20160131 01:23:17< vultraz> Very true
20160131 01:23:21< vultraz> I agree 100%
20160131 01:23:23< celticminstrel> But I suppose it's more important that it works.
20160131 01:23:31< vultraz> (100.00% :P )
20160131 01:23:34< celticminstrel> (I include 1.00 in that, BTW.)
20160131 01:24:59< vultraz> I suppose I could strip trailing 0's 
20160131 01:25:01< vultraz> how would you do that?
20160131 01:25:23< celticminstrel> Very carefully.
20160131 01:25:36< vultraz> Oh deer 
20160131 01:25:42< celticminstrel> ^a
20160131 01:26:02< celticminstrel> If you just strip 0's you'll be left with "1."
20160131 01:26:04< vultraz> (I say deer deliberately :P )
20160131 01:26:21< vultraz> hm... good point
20160131 01:27:19< irker624> wesnoth: gfgtdf wesnoth:master a885c2bdf12d / src/ (scripting/game_lua_kernel.cpp scripting/push_check.hpp unit.hpp): add alignment getter/setter for lua units https://github.com/wesnoth/wesnoth/commit/a885c2bdf12d94c436663ee696fcd34ccbb9b5f1
20160131 01:27:21< irker624> wesnoth: gfgtdf wesnoth:master 08236f8953b0 / / (6 files in 4 dirs): added name= attribute to [item] https://github.com/wesnoth/wesnoth/commit/08236f8953b0ef02ea34871b6a02ba0690e30e3e
20160131 01:27:27< gfgtdf> zookeeper, Ravana_ ^
20160131 01:29:14-!- _trewe [~trewe@bl20-16-246.dsl.telepac.pt] has quit [Quit: quit]
20160131 01:29:30< vultraz> celticminstrel: how's this? http://pastebin.com/Fc1vyFb3
20160131 01:29:55< vultraz> er, *removed setprecision*
20160131 01:33:02< celticminstrel> vultraz: If I read that right, you'll get 0.2, 0.5, 0.7, 1.0, 1.2, 1.5, 1.7, 2.0, ... except maybe 1.0 and 2.0 would be just 1 and 2.
20160131 01:33:21< celticminstrel> Analyze what you're doing there.
20160131 01:33:23< vultraz> uh, why?
20160131 01:33:27< vultraz> it's 0.75
20160131 01:33:58< vultraz> I just tested it and it seems to work
20160131 01:34:17< celticminstrel> find_last_not_of('0') gives you the index of the last character that's not 0, so that'll successfully remove any trailing zeroes.
20160131 01:34:24< celticminstrel> Oh, wait.
20160131 01:34:29< celticminstrel> I see why it could work.
20160131 01:34:46< celticminstrel> For "0.75", find_last_not_of('.') is npos.
20160131 01:35:06< celticminstrel> Or no, it's the index of the last character. The 5.
20160131 01:35:27< celticminstrel> So adding 1 is effectively npos. (It's not really, but any out-of-bounds value behaves the same as npos.)
20160131 01:35:55< vultraz> is there a better way to do it?
20160131 01:36:26< celticminstrel> Probably, but I can't think of anything right now.
20160131 01:36:51< celticminstrel> BTW, what does str_cast do again? Is that casting to string or from string?
20160131 01:37:35< vultraz> str cast?
20160131 01:37:43< celticminstrel> utils::str_cast
20160131 01:38:43< vultraz> it's a lexical_cast wrapper
20160131 01:38:54< celticminstrel> Oh, is it?
20160131 01:39:04< celticminstrel> I thought it was rather a reimplementation of lexical_cast.
20160131 01:39:12< vultraz> template<typename From>
20160131 01:39:14< vultraz> std::string str_cast(From a)
20160131 01:39:16< vultraz> {
20160131 01:39:16< celticminstrel> Well, it doesn't matter though.
20160131 01:39:17< vultraz> 	return lexical_cast<std::string,From>(a);
20160131 01:39:18< vultraz> }
20160131 01:39:25< celticminstrel> You didn't need to paste it.
20160131 01:45:02< vultraz> at least this is working
20160131 01:46:44< irker624> wesnoth: gfgtdf wesnoth:master d15aa76e4428 / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/d15aa76e442897409238ca370cbd1e91c40fdcaf
20160131 01:49:49< vultraz> celticminstrel: btw, is t_string expensive, performance-wise?
20160131 01:50:03< celticminstrel> Probably.
20160131 01:50:11< celticminstrel> More so than std::string, too.
20160131 01:51:34< vultraz> oh?
20160131 01:52:27< celticminstrel> If I understand correctly, t_string is an array of snippets, each of which can be either literal text (ie std::string) or translateable text (a string with an associated textdomain).
20160131 01:53:19< vultraz> oh...
20160131 01:53:23< vultraz> well that is expensive 
20160131 01:53:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20160131 01:54:16< vultraz> wait a second...
20160131 01:54:17< vultraz> .....
20160131 01:54:29 * vultraz tries something
20160131 01:56:04< vultraz> celticminstrel: a lexical cast of the double value strips the trailing 0/. by default!
20160131 01:56:07< vultraz> :|
20160131 01:56:39< celticminstrel> I thought that was likely the case, but I also thought you'd already tested it.
20160131 01:56:45< vultraz> it didn't work before *because I had trailing 0's in the array*
20160131 01:56:50 * vultraz hits face on keyboard
20160131 01:56:51< celticminstrel> Right.
20160131 01:57:03< vultraz> STUPID VULTRAZ 
20160131 01:57:19< celticminstrel> Which is why I pointed at setprecision as an option if you wanted to keep those trailing 0's.
20160131 01:57:27< celticminstrel> (And fixed.)
20160131 01:58:24< vultraz> this is what happens when you code at 6 AM after being up all night
20160131 01:58:35< vultraz> (which is what i was doing earlier)
20160131 01:59:00< vultraz> IN FACT 
20160131 01:59:09< vultraz> the old prefs dialog didn't use trailing-0 speed values either
20160131 01:59:12-!- roglo [6c1cb208@gateway/web/freenode/ip.108.28.178.8] has joined #wesnoth-dev
20160131 01:59:14< vultraz> so this is consistent!
20160131 02:00:11< vultraz> celticminstrel: I feel now I wasted your time :P
20160131 02:00:15< vultraz> apologies 
20160131 02:02:52< vultraz> at least the code works cleanly now
20160131 02:06:34-!- roglo [6c1cb208@gateway/web/freenode/ip.108.28.178.8] has quit [Quit: Page closed]
20160131 02:23:59-!- gfgtdf_ [~chatzilla@f050181135.adsl.alicedsl.de] has joined #wesnoth-dev
20160131 02:26:02-!- gfgtdf [~chatzilla@f050178198.adsl.alicedsl.de] has quit [Ping timeout: 256 seconds]
20160131 02:26:10-!- gfgtdf_ is now known as gfgtdf
20160131 02:26:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160131 02:26:13-!- prkc [~prkc@54001BD3.dsl.pool.telekom.hu] has quit [Remote host closed the connection]
20160131 02:30:59-!- oem_ [~oem@2601:1c2:901:5227:178:5f3e:1dc:4aaa] has joined #wesnoth-dev
20160131 02:31:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160131 02:42:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160131 02:45:25-!- oem_ [~oem@2601:1c2:901:5227:178:5f3e:1dc:4aaa] has quit [Ping timeout: 260 seconds]
20160131 03:20:42-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 272 seconds]
20160131 03:22:09-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160131 03:32:08-!- neverEnough [~nEnough@host58-11-dynamic.16-79-r.retail.telecomitalia.it] has quit [Quit: asleep]
20160131 03:32:08-!- gfgtdf [~chatzilla@f050181135.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160131 03:56:00-!- oem_ [~oem@2601:1c2:901:5227:178:5f3e:1dc:4aaa] has joined #wesnoth-dev
20160131 05:26:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160131 05:31:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160131 05:33:20-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 265 seconds]
20160131 05:35:13-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160131 05:40:58-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 256 seconds]
20160131 05:42:56-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160131 05:57:00-!- oem_ [~oem@2601:1c2:901:5227:178:5f3e:1dc:4aaa] has quit [Ping timeout: 250 seconds]
20160131 06:02:44-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160131 06:06:02-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20160131 06:06:03-!- wedge010 is now known as wedge009
20160131 06:33:34-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160131 06:41:51< vultraz> shadowm: when can I merge 581?
20160131 06:46:28< shadowm> When it isn't so ridiculously huge and full of WIP crap that no-one needs to see.
20160131 06:47:08< vultraz> You mean I should merge commits?
20160131 06:47:16< vultraz> together*
20160131 06:47:29< shadowm> Look, you still haven't get rid of the comma columns.
20160131 06:47:39< shadowm> I feel like I'm talking to a wall again.
20160131 06:47:51< vultraz> Yes, I will
20160131 06:47:56< vultraz> I have a cleanup commit coming
20160131 06:49:05< shadowm> You know, when I deal with _my_ crap I make sure to clean up the commit history so no-one has to see me struggling to get some piece of API (or in your case, _syntax_!) right next time there's a need to walk through history to find the cause of a bug.
20160131 06:49:52< shadowm> If you are going to throw claims around that I'm hindering you you might as well prove that you don't need to be treated especially.
20160131 06:51:10< shadowm> That you can be trusted to write well-thought code without hand-holding.
20160131 06:52:04< shadowm> There should only be _two_ kinds of changes in this PR: refactoring of existing code, and migration of the old code to GUI2.
20160131 06:52:23< shadowm> Anything else only belongs in a private branch in your hard disk drive.
20160131 06:53:03< shadowm> Oh, and a third: commits that explicitly deal with bugs in preexisting code, or library code (e.g. GUI2).
20160131 06:53:41< vultraz> Should be in the PR?
20160131 06:54:24< shadowm> Unclear question, elaborate further.
20160131 06:54:57< vultraz> Should I have left the GUI2 commits that I merged to master yesterday in the PR or not
20160131 06:55:16< shadowm> No, if they went to master first that's okay too.
20160131 06:55:39< shadowm> That's what I usually do to make sure most of the breakage can be detected by other people before I finish up my branches.
20160131 06:57:19< vultraz> Alright
20160131 06:57:40< vultraz> I'll do a bunch of cleanup on the PR and get back to you
20160131 07:21:37-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: ancestral]
20160131 07:28:46-!- Kwandulin [~Miranda@p200300760F69242FF97DD3E06282DB8C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160131 07:53:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160131 07:58:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160131 08:01:23< vultraz> shadowm: what is the purpose of the execute() function?
20160131 08:03:10< shadowm> src/gui/dialogs/dialog.hpp:96 - src/gui/dialogs/dialog.hpp:119
20160131 08:05:13< vultraz> Ok, so I don't think we need this for the preferences dialog
20160131 08:06:43< shadowm> Why.
20160131 08:07:14< shadowm> (Also, exactly why didn't you just read the documentation like I said in the code itself.)
20160131 08:08:06< vultraz> My design has the dialog call all setters immediately in widget callbacks 
20160131 08:08:13< vultraz> There's nothing to return
20160131 08:08:39< shadowm> In that case what do you think you are supposed to do?
20160131 08:10:28< vultraz> I think I'm supposed to remove the execute function
20160131 08:10:53< shadowm> And?
20160131 08:11:05< vultraz> and....?
20160131 08:11:12< shadowm> And???
20160131 08:11:37< vultraz> And????
20160131 08:11:38-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160131 08:11:39-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160131 08:11:58< shadowm> And.
20160131 08:12:29 * shadowm sighs deeply.
20160131 08:12:46< vultraz> What do you want of me :|
20160131 08:13:12< shadowm> To read the documentation again in its entirety.
20160131 08:13:41< vultraz> does it need to be display() instead?
20160131 08:13:49< shadowm> Yes, finally.
20160131 08:52:32< vultraz> shadowm: what does this mean in a header as a function argument? "class tlistbox& selector" - that you don't have to include the class's header?
20160131 08:52:54< vultraz> and is it better to include a header or do that?
20160131 08:53:58< shadowm> Didn't someone explain forward declarations to you the other day or did I misread the log?
20160131 08:54:08< vultraz> not in function arguments
20160131 08:54:18< vultraz> is it the same?
20160131 08:54:29< shadowm> Pretty much yes.
20160131 08:54:53< shadowm> If you need to call a function like that, odds are you _will_ need to include the relevant header yourself.
20160131 08:55:59< shadowm> In fact I think you will always need to do it even if it's a pointer type (otherwise how would the compiler know about the pointer's size and alignment...).
20160131 08:56:46< shadowm> And this is why I really dislike forward declarations in public APIs.
20160131 08:58:17< vultraz> The case was present in your initial commit, so I just didn't change it
20160131 08:58:33< vultraz> since I didn't really know what it was
20160131 08:58:37< vultraz> now I do
20160131 08:58:40< shadowm> Well, don't change it then, I know what I'm doing.
20160131 08:58:59< shadowm> That's used by a private portion of the interface.
20160131 08:59:25< shadowm> You already included the file needed to call it because... otherwise your code wouldn't have compiled a million years ago when you started writing it.
20160131 08:59:45< shadowm> tl;dr keep it as a forward declaration.
20160131 09:00:11< shadowm> If you include any unnecessary headers from the header, in fact, everyone will be highly displeased.
20160131 09:00:13< vultraz> now there are two other functions requiring tlistbox arguments
20160131 09:00:26< vultraz> should I make them all forward declarations or just make sure they're under the first one
20160131 09:00:44< shadowm> Wow.
20160131 09:00:50< vultraz> or put it at the beginning of the file?
20160131 09:00:52< shadowm> Make them all forward declarations. What were you thinking?
20160131 09:00:55-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 240 seconds]
20160131 09:01:05< shadowm> preferences_dialog.hpp pulls a load of crap no-one wants to see.
20160131 09:01:34< shadowm> All those includes except for config.hpp, make_enum.hpp, gui/dialogs/dialog.hpp, they belong in the implementation portion.
20160131 09:01:42< shadowm> preferences_dialog.cpp is the implementation.
20160131 09:01:46< shadowm> preferences_dialog.hpp is the interface.
20160131 09:01:51< vultraz> I only included them for function arguments
20160131 09:01:54< shadowm> Interfaces ought to be clean and lightweight.
20160131 09:02:02< vultraz> Private function arguments
20160131 09:02:21< shadowm> No-one will call the private portion of the interface other than the implementation of it.
20160131 09:02:41< shadowm> Do everyone a favor and hide those header inclusions away where they belong.
20160131 09:03:17< shadowm> Consider them to be the bodily fluids of your code.
20160131 09:03:20< vultraz> yes, I want to get rid of them, but *do I need a forward declaration for each widget class included there instead*
20160131 09:03:25< shadowm> No-one wants to see _that_ in public.
20160131 09:03:26-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160131 09:04:05< shadowm> Let me ask you a question, what do you think will happen if there aren't any forward declarations for types that your code refers to before they are declared?
20160131 09:04:24< vultraz> compiler error 
20160131 09:04:30< shadowm> A pageful or more of compiler errors.
20160131 09:04:53< shadowm> Place the forward declarations in the correct namespace, don't do it inline like I did.
20160131 09:05:05< shadowm> I did it inline only because: 1) WIP code; 2) single-site usage.
20160131 09:06:40< vultraz> Does it also work if you forward-declare classes these inherit from?
20160131 09:06:53< shadowm> You don't need to do that.
20160131 09:07:53< shadowm> If the code that needs to see the forward declarations needs to see their type relationships then the forward declaration simply won't suffice no matter what you do, and you will get a compiler error.
20160131 09:08:10< shadowm> Additionally, forward declarations don't allow to declare relationships anyway.
20160131 09:11:16< vultraz> so uh.. .like this? http://pastebin.com/0rjPYf2p
20160131 09:11:39< shadowm> Yes, exactly.
20160131 09:11:57< vultraz> whew
20160131 09:13:09< vultraz> And this is good practice?
20160131 09:13:40< vultraz> That I should adhere to?
20160131 09:14:21< shadowm> Everything I said above explicitly states that what you were doing before with the extra headers is bad practice.
20160131 09:14:39< vultraz> Ok
20160131 09:14:46< shadowm> Very explicitly, I must say.
20160131 09:15:14< shadowm> The obvious implication is that this alternative you were just ordered to utilize is not bad practice.
20160131 09:16:28< shadowm> Because, think about it: what business do the preferences dialog's callers  have with the widgets it uses?
20160131 09:17:07< shadowm> Why would they want to have their namespace (in a loose sense of the word) polluted with crap they don't need to use?
20160131 09:17:24< shadowm> Not to mention that all header code has an impact on compile times.
20160131 09:17:37< shadowm> Because, like code in not-headers, it's code the compiler has to compile.
20160131 09:18:08< shadowm> The compiler doesn't have a crystal ball with which it can tell that it does not _need_ to compile the extra code.
20160131 09:21:09< shadowm> tl;dr (since I know you love these): dependencies used in private API = keep them out of the header, use forward declarations; used in public API = keep them in the header.
20160131 09:22:26< shadowm> In the future you'll want to consider going a step further and keeping the private API fully private, but that's really an unnecessary complication at this point and it'll only confuse you further.
20160131 09:23:03< shadowm> Plus your private members are very few and none of them are inline.
20160131 09:23:20-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160131 09:23:33< shadowm> Wait, I was looking at my commit instead of the full diff.
20160131 09:24:11< shadowm> Your private members are very many and.
20160131 09:24:28< shadowm> Why is gui2::tpreferences::advanced_preferences_sorter in the header even?
20160131 09:25:18< shadowm> That's the kind of crap I'd relegate to an anon namespace in the implementation file. No-one outside needs to know it exists.
20160131 09:25:29< shadowm> It's not even used by anything in the interface.
20160131 09:26:22< shadowm> Well, most of the other members can be excused by being semantically tied to the thing.
20160131 09:26:32< shadowm> Probably.
20160131 09:26:47< shadowm> And I assume they also access `this`.
20160131 09:27:13-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160131 09:27:46< shadowm> Yeah, gui2::tpreferences::advanced_preferences_sorter seems to be the only member that doesn't really need to be there.
20160131 09:28:21< shadowm> OTOH it hardly has any code in it other than a method with trivial code inside.
20160131 09:38:45-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160131 09:46:59-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160131 09:53:43-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160131 09:54:24-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 250 seconds]
20160131 09:58:34-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20160131 10:20:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160131 10:25:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160131 10:27:03-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160131 10:29:08-!- Kwandulin [~Miranda@p200300760F69242FF97DD3E06282DB8C.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160131 10:32:34< vultraz> shadowm: I wanted to simplify that but I don't know how
20160131 10:36:11-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 264 seconds]
20160131 10:37:09< vultraz> shadowm: also I don't use 'this'
20160131 10:37:19< vultraz> shadowm: well, only for the bindings
20160131 10:37:29< vultraz> becuase you need 'this' when binding a member functon
20160131 10:48:59-!- irker624 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160131 11:26:41-!- prkc [~prkc@54001BD3.dsl.pool.telekom.hu] has joined #wesnoth-dev
20160131 12:25:23-!- Netsplit *.net <-> *.split quits: Soliton, Jetrel
20160131 12:25:32-!- Netsplit *.net <-> *.split quits: iwaim, Rhonda, TheJJ
20160131 12:25:43-!- Netsplit *.net <-> *.split quits: higgins, aidanhs, avtobiff, zookeeper
20160131 12:26:19-!- Netsplit *.net <-> *.split quits: aeonchild, Elsi_, quentinp_, ypnos, legoktm, pydsigner, loonycyborg, prkc, esr, wedge009,  (+5 more, use /NETSPLIT to show all of them)
20160131 12:26:44-!- Netsplit *.net <-> *.split quits: {V}, Gambit, aeth, new_one, heirecka, Yaiyan, Jetrel_bot, nurupo, janebot, timotei_
20160131 12:26:55-!- Netsplit *.net <-> *.split quits: TC01, shadowm
20160131 12:27:19-!- Netsplit *.net <-> *.split quits: vincent_c, _laco, Ivanovic, oldlaptop, AI0867_, Lohengramm, vultraz, kidneb, Crendgrim, Greywhind,  (+1 more, use /NETSPLIT to show all of them)
20160131 12:28:53-!- Netsplit over, joins: prkc, zookeeper, janebot, elias, aeonchild, aeth, clavi, Elsi_, heirecka, Jetrel_bot (+19 more)
20160131 12:29:37-!- Netsplit over, joins: Soliton, Rhonda, Jetrel, TheJJ
20160131 12:29:52-!- Netsplit over, joins: midzer, oldlaptop, vincent_c
20160131 12:30:03-!- Netsplit over, joins: Ivanovic, _laco, kidneb, Lohengramm
20160131 12:30:08-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 250 seconds]
20160131 12:30:09-!- Netsplit over, joins: shadowm, TC01
20160131 12:30:42-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160131 12:32:37-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20160131 12:32:37-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160131 12:32:37-!- Crendgrim [~crend@wesnoth/forum-moderator/crendgrim] has joined #wesnoth-dev
20160131 12:32:37-!- Greywhind [~Greywhind@c-50-133-231-228.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160131 12:32:37-!- AI0867_ [~ai@wesnoth/developer/ai0867] has joined #wesnoth-dev
20160131 12:34:44-!- Kwandulin [~Miranda@p200300760F6924ECF97DD3E06282DB8C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160131 12:49:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160131 13:02:30-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160131 13:02:30-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160131 13:04:38-!- gfgtdf [~chatzilla@f050181135.adsl.alicedsl.de] has joined #wesnoth-dev
20160131 13:05:44< gfgtdf> i just noticed that team_name in [item] really refers to the team_name of a side (insetead of to the dies number), is there a way to show an [item] only to side 1 but not to side 2 if they have the same team_name?
20160131 13:09:52-!- Kwandulin [~Miranda@p200300760F6924ECF97DD3E06282DB8C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160131 13:11:29< vultraz> [filter] side=1?
20160131 13:15:10< gfgtdf> vultraz: where can i put that ?
20160131 13:15:54< vultraz> oh
20160131 13:15:56< vultraz> hm
20160131 13:16:19< vultraz> ohh
20160131 13:16:31< vultraz> item only has full SLF support in [event]
20160131 13:16:39< vultraz> gfgtdf: so [event] [item] side = 1
20160131 13:16:43< vultraz> i think
20160131 13:17:14< gfgtdf> vultraz: how can side= filter a location?
20160131 13:17:46< vultraz> oh
20160131 13:17:48< vultraz> hm
20160131 13:17:52< vultraz> yeah uh...
20160131 13:18:12< vultraz> [event] [item] [filter] side =1 would be the loc of all side 1 units
20160131 13:18:57< gfgtdf> vultraz: no, my situation is that i know the location, and only want the item to be visible for side 1.
20160131 13:19:09< vultraz> i think that's not possible
20160131 13:19:16< vultraz> unless you assign two team names to side 1
20160131 13:19:28< vultraz> so like side 1's team name is foo,bar and side 2 is foo
20160131 13:19:39< vultraz> then filter item to team name foo 
20160131 13:19:43< vultraz> er
20160131 13:19:44< vultraz> team name bar
20160131 13:20:27< gfgtdf> vultraz: hmm ok
20160131 13:28:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160131 13:28:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160131 13:39:58-!- irker544 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160131 13:39:58< irker544> wesnoth: Charles Dang wesnoth:master e72eef3c982a / src/gui/widgets/ (tree_view_node.cpp tree_view_node.hpp): ttree_view_node: split fold/unfold internals into private functions https://github.com/wesnoth/wesnoth/commit/e72eef3c982a6605fa6158189eb48930dbd7c8ec
20160131 13:40:01< vultraz> gfgtdf: ^
20160131 13:40:25< vultraz> gfgtdf: that doesn't fix the problem that selection events don't seem to fire if you click in a child widget border area tho
20160131 13:40:36< vultraz> (or on hidden widgets, but I think that's a separate bug)
20160131 13:41:18< gfgtdf> vultraz: but shouldnt you not change the is_folded chacks to the opposite?
20160131 13:41:37< vultraz> I had them opposite before 
20160131 13:43:05< gfgtdf> vultraz: no, now its if(is_folded()) { do stuff } befroie it was if(!is_folded()) { return: } ..do_stuff.. which is teh same as bafore
20160131 13:44:02< vultraz> oh right
20160131 13:44:04< vultraz> hm
20160131 13:44:13< gfgtdf> vultraz: do you know what teh current blockers for 1.13.3 are ?
20160131 13:44:45< vultraz> gfgtdf: weird window/drawing behavior that Aginor is working on
20160131 13:45:06< gfgtdf> vultraz: is there a bugreport for it, which explains how to reproduce ?
20160131 13:45:23< vultraz> some
20160131 13:45:39< vultraz> but it's not just one thing
20160131 13:46:32-!- trewe [~trewe@bl20-16-246.dsl.telepac.pt] has joined #wesnoth-dev
20160131 13:47:19< gfgtdf> iceiceice: you did implement https://gna.org/bugs/?16214 in 1.13.0 right?
20160131 14:04:18-!- Kwandulin [~Miranda@p200300760F6924ECF1827472FCC7087D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160131 14:08:09-!- mjs-de [~mjs-de@f049111101.adsl.alicedsl.de] has joined #wesnoth-dev
20160131 14:08:43< vultraz> gfgtdf: do you have an idea where i could look to make linked groups/scroll labels work in tree nodes?
20160131 14:09:34< gfgtdf> vultraz: lnked groupd do not wokr in tree nodes ?
20160131 14:09:48< vultraz> gfgtdf: no 
20160131 14:10:00< gfgtdf> vultraz: hmm what exactly does wrng ?
20160131 14:10:24< gfgtdf> goes*
20160131 14:11:03< vultraz> gfgtdf: seems like each node has its own size calculations. so even if a child widget has linked_group when you add a new node that widget won't be the same size as in other nodes
20160131 14:11:32< vultraz> also if you do something to change a node's dimensions (like swapping in an image widget of a certain height) the other nodes don't get their size updated
20160131 14:13:16< gfgtdf> vultraz: you do that in a preshow function ?
20160131 14:13:23< vultraz> ya
20160131 14:16:31< gfgtdf> hmm in the code i see no reason why linked_size shouldnt work in treeviewnodes :/
20160131 14:18:12< vultraz> ya... same for scroll labels
20160131 14:18:20< vultraz> i think there;s maybe a size update call missing somewhere
20160131 14:29:23< gfgtdf> vultraz: you know whther its possible to have custom alignmnets that get like +50% in light, -50% in dark or something?
20160131 14:29:47< vultraz> not from ucm i dont think
20160131 14:31:24< gfgtdf> hmm will try to use a custom [leadership] that onyl applies to the unit itself.
20160131 14:48:08-!- mjs-de [~mjs-de@f049111101.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160131 15:12:48-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160131 15:13:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20160131 15:18:54-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 272 seconds]
20160131 15:38:54< shadowm> vultraz: I didn't specifically mean _explicitly_ using the `this` keyword, just accessing the `this` pointer.
20160131 15:39:03< shadowm> But that answers the question anyway.
20160131 15:40:31< shadowm> (If you are accessing member variables, you _are_ dereferencing `this` whether you spell it out that way or not, otherwise your CPU would never be able to find the right object in memory.)
20160131 15:42:20-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20160131 15:56:34-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160131 16:00:25-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Disconnected by services]
20160131 16:00:28-!- VultCave is now known as vultraz
20160131 16:00:33-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160131 16:00:33-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160131 16:17:54 * zookeeper hadn't realized we had all of tropical forest, rainforest, palm forest, dense palm forest and savanna forest
20160131 16:28:51-!- Kwandulin [~Miranda@p200300760F6924ECF1827472FCC7087D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160131 16:31:41-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160131 16:40:54-!- irker544 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160131 16:41:54-!- oem_ [~oem@2601:1c2:901:5227:178:5f3e:1dc:4aaa] has joined #wesnoth-dev
20160131 16:53:33< gfgtdf> shadowm: has wesnoth 1.12.5 the purge cache option ?
20160131 17:03:14-!- gfgtdf [~chatzilla@f050181135.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160131 17:06:27-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160131 17:07:31-!- gfgtdf [~chatzilla@f050181135.adsl.alicedsl.de] has joined #wesnoth-dev
20160131 17:07:53< gfgtdf> does anyone else have problems with imgur? It always gived me error when uploading images
20160131 17:29:44-!- prkc [~prkc@54001BD3.dsl.pool.telekom.hu] has quit [Remote host closed the connection]
20160131 17:31:33-!- Kwandulin [~Miranda@p200300760F6924EC180CA0A9F40A26D8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160131 17:43:15< shadowm> gfgtdf: No, it's only in 1.13.x.
20160131 17:50:53-!- oem_ [~oem@2601:1c2:901:5227:178:5f3e:1dc:4aaa] has quit [Quit: Leaving]
20160131 18:01:19-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160131 18:02:45-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160131 18:06:15-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160131 18:06:16-!- wedge010 is now known as wedge009
20160131 18:19:18-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160131 18:25:33-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160131 18:27:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160131 18:27:06-!- wedge010 is now known as wedge009
20160131 18:28:31-!- lipkab [~the_new_l@apn-94-44-252-177.vodafone.hu] has joined #wesnoth-dev
20160131 19:11:20-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 272 seconds]
20160131 19:17:38-!- irker319 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160131 19:17:38< irker319> wesnoth: Ignacio R. Morelle website:master 8edb231fb9df / start/1.12/ (15 files in 2 dirs): Use same protocol for page resources https://github.com/wesnoth/website/commit/8edb231fb9dffca489be89fc0fad379654009a49
20160131 19:49:04-!- lipkab [~the_new_l@apn-94-44-252-177.vodafone.hu] has quit [Quit: Leaving]
20160131 19:52:58-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160131 19:53:05< Aginor> morning
20160131 19:55:34-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160131 20:17:58-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 250 seconds]
20160131 20:37:10-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 265 seconds]
20160131 20:39:03-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160131 21:05:05-!- mjs-de [~mjs-de@f049111101.adsl.alicedsl.de] has joined #wesnoth-dev
20160131 21:07:05< vultraz> morning 
20160131 21:09:13-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160131 21:09:15-!- ancestral [~ancestral@99.sub-70-197-206.myvzw.com] has joined #wesnoth-dev
20160131 21:09:30-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160131 21:10:43-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160131 21:10:43-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Disconnected by services]
20160131 21:10:43-!- celmin is now known as celticminstrel
20160131 21:31:16-!- ancestral [~ancestral@99.sub-70-197-206.myvzw.com] has quit [Read error: Connection reset by peer]
20160131 21:38:09-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160131 21:55:23-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds]
20160131 22:10:19< Aginor> hmmm
20160131 22:10:37< Aginor> assertion failures because of object delete orders :/
20160131 22:10:40 * Aginor does not like
20160131 22:11:27-!- Kwandulin [~Miranda@p200300760F6924EC180CA0A9F40A26D8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160131 22:25:09< Ravana_> Is it correct that filter "evaluation order of top level conditions (those not embedded in and/or/not tags) is undocumented, which means your code shouldn’t rely on it"? source https://wiki.wesnoth.org/FilterWML/Examples_-_How_to_use_Filter#Ordering_and_writing
20160131 22:26:27< zookeeper> "doesn't matter" is quite different from "undocumented"
20160131 22:27:43-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160131 22:30:07< Ravana_> I tracked my most recent crash down to http://pastebin.com/wLJwEpkR , and if it happened that formula= evaluation happened before attack filtering, then it would explain crash
20160131 22:31:43-!- StandYourGround [~Adium@2602:30a:c02f:d050:2c0f:4a48:2541:82d9] has joined #wesnoth-dev
20160131 22:35:07< gfgtdf> Ravana_:you shoudlnt rely on order in this case, if you need to use [and].
20160131 22:35:37< Ravana_> ok, thats what I needed to know
20160131 22:35:40< StandYourGround> installing wesnoth —HEAD via homebrew has been failing for a few months now
20160131 22:36:04< vultraz>  talk to ancestral 
20160131 22:36:07< gfgtdf> Ravana_: specially in wml its really the same whether you write aa="a" bb="b" or  bb="b" aa="a" wince the parsere will order it aphabetically anyway
20160131 22:36:15< gfgtdf> since*
20160131 22:36:27< gfgtdf> when it writes them i mean
20160131 22:37:34< Ravana_> I noticed that part in pbl files
20160131 22:43:28-!- StandYourGround [~Adium@2602:30a:c02f:d050:2c0f:4a48:2541:82d9] has quit [Quit: Leaving.]
20160131 22:43:46< irker319> wesnoth: gfgtdf wesnoth:master e5a184bc0a3b / src/gui/dialogs/campaign_difficulty.cpp: fix campaign difficulty dialog in case description is empty. https://github.com/wesnoth/wesnoth/commit/e5a184bc0a3b6601bf2e619f53c651fc0bbaf8ef
20160131 22:58:07-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160131 23:07:45-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160131 23:15:43-!- Appleman1234 [~Appleman1@KD119104018151.au-net.ne.jp] has joined #wesnoth-dev
20160131 23:20:31-!- trewe [~trewe@bl20-16-246.dsl.telepac.pt] has quit [Quit: quit]
20160131 23:23:30-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 250 seconds]
20160131 23:26:32-!- Aginor [~andreas@unaffiliated/aginor] has quit [Ping timeout: 250 seconds]
20160131 23:27:10-!- gfgtdf [~chatzilla@f050181135.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20160131 23:27:13-!- Aginor [~andreas@apollo.alternating.net] has joined #wesnoth-dev
20160131 23:27:13-!- Aginor [~andreas@apollo.alternating.net] has quit [Changing host]
20160131 23:27:13-!- Aginor [~andreas@unaffiliated/aginor] has joined #wesnoth-dev
20160131 23:27:24-!- knotwork_ [~markm@unaffiliated/knotwork] has quit [Ping timeout: 250 seconds]
20160131 23:40:45-!- knotwork_ [~markm@99.192.89.107] has joined #wesnoth-dev
20160131 23:40:45-!- knotwork_ [~markm@99.192.89.107] has quit [Changing host]
20160131 23:40:45-!- knotwork_ [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20160131 23:50:07-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
--- Log closed Mon Feb 01 00:00:35 2016