--- Log opened Tue Jan 26 00:00:42 2016
20160126 00:06:57-!- travis-ci [~travis-ci@ec2-54-146-168-72.compute-1.amazonaws.com] has joined #wesnoth-dev
20160126 00:06:58< travis-ci> wesnoth/wesnoth#8306 (asio_wesnothd - 610c844 : loonycyborg): The build has errored.
20160126 00:06:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/104773395
20160126 00:06:58-!- travis-ci [~travis-ci@ec2-54-146-168-72.compute-1.amazonaws.com] has left #wesnoth-dev []
20160126 00:07:48-!- Appleman1234 [~Appleman1@KD119104014008.au-net.ne.jp] has joined #wesnoth-dev
20160126 00:14:07-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 265 seconds]
20160126 00:18:51-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20160126 00:34:42< shadowm> loonycyborg: https://forums.wesnoth.org/viewtopic.php?p=593251#p593251 -- I believe those are much older than those we tried for 1.12.4?
20160126 00:39:44< gfgtdf> i notced that in 1.13.2 the green for thew unit resitance in the right side panel is now darker as in 1.12.5
20160126 00:40:00< gfgtdf> does anyone else laos have this problem?
20160126 00:43:14< gfgtdf> the green whena  unit has a very good resistance (like ghosts)
20160126 00:50:15< vultraz> gfgtdf: I haven't noticed 
20160126 00:51:01< gfgtdf> vultraz: could you please test (simply by creaing a ghost in debug mode in any scenario  and putting mose over its hp in rigth side panel)
20160126 00:52:59< vultraz> hmmm
20160126 00:53:09< vultraz> could be a difference but if there is it's extremely minor 
20160126 00:54:18< gfgtdf> vultraz: hmm so its still a light green on 1.13.2+dev for you ?
20160126 00:54:49< shadowm> You aren't using named Pango colors, right?
20160126 00:55:11< vultraz> I would call it a bright green not light green
20160126 00:55:18< shadowm> IIRC one of them had different values depending on the Pango version used.
20160126 00:55:29< gfgtdf> shadowm: hmm might bve that that code used pango colors
20160126 00:55:37< shadowm> Named colors.
20160126 00:55:39< gfgtdf> shadowm: and its true that i recently updated my pango verison
20160126 00:55:50< shadowm> As in 'green' instead of '#0f0' or '#00ff00', etc.
20160126 00:56:33< shadowm> (Yeah the question is for vultraz, really.)
20160126 00:56:50< vultraz> Uh
20160126 00:57:01< vultraz> Why are you asking me, I'm not looking at any code I'm writing 
20160126 00:57:09< vultraz> I'm looking at the in-game display
20160126 00:57:16< gfgtdf> shadowm: https://github.com/wesnoth/wesnoth/blob/master/src/reports.cpp#L437 it looks like it might be sng named pango colors, but i wouldnt say i am using them.
20160126 00:57:23< shadowm> Oh, the sidebar, I thought it was the attack dialog. Never mind then.
20160126 00:58:08< shadowm> Oh, yes, it is named colors.
20160126 00:58:27< shadowm> https://github.com/wesnoth/wesnoth/blob/master/src/unit_helper.cpp#L36
20160126 00:58:57< shadowm> The fix is to use RGB colors instead (or to acknowledge and embrace the fact that the output will vary depending on the Pango version used).
20160126 00:59:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20160126 01:00:16< shadowm> It does raise the question of which should be the authoritative definition of those colors to use instead of the names, and I don't have time to deal with that right now so I'm leaving it to you people.
20160126 01:00:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 01:02:27< gfgtdf> the dark green is hard to read only the black/brown background.
20160126 01:04:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20160126 01:06:14< gfgtdf> s/only/on
20160126 01:06:20< vultraz> Dammit, I don't think I can reuse this part of my code :(
20160126 01:06:48< vultraz> None of the advanced preferences have their own setter functions
20160126 01:06:57< vultraz> so you need to use set()
20160126 01:07:08< vultraz> but set needs the preference id
20160126 01:09:56< vultraz> gfgtdf: it's not possible to pass an incomplete function call as a pointer, is it? like if foo(string a, bool b) exists, and you pass foo(x) as a pointer and then later call foo(y) and it would get called as foo(x, y)
20160126 01:10:30< gfgtdf> vultraz: no that what boost bind and boost function can do
20160126 01:11:34< vultraz> oh?
20160126 01:13:01< gfgtdf> vultraz: no= its not possible, you need to use boost::function  function pointer
20160126 01:16:09< vultraz> oh ok
20160126 01:16:14< vultraz> what would the syntax look like?
20160126 01:17:55< gfgtdf> vultraz: ? I thought you used boost bind already quite foten
20160126 01:18:10< vultraz> Yes but you said boost::function
20160126 01:19:05< gfgtdf> boost::bind returns a boost::function
20160126 01:19:26< gfgtdf> vultraz: or at lest something that is usally converted into a boost function
20160126 01:23:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 01:23:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 01:25:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 01:26:38< vultraz> gfgtdf: I forgot, what does the _1/_2 etc mean again? I think celticminstrel said it was 'pass the next argument as the first argument to this function' or something?
20160126 01:27:07< celticminstrel> The numbers index the arguments passed to the bound function.
20160126 01:27:25< celticminstrel> Their position in the bind list specifies which argument they're passed as to the base function.
20160126 01:28:19< vultraz> so if I said bind(&foo, bar, _2), the _2 would be passed as the second argument? 
20160126 01:28:45< celticminstrel> Yes, but that would produce a function whose first argument is ignored.
20160126 01:28:55< celticminstrel> So you probably want _1 instead.
20160126 01:29:49< celticminstrel> (But maybe not. Sometimes there's reasons to have a function that ignores one or more of its arguments.)
20160126 01:30:51< vultraz> well in this case I'm trying to pass an incomplete function call as a boost::function pointer that will then be bound to ANOTHER function and called with an argument that will hopefully end up as the second argument to the first thing
20160126 01:32:16< vultraz> all because I decided to try to generalize these functions so I don't have to clutter up the code with duplicate functionality 
20160126 01:33:59< iceiceice> celticminstrel, i'm not sure if you are actually allowed to omit arguments,
20160126 01:34:07< celticminstrel> You are.
20160126 01:34:11< iceiceice> i remember once seeing some wierd error that can result
20160126 01:34:20< iceiceice> i never tried it myself though
20160126 01:34:24 * vultraz wonders what languages handle this kind of stuff better
20160126 01:35:11< celticminstrel> Okay, so the expression "fcn = bind(&foo, bar, _2)" is equivalent to the following function definition: "return_type fcn(arg1_type arg1, arg2_type arg2) {return foo(bar. arg2);}"
20160126 01:35:26< celticminstrel> That last . should be a , obviously.
20160126 01:36:38< iceiceice> celticminstrel, someone posted this as an example of a tiny program that generates a 44kb error message:
20160126 01:36:39< iceiceice> http://ideone.com/cUvlNb
20160126 01:36:44< celticminstrel> iceiceice: I suppose that could produce an issue with determining the type of the missing argument, maybe? But, I think the functors produced by bind() are internally set up to accept any type imaginable...
20160126 01:37:13< iceiceice> claim is that the error means "in which compiler tries to say: Please define placeholder for first argument if you define it for second. "
20160126 01:37:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160126 01:37:23< iceiceice> but i dont know if hes actually right about what it means
20160126 01:37:28< vultraz> for some reason this doesn't work 
20160126 01:37:33< vultraz> boost::bind(&preferences::set, option["field"].str(), _1)
20160126 01:37:43< iceiceice> vultraz, imo lua handles it pretty well
20160126 01:37:49< celticminstrel> boost::bind might be a little more lenient on this than the C++11 bind.
20160126 01:37:58< iceiceice> ah i see
20160126 01:38:10< celticminstrel> I'm not entire sure though. You might be right.
20160126 01:38:21< iceiceice> yeah i should read the docs some time ><
20160126 01:38:28< celticminstrel> ^+ly
20160126 01:39:37-!- prkc [~prkc@51B78693.dsl.pool.telekom.hu] has quit [Quit: Leaving]
20160126 01:41:59< vultraz> ohh
20160126 01:42:01< vultraz> hm
20160126 01:42:18< vultraz> I wonder if I should make set a templated function instead of 4 overloads 
20160126 01:42:44< vultraz> because it can't resolve the _1
20160126 01:43:00< vultraz> even though it's passed as this argument: boost::function<void(bool)> callback
20160126 01:43:09< iceiceice> oh
20160126 01:43:18< iceiceice> you might need to specify which overload you want
20160126 01:43:22< iceiceice> when you are making the function pointer
20160126 01:43:33< iceiceice> i can't remember exactly how you do that,
20160126 01:43:36< vultraz> but how do you do that :|
20160126 01:43:48< iceiceice> its like `&my_func(int, double) ` maybe?
20160126 01:43:54< iceiceice> i would have to look it up
20160126 01:44:44< iceiceice> taking a function pointer to an overloaded function is not trivial
20160126 01:45:11< iceiceice> the overload resolution process cannot be delayed until later or anything, it has to happen before the templates get to see it
20160126 01:45:32< vultraz> is this relevant? https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/mp_alerts_options.cpp#L76
20160126 01:45:43< vultraz> you wrote that 
20160126 01:46:02< iceiceice> hehe
20160126 01:46:06< iceiceice> i guess that is one way to do it
20160126 01:46:12< iceiceice> yeah i remember doing that now
20160126 01:46:22< iceiceice> vultraz, what that does is,
20160126 01:46:28< iceiceice> it declares a new function pointer variable named "set"
20160126 01:46:39< iceiceice> whose signature is "void(const std::string & , bool)"
20160126 01:46:54< iceiceice> and sets it to the value of the overload of preferences::set corresponding to that signature
20160126 01:47:49< vultraz> huh
20160126 01:48:11< iceiceice> if i wrote it again today i would do it like this probably
20160126 01:48:12< iceiceice> http://hastebin.com/ujomeqonef.cpp
20160126 01:49:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 01:51:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 01:51:21< vultraz> tbh that makes more sense when you look at it than the other one
20160126 01:52:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 01:53:58-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160126 01:54:23< vultraz> hm
20160126 01:54:30< vultraz> looks like find_widget don't like tgrid 
20160126 01:54:32< vultraz> weird
20160126 01:54:45< shadowm> Why?
20160126 01:54:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 01:55:01< vultraz> oh nevermind
20160126 01:55:22< vultraz> wait
20160126 01:55:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 01:55:48< vultraz> weird
20160126 01:56:17< vultraz> this works: tlabel& value_label = find_widget<tlabel>(main_grid, "value", false);
20160126 01:56:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 01:57:00< gfgtdf> vultraz: you coudl just look at the declaration of find_widgets to see what it accepts
20160126 01:57:10< shadowm>     tgrid& w32_options_grid = find_widget<tgrid>(&window, "win32_paths", false);
20160126 01:57:16< shadowm> It works just the same.
20160126 01:57:40< vultraz> OH I think I know what's wrong 
20160126 01:57:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 01:57:53< vultraz> main_grid is a pointer
20160126 01:58:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 01:58:15< shadowm> And...?
20160126 01:58:24< vultraz> 	ttoggle_button& widget =
20160126 01:58:25< vultraz> 		find_widget<ttoggle_button>(&window, widget_id, false);
20160126 01:58:38< vultraz> in this case, window is a templated argument
20160126 01:58:47< shadowm> &window is a pointer.
20160126 01:59:01< shadowm> No matter what the operand is, the address-of operator can only return a pointer.
20160126 01:59:21< vultraz> but main_grid is already a pointer
20160126 01:59:23< vultraz> so double pointer
20160126 01:59:34< shadowm> Why is window a pointer?
20160126 01:59:55< shadowm> Do you actually need it to be a pointer? Common newbie mistake is to use pointers where a reference would do just fine.
20160126 02:00:24< vultraz> main_grid is a pointer because I use it with dynamic_cast 
20160126 02:00:35< shadowm> (Rule of thumb: if it can't/isn't ever supposed to be be null, it doesn't need to be a pointer.)
20160126 02:00:55< gfgtdf> shadowm: i shoudl a class can define a custom adressof operator ?
20160126 02:00:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:00:59 * vultraz makes a pastebin
20160126 02:00:59< gfgtdf> i thought*
20160126 02:01:06< gfgtdf> not that i recooment doing that
20160126 02:01:39< shadowm> gfgtdf: IIRC it's one of the non-overridable operators along with . and ::.
20160126 02:02:03< shadowm> "The operators :: (scope resolution), . (member access), .* (member access through pointer to member), and ?: (ternary conditional) cannot be overloaded."
20160126 02:02:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 02:02:53-!- mjs-de [~mjs-de@f049107050.adsl.alicedsl.de] has joined #wesnoth-dev
20160126 02:02:55< shadowm> Waaait.
20160126 02:03:00< vultraz> shadowm: http://pastebin.com/HVrRewrv
20160126 02:03:25< shadowm> Oh my god, it seems you can actually override address-of.
20160126 02:03:40< shadowm> Why would you ever want to do that? That's just evil.
20160126 02:04:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:04:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 02:05:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:05:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 02:07:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:07:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 02:09:29< vultraz> Eh?
20160126 02:09:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:10:28< vultraz> I assume this is some trivial pointer/reference stuff that I should know
20160126 02:12:06< gfgtdf> vultraz: the erros message (from whihc you only provided teh first quater) says taght you tried to pass a gui2::tgrid** to find_widget
20160126 02:12:21< vultraz> yes
20160126 02:13:00< gfgtdf> but it doenst accept a tgrid**
20160126 02:13:53< vultraz> yes. so how should I pass main_grid to setup_single_toggle so it will not be a double pointer?
20160126 02:15:24-!- irker026 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160126 02:16:06< iceiceice> shadowm, i think there may be some reason,
20160126 02:16:12< iceiceice> but i agree its super evil
20160126 02:16:25< iceiceice> i would imagine they use it for like `boost::recursive_wrapper`
20160126 02:18:18< iceiceice> actually i'm surprised, i thought you could override member access
20160126 02:19:11< celticminstrel> vultraz: The problem is on line 22 of your paste, where it takes the address of window.
20160126 02:19:41< iceiceice> yeah i'm wrong
20160126 02:19:49< celticminstrel> So you can fix it by not passing the grid as a pointer to setup_single_toggle.
20160126 02:19:50< iceiceice> i guess i dont know why you would ever overload &
20160126 02:20:09< celticminstrel> iceiceice: I think MFC or something does so for some reason.
20160126 02:20:19< vultraz> celticminstrel: but I don't know how to make it not a pointer 
20160126 02:20:20< celticminstrel> Not that I've ever used it.
20160126 02:20:25< vultraz> since it has to be a pointer
20160126 02:20:32< vultraz> as evidenced on line 1
20160126 02:20:38< celticminstrel> vultraz: Whenever you have a pointer and you want a reference, just use the indirection operator.
20160126 02:20:52< vultraz> the what now?
20160126 02:20:56< celticminstrel> The indirection operator is the prefix * operator.
20160126 02:21:17< celticminstrel> So, if main_grid is a pointer, then *main_grid is a reference.
20160126 02:21:29< shadowm> I called it just that when I was first teaching vultraz C++ last year.
20160126 02:21:37< shadowm> ¬_¬
20160126 02:22:04< celticminstrel> I'm pretty sure I used it with him a month or two ago.
20160126 02:22:10< celticminstrel> The name, I mean.
20160126 02:22:39< vultraz> YAY IT BUILDS 
20160126 02:23:16< vultraz> but does it run
20160126 02:23:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160126 02:23:32< celticminstrel> That's the question of the year.
20160126 02:23:47< vultraz> it does :O
20160126 02:24:09< shadowm> A better question is if it does what it's supposed to....
20160126 02:24:23< iceiceice> harder question: does wesnoth as a whole have formally undefined behavior
20160126 02:24:39< vultraz> it does
20160126 02:24:50< vultraz> I mean it does what it's supposed to do
20160126 02:24:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:25:07< iceiceice> at least once
20160126 02:25:09< iceiceice> on your machine :p
20160126 02:25:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 02:25:55< vultraz> xD
20160126 02:28:38< vultraz> much thanks you guys 
20160126 02:30:32-!- gfgtdf_ [~chatzilla@f054052101.adsl.alicedsl.de] has joined #wesnoth-dev
20160126 02:30:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 02:32:26-!- gfgtdf [~chatzilla@x50abdd2a.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20160126 02:32:26-!- gfgtdf_ is now known as gfgtdf
20160126 02:35:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 02:36:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 03:05:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160126 03:07:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 03:08:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 03:10:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 03:11:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 03:14:17< vultraz> oh deer. bad lexical cast
20160126 03:16:37< celticminstrel> Fun!
20160126 03:18:45< vultraz> If I catch the exception what happens to the bad value
20160126 03:19:46< shadowm> The exception was thrown fro lexical_cast , that means the function doesn't return a value that would be assigned anywhere.
20160126 03:20:19< shadowm> When an exception is thrown, stack unwinding happens and execution resumes not at the callee, but rather at the closest catch block that matches the exception type.
20160126 03:20:27< shadowm> *caller
20160126 03:27:21< gfgtdf> do you get teh bas lexical cat froma bad user input string ?
20160126 03:27:37< vultraz> no from dragging a slider 
20160126 03:27:42< vultraz> I'll have to look into it 
20160126 03:28:36< vultraz> but first I'm faced by another gui2-ism.  find_widget doesn't include scroll labels under its search if you pass tlabel even though both use the tlabel class >_>
20160126 03:29:20< shadowm> Uh, scroll labels aren't labels.
20160126 03:29:25< shadowm> They contain labels.
20160126 03:29:37< shadowm> namespace gui2 { class tscroll_label : public tscrollbar_container
20160126 03:29:59< shadowm> The usual approach is to look for tcontrol instead.
20160126 03:33:58< gfgtdf> shadowm: you know whetrhe the names colors are defined by pango or cairo or something else?
20160126 03:34:31< shadowm> I assume Pango, but it _could_ be Cairo.
20160126 03:38:19< vultraz> gfgtdf: I found another bug in tree views: this is what happens if you use a scroll label in a node: https://www.dropbox.com/s/2pytylugr7vi4t3/tree%20view%20scroll%20label%20bug.PNG?dl=0
20160126 03:39:29< gfgtdf> vultraz: sure you didnt set scrollbar mode to alway in the scroll label wml ?
20160126 03:39:33< gfgtdf> always
20160126 03:40:02< vultraz> no i didn't
20160126 03:40:14< vultraz> if I set it to never the space still gets reserved underneath the list 
20160126 03:40:57< vultraz> https://www.dropbox.com/s/utb0xojs2gj1sok/empty%20space.PNG?dl=0
20160126 03:40:59< vultraz> like that
20160126 03:41:18< shadowm> Why not use [label] wrap = true instead?
20160126 03:42:05< vultraz> Because labels are bugged and will cut off their value if you set them to a new value larger than the originally allocated space, even with wrap
20160126 03:42:53< shadowm> El sigh...
20160126 03:43:46< gfgtdf> vultraz: maybe you shoudl increaw the originally allocalted space for the label
20160126 03:45:12< vultraz> I've tried that and for some reason it doesn't work
20160126 03:45:46< vultraz> shadowm: I could avoid this by removing the whole label column to the right but I figured you'd want me to keep values visible at a glance without having to go into the node
20160126 03:48:38-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160126 03:50:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160126 03:55:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 04:00:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160126 04:03:53-!- gfgtdf [~chatzilla@f054052101.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160126 04:26:14< ancestral> Feel free to close this one: https://gna.org/bugs/index.php?23199
20160126 04:32:12< vultraz> ah, lexical_cast_default is a thing
20160126 04:40:48 * ancestral just listened to the new Frantic for the first time
20160126 04:56:58< vultraz> dammit, setter not working...
20160126 04:59:12< vultraz> ahhh
20160126 04:59:36< vultraz> I had disambiguated the wrong overload
20160126 05:03:48-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160126 05:05:38-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160126 05:14:39-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160126 05:29:29< vultraz> shadowm: to elaborate on the label wrap issue, it extends the label vertically but doesn't consider horizontal space 
20160126 05:43:58-!- mjs-de [~mjs-de@f049107050.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160126 05:46:48-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160126 06:22:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 06:27:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160126 07:03:59-!- Kwandulin [~Miranda@p200300760F69246E6028771D346D60EF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160126 07:33:53< vultraz> error: invalid use of void expression| ugh 
20160126 07:34:00< vultraz> what does this even mean
20160126 07:44:12< ancestral> Note to self: best not to use Legend of the North for the Wesnoth trailer: http://store.steampowered.com/app/247000
20160126 07:46:29< vultraz> huh
20160126 07:48:03< vultraz> good catch 
20160126 07:57:58-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160126 08:34:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160126 08:34:16-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160126 08:49:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 08:53:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 245 seconds]
20160126 09:11:15-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160126 09:20:18-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160126 09:40:32< Aginor> hmmz
20160126 09:40:46< Aginor> trying to figure out gui2 and events
20160126 09:52:57-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160126 09:55:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20160126 09:55:31-!- wedge010 is now known as wedge009
20160126 09:57:00-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 260 seconds]
20160126 10:08:15-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 240 seconds]
20160126 10:15:30< vultraz> Aginor: good luck :P
20160126 10:15:39< vultraz> Aginor: what are you working on?
20160126 10:21:44-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20160126 10:29:18-!- Kwandulin [~Miranda@p200300760F69246E6028771D346D60EF.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20160126 10:31:13-!- Kwandulin [~Miranda@p200300760F6924E66028771D346D60EF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160126 10:43:38< Aginor> vultraz: I've sussed out the GUI1 bits, they're not too complex
20160126 10:44:24< Aginor> but I want to know when a GUI2 toplevel component is destroyed, and I want to extend the event handling to deal with more/global event contexts
20160126 10:44:40< Aginor> that will have to be continued tomorrow though
20160126 10:44:56< Aginor> (working on the last of the gui problems)
20160126 10:46:05< vultraz> I've come more and more to realize GUI2 is a huge complicated mess
20160126 10:48:28< vultraz> gfgtdf might know about event handling in it, though
20160126 10:55:34-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160126 10:58:36< loonycyborg> shadowm: Not sure, could as well be the same. At that time I didn't change dlls often..
20160126 11:16:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 11:21:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160126 11:27:25-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160126 11:40:43-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has joined #wesnoth-dev
20160126 11:52:35-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160126 12:21:03-!- Kwandulin [~Miranda@p200300760F6924E66028771D346D60EF.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160126 12:27:11-!- Xara [yangyf@2001:cc0:2020:4010:a894:53cf:bdf4:c8d5] has joined #wesnoth-dev
20160126 12:32:42-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160126 13:05:00-!- prkc [~prkc@51B78693.dsl.pool.telekom.hu] has joined #wesnoth-dev
20160126 13:06:02-!- horrowind [~Icedove@2a02:810a:8b00:1a54:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160126 13:08:56-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 276 seconds]
20160126 13:14:02-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20160126 13:34:28-!- Kwandulin [~Miranda@p200300760F6924E6F42C9039AE19CFA7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160126 13:49:42-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has quit [Quit: Leaving]
20160126 13:57:41-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 276 seconds]
20160126 14:03:06-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160126 14:06:04< vultraz> grrrrrr
20160126 14:07:15< vultraz> tfw you have to deal with bools as numbers >_>
20160126 14:07:54< vultraz> get_value() returns integers 
20160126 14:08:04 * vultraz groans
20160126 14:08:14< vultraz> and I was so close to unifying the value setter too
20160126 14:08:24< vultraz> guess I have to make overloads for different types of functions
20160126 14:09:06< vultraz> or maybe
20160126 14:09:14< vultraz> maybe you can get widget types?
20160126 14:09:26< vultraz> but then I'd still need to pass a vector for the combobox
20160126 14:09:34< vultraz> unless the vector is a class member value 
20160126 14:24:12< vultraz> YES the vector is a class member value
20160126 14:24:18< vultraz> ok I can simplify some code here 
20160126 14:34:28< vultraz> well
20160126 14:34:30< vultraz> hm
20160126 14:34:33< vultraz> actually I can't
20160126 14:50:18-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160126 15:02:41< vultraz> useful anyway
20160126 15:07:17-!- Xara [yangyf@2001:cc0:2020:4010:a894:53cf:bdf4:c8d5] has quit [Read error: Connection reset by peer]
20160126 15:21:07-!- gfgtdf [~chatzilla@f054052101.adsl.alicedsl.de] has joined #wesnoth-dev
20160126 15:21:53< gfgtdf> vultraz: you can call get_value_bool() on togglebutton/toggle panels if you know that it is a bood
20160126 15:22:04< gfgtdf> vultraz: meaning if its not a tristate button or similar
20160126 15:37:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 15:52:59-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 264 seconds]
20160126 15:55:42-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160126 16:28:38-!- mjs-de [~mjs-de@f048182077.adsl.alicedsl.de] has joined #wesnoth-dev
20160126 16:37:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 16:37:07-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160126 16:37:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160126 16:37:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 16:37:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160126 16:38:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 16:38:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 16:38:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160126 16:39:03-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160126 16:39:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 16:51:15-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 240 seconds]
20160126 16:58:40-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160126 17:02:11-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160126 17:07:15-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160126 17:07:17-!- wedge010 is now known as wedge009
20160126 17:16:52-!- boucman [~rosen@2a02-8428-034f-f800-285e-7a35-429c-f1a5.rev.sfr.net] has joined #wesnoth-dev
20160126 17:16:56-!- boucman [~rosen@2a02-8428-034f-f800-285e-7a35-429c-f1a5.rev.sfr.net] has quit [Changing host]
20160126 17:16:56-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160126 17:24:34-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160126 17:28:31-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 260 seconds]
20160126 17:35:00-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20160126 18:10:24-!- ancestral [~ancestral@63.92.246.121] has joined #wesnoth-dev
20160126 18:12:04-!- ancestral [~ancestral@63.92.246.121] has quit [Client Quit]
20160126 18:21:59-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160126 18:22:14-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 276 seconds]
20160126 18:44:54-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20160126 19:26:40-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 19:26:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 245 seconds]
20160126 19:27:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160126 19:30:54-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 250 seconds]
20160126 19:31:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 19:32:51-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160126 19:39:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 19:41:45< Ravana_> shadowm zookeeper: would be nice if someone dealt with current spammer
20160126 19:59:35< zookeeper> done
20160126 20:11:35-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160126 20:17:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160126 20:51:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160126 20:59:54-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160126 21:05:34< vultraz> gfgtdf: I know - I just didn't realize that that actually returns "0/1" not "yes/no"
20160126 21:05:55< gfgtdf> vultraz: you mean true/false
20160126 21:07:11< gfgtdf> vultraz: i changed that code into returning numbers when i implemented the tristate buttons (it then returns 0,1,2 .. n-1 for n-state buttons)
20160126 21:09:05-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160126 21:19:12-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160126 21:22:57-!- Redfur [~Sasquash@c-24-21-217-33.hsd1.or.comcast.net] has joined #wesnoth-dev
20160126 21:23:21-!- Redfur [~Sasquash@c-24-21-217-33.hsd1.or.comcast.net] has left #wesnoth-dev []
20160126 21:36:11-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection timed out]
20160126 21:41:56-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160126 21:45:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160126 21:52:54-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160126 21:55:55-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160126 21:55:56-!- wedge010 is now known as wedge009
20160126 21:59:14-!- SpoOkyMagician [~chatzilla@cpe-74-136-45-198.kya.res.rr.com] has joined #wesnoth-dev
20160126 22:19:15< vultraz> shadowm: do you have an idea how to implement the 'custom' advanced pref type? I had previously thought specifying a function name in the config would be enough, but then I realized C++ doesn't do dynamic function names
20160126 22:39:54-!- Kwandulin [~Miranda@p200300760F6924E6F42C9039AE19CFA7.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160126 22:44:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20160126 22:50:05< shadowm> vultraz: Simple: the preference by itself does nothing, the dialog must have its own mapping of ids to calls.
20160126 22:50:22< shadowm> (That's kind of obvious.)
20160126 22:51:03< vultraz> Ok, so manually set up a callback for each custom option? I can do that
20160126 22:52:31< shadowm> If you want to get into syntax, I'd just use an if/else chain.
20160126 22:52:54< shadowm> There's not much point into doing anything fancier than that other than proving that you can write code where not needed.
20160126 23:03:25-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160126 23:10:12< vultraz> I already have a enum in plane 
20160126 23:10:14< vultraz> place
20160126 23:10:55-!- Appleman1234 [~Appleman1@KD119104014008.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20160126 23:13:03< shadowm> ... enum.
20160126 23:13:19< shadowm> Even though options have alphanumeric ids.
20160126 23:18:11< shadowm> Either you have set up something needlessly convoluted or I don't know.
20160126 23:23:42-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Ping timeout: 265 seconds]
20160126 23:35:13< vultraz> I used MAKE_ENUM to set up a key for each type option
20160126 23:55:13< vultraz> well, I could just use type=custom and then an option_id key
20160126 23:56:23< shadowm>     field=mouse_scrolling
20160126 23:56:27< shadowm> There is such an attribute already.
20160126 23:57:09< vultraz> right, right
20160126 23:57:28< vultraz> alright, t'is simple
20160126 23:59:26< vultraz> I hope you'll review the PR before it gets marged anyway
20160126 23:59:27< vultraz> merged
20160126 23:59:29< shadowm> The annoying thing is that you arrived at the same conclusion I did first.
20160126 23:59:52< vultraz> What?
--- Log closed Wed Jan 27 00:00:10 2016