--- Log opened Sat Feb 06 00:00:35 2016
20160206 00:18:31-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160206 00:18:32-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160206 00:28:58-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160206 00:30:48-!- travis-ci [~travis-ci@ec2-184-73-29-113.compute-1.amazonaws.com] has joined #wesnoth-dev
20160206 00:30:49< travis-ci> wesnoth/wesnoth#8394 (master - b3d9060 : gfgtdf): The build is still failing.
20160206 00:30:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/107366818
20160206 00:30:49-!- travis-ci [~travis-ci@ec2-184-73-29-113.compute-1.amazonaws.com] has left #wesnoth-dev []
20160206 00:36:40< irker030> wesnoth: gfgtdf wesnoth:master 1e518a56d858 / src/unit.cpp: fix unit image and image_icon in unit.__cfg https://github.com/wesnoth/wesnoth/commit/1e518a56d85892c2c7d8aa5d0a5223ac1b60013d
20160206 00:42:00< irker030> wesnoth: gfgtdf wesnoth:master f3ba474f5038 / src/unit.cpp: use to_string instead of lexical_cast https://github.com/wesnoth/wesnoth/commit/f3ba474f5038315a8cdc5fd78e6ff9df5958f9eb
20160206 00:44:05-!- mjs-de [~mjs-de@f048244070.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160206 00:45:00-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20160206 00:48:51-!- ancestral [~ancestral@63.92.240.233] has quit [Client Quit]
20160206 00:50:26-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20160206 01:05:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160206 01:14:07-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160206 01:15:32-!- travis-ci [~travis-ci@ec2-174-129-106-167.compute-1.amazonaws.com] has joined #wesnoth-dev
20160206 01:15:33< travis-ci> wesnoth/wesnoth#8396 (master - 1e518a5 : gfgtdf): The build was fixed.
20160206 01:15:33< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/107372409
20160206 01:15:33-!- travis-ci [~travis-ci@ec2-174-129-106-167.compute-1.amazonaws.com] has left #wesnoth-dev []
20160206 01:30:04-!- Appleman1234 [~Appleman1@KD119104005059.au-net.ne.jp] has joined #wesnoth-dev
20160206 01:42:39-!- travis-ci [~travis-ci@ec2-184-73-29-113.compute-1.amazonaws.com] has joined #wesnoth-dev
20160206 01:42:40< travis-ci> wesnoth/wesnoth#8397 (master - f3ba474 : gfgtdf): The build has errored.
20160206 01:42:40< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/107373036
20160206 01:42:40-!- travis-ci [~travis-ci@ec2-184-73-29-113.compute-1.amazonaws.com] has left #wesnoth-dev []
20160206 01:45:19-!- SpoOkyMagician [~chatzilla@cpe-74-136-45-198.kya.res.rr.com] has quit [Quit: thats enough for today]
20160206 02:37:38-!- ancestral [~ancestral@51.sub-70-197-227.myvzw.com] has joined #wesnoth-dev
20160206 02:39:40-!- gfgtdf [~chatzilla@f054141091.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160206 02:50:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160206 03:06:18-!- ancestral [~ancestral@51.sub-70-197-227.myvzw.com] has quit [Quit: i go nstuf kthxbai]
20160206 03:13:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160206 03:18:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160206 03:21:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160206 03:31:07-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 03:42:02-!- irker030 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160206 04:10:38-!- Appleman1234 [~Appleman1@KD119104005059.au-net.ne.jp] has quit [Read error: Connection reset by peer]
20160206 05:16:00-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 05:24:10-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 05:25:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160206 05:30:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160206 06:34:38-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 06:41:21-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160206 07:05:45-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 07:05:52-!- Kwandulin [~Miranda@p200300760F0BC58281431032063BFA93.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160206 07:52:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160206 07:56:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160206 08:06:15-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 08:14:33-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20160206 08:55:21< vultraz> Aginor: ping
20160206 08:55:58< vultraz> Aginor: I noticed something, and i was wondering the cause: dragging a gui2 slider isn't smooth - is this because of inefficient draw routines or maybe bc of sdl event polling?
20160206 08:56:05< vultraz> (ie, only x milliseconds)
20160206 08:56:08< vultraz> only every*
20160206 08:58:48< vultraz> im tentatively thinking the former
20160206 09:10:52< shadowm> I'd say it's connected to the > 30% idle CPU usage issue introduced with the SDL 2 port.
20160206 09:12:37< shadowm> Every cycle spent not sleeping is a missed opportunity for an event.
20160206 09:14:50-!- Kwandulin [~Miranda@p200300760F0BC58281431032063BFA93.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160206 09:17:24< vultraz> Oh, I see..
20160206 09:19:22-!- irker906 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160206 09:19:22< irker906> wesnoth: Charles Dang wesnoth:master b4aa768fc8c7 / src/gui/widgets/grid.cpp: tgrid: preserve visible status when swapping widgets https://github.com/wesnoth/wesnoth/commit/b4aa768fc8c7ab7aa90b2dec942b782ea686312b
20160206 09:27:55< vultraz> shadowm: will you be free next Friday (the 12th) for a possible release?
20160206 09:29:05< vultraz> I *think* Aginor is nearing completion on guifixes, and 581 just needs review, so I'm tentatively thinking next Friday could be release day.
20160206 09:29:16< vultraz> If not, the 19th
20160206 09:30:08< shadowm> At this time I can't promise I will be available or physically enabled to perform a release at any given date.
20160206 09:30:39< shadowm> *make
20160206 09:33:40< vultraz> Alright
20160206 09:50:53-!- travis-ci [~travis-ci@ec2-54-81-13-214.compute-1.amazonaws.com] has joined #wesnoth-dev
20160206 09:50:54< travis-ci> wesnoth/wesnoth#8398 (master - b4aa768 : Charles Dang): The build passed.
20160206 09:50:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/107415778
20160206 09:50:54-!- travis-ci [~travis-ci@ec2-54-81-13-214.compute-1.amazonaws.com] has left #wesnoth-dev []
20160206 10:00:21-!- Kwandulin [~Miranda@p200300760F0BC5822539B96286B9B8F0.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160206 10:00:36-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160206 10:03:47-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20160206 10:03:48-!- wedge010 is now known as wedge009
20160206 10:15:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160206 10:34:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160206 10:39:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160206 11:07:47-!- mjs-de [~mjs-de@x4db543c6.dyn.telefonica.de] has joined #wesnoth-dev
20160206 11:07:52-!- mjs-de [~mjs-de@x4db543c6.dyn.telefonica.de] has quit [Client Quit]
20160206 11:08:20-!- mjs-de [~mjs-de@77.181.67.198] has joined #wesnoth-dev
20160206 11:11:47-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160206 12:01:05-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160206 12:11:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160206 12:33:25-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
20160206 12:33:45-!- Kwandulin [~Miranda@p200300760F0BC5822539B96286B9B8F0.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
20160206 12:41:47< zookeeper> vultraz, oddly enough, the debug target doesn't work: C:\Games\Wesnoth-git\src\variable.cpp|157|undefined reference to `config::add_child(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, config&&)'|
20160206 12:41:55< zookeeper> when i switch to release, no problems
20160206 12:42:13< vultraz> maybe a file didn't get added to debug at some point
20160206 12:43:49< vultraz> but I doubt it
20160206 12:51:07< zookeeper> and even if i switch debug symbols on for the release build, they still won't show up in a profiler
20160206 12:55:21-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 13:18:16-!- gfgtdf [~chatzilla@f054141091.adsl.alicedsl.de] has joined #wesnoth-dev
20160206 13:18:24< gfgtdf> zookeeper: which profiler do you use?
20160206 13:19:50< gfgtdf> vultraz: did you make sure that all other gui2 dialogs still wok after https://github.com/wesnoth/wesnoth/commit/b4aa768fc ?
20160206 13:20:29< vultraz> yes everything seems to
20160206 13:20:40-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160206 13:25:58-!- gfgtdf [~chatzilla@f054141091.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
20160206 13:26:09-!- irker906 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160206 13:29:10-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160206 13:32:36 * vultraz ponders how complicated it would be to implement radio buttons as their own widget
20160206 13:43:34< zookeeper> gfgtdf, very sleepy
20160206 13:46:01-!- gfgtdf [~chatzilla@f054141091.adsl.alicedsl.de] has joined #wesnoth-dev
20160206 13:46:12< gfgtdf> vultraz: actually i see no reason to do so
20160206 13:46:25< gfgtdf> zookeeper: is that better than visual studios own debugger ?
20160206 13:46:39< vultraz> well there should be some genertic function to register buttons as a group then
20160206 13:47:15< zookeeper> gfgtdf, i don't know
20160206 13:47:21< zookeeper> it's simple and easy to use
20160206 13:48:10< gfgtdf> vultraz: hmm cant you just create a toggle_button_croup class or similar that contains a list of tselectable and deselects all other items in the list when one is selected?
20160206 13:48:22< vultraz> yes
20160206 13:48:31< vultraz> but every dialog that wants to do that has to dupe the code
20160206 13:48:59< gfgtdf> vultraz: well no if you'D wite sucha  class you could just use it in every dialog
20160206 13:49:12< vultraz> a class, you say
20160206 13:49:41< gfgtdf> yes
20160206 13:52:27< vultraz> first would like to get it working in one dialog without using class member variables
20160206 13:52:38< gfgtdf> ?
20160206 13:53:09< vultraz> currently in the prefs dialog I copied the radio code from teditor_edit_side
20160206 13:53:21< gfgtdf> every normal calss has member variables.
20160206 13:53:21< vultraz> which makes use of a class member variable for its vector
20160206 13:53:43< vultraz> but i guess if i make this its own class i can use a member variable
20160206 13:53:54< vultraz> maybe i should do that instead of trying to make this work
20160206 13:53:56< vultraz> hm
20160206 13:54:52< vultraz> i've never actually written a class before
20160206 13:54:59 * vultraz looks up some documentation
20160206 13:57:40< vultraz> i guess it would have to be a subclass of tbutton
20160206 13:58:08< vultraz> er
20160206 13:58:10< vultraz> ttoggle_button
20160206 14:00:44< gfgtdf> vultraz: no i actually just thought of a class that holds teh vector and does the work that currently has to be copied into every dialog that wants toggle buttons.
20160206 14:01:38< gfgtdf> vultraz: more or less liek this http://pastebin.com/7fxrcvVS (pseudocode)
20160206 14:04:18< vultraz> hm...
20160206 14:04:25< vultraz> or what about not even a class
20160206 14:04:40< vultraz> er
20160206 14:04:42< vultraz> actually 
20160206 14:04:44< vultraz> wait
20160206 14:05:41< vultraz> gfgtdf: ok what about an add_to_group() member in ttoggle_button and a subclass that has a vector for the group 
20160206 14:07:49< vultraz> and then ttoggle_button::signal_handler_left_button_click will handle the call to a delesect() member of the subclass
20160206 14:08:08< vultraz> is that possible 
20160206 14:09:58< vultraz> though im not sure how to keep track of all the groups
20160206 14:10:23< vultraz> maybe a vector?
20160206 14:20:46< vultraz> er
20160206 14:20:48< vultraz> hm..
20160206 14:21:34< vultraz> is it possible to have a parent class have, say, a vector of objections of a subclass?
20160206 14:24:56< vultraz> or does it only work the other way around
20160206 14:30:58-!- Kwandulin [~Miranda@p200300760F0BC5356CD861C7776FA0D4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160206 14:31:03< vultraz> hmm
20160206 14:31:30< vultraz> wait, we only want to keep one list of all the button groups
20160206 14:31:47< vultraz> so it can't be in ttoggle_button
20160206 14:32:31< vultraz> because there are many toggle buttons :/
20160206 14:32:53< vultraz> gfgtdf: would such a vector go in tselectable_?
20160206 14:39:25 * vultraz waits for celticminstral
20160206 14:43:15< gfgtdf> vultraz: hmm no the list of toggle groups shoudl eigher be owned by the dialog calss or by teh widgt that contains the togglebuttons (tcontainer ot tpanel)
20160206 14:43:46< gfgtdf> vultraz: the later woudl also allow to specify toggle groups by wml.
20160206 14:43:59< vultraz> tcontainer?
20160206 14:44:07< gfgtdf> vultraz: well not 100% sure but i think that cound be possible
20160206 14:44:18-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160206 14:45:00< vultraz> ttoggle_button inherits from tcontrol you don't mean that?
20160206 14:45:35< gfgtdf> no i dont
20160206 14:45:54< vultraz> hm ok
20160206 14:46:26< gfgtdf> i meant tcontainer
20160206 14:46:35< gfgtdf> tcontainer_
20160206 14:47:08< vultraz> ya
20160206 14:47:27-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 14:48:05< vultraz> so I make it a public member of tcontainer_ and then I can add to it from a ttoggle_button member?
20160206 14:50:24< vultraz> er
20160206 14:50:34< vultraz> private and then call a setter i
20160206 14:50:36< vultraz> guess
20160206 14:53:28-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 14:56:00< vultraz> ok I guess tcontainer should inherit from the propose grouping class
20160206 15:03:33< vultraz> celticminstrel: what's the = 0 thing at the end of some virtual functions mean?
20160206 15:03:50< vultraz> I'm attempting to learn to use class inheritance :|
20160206 15:04:14< celticminstrel> vultraz: That means it's pure virtual.
20160206 15:05:09< vultraz> which means... its implementation is always in inherited classes?
20160206 15:05:43< celticminstrel> Well, you can implement a pure virtual method if you really want, but you generally don't.
20160206 15:06:50< celticminstrel> The presence of a pure virtual method (either declared or inherited without overriding) marks the class as abstract.
20160206 15:13:22 * vultraz ponders virtual methods
20160206 15:13:46< vultraz> ok, so I'm thinking..
20160206 15:13:54< vultraz> if we wanted different widgets to be able to use this then uh..
20160206 15:14:06< vultraz> maybe the add_to_group method should be pure virtual
20160206 15:14:19< vultraz> OR
20160206 15:14:23< vultraz> I could use a template..
20160206 15:14:31< vultraz> celticminstrel: how do templates work with virtual functions?
20160206 15:15:07< celticminstrel> Same way they work with non-virtual functions?
20160206 15:15:11< vultraz> ok
20160206 15:15:50< celticminstrel> Virtual means it can be overridden.
20160206 15:16:25< vultraz> (on second thought, can probably use twidget)
20160206 15:28:58< vultraz> the whole class paradigm is a little hard to wrap your head around :|
20160206 15:29:08< vultraz> since I've never really paid attention to their interactions
20160206 15:34:10< celticminstrel> What's hard about it?
20160206 15:35:52< vultraz> well....
20160206 15:35:59< vultraz> ok so uh...
20160206 15:36:16< vultraz> I wanted to implement a simple way to use radio buttons
20160206 15:36:27< vultraz> in any dialog, without having to copy code
20160206 15:37:22< vultraz> I was going to make a toggle button group class, but then I realized you can't store a vector of groups in ttoggle_button, since there are multiple toggle buttons all over the place
20160206 15:37:51< vultraz> so gfgtdf suggested in tcontainer_, which is inherited from by multiple widgets (not ttoggle_button, but I guess I can add that)
20160206 15:38:05< vultraz> so right now I have the basic vector setups done
20160206 15:38:10< vultraz> but
20160206 15:38:13< gfgtdf> vultraz: no toggle_button shoudl not inherit from tvcontainer
20160206 15:38:29< vultraz> the groups are basically vectors of widgets
20160206 15:38:42< vultraz> the widgets have their own event handlers
20160206 15:38:46< vultraz> so I'm wondering..
20160206 15:39:04< vultraz> if I wanted to implement a method to do something to those widgets
20160206 15:39:06< vultraz> how would I do it
20160206 15:40:04< vultraz> ill make a commit in a sec..
20160206 15:42:10< vultraz> celticminstrel, gfgtdf: https://github.com/Vultraz/wesnoth/commit/4995f44467e8f9b6a8c77a80d43042337805e58e
20160206 15:42:26< vultraz> (it's in 581 since i will be using 581 as a testing area)
20160206 15:44:07-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160206 15:44:26< gfgtdf> vultraz: tgroup is a too gerneal name you chosul call i toggle group or something
20160206 15:44:54< vultraz> gfgtdf: well I was thinking maybe other widgets could use it too
20160206 15:45:06< vultraz> something like
20160206 15:45:33< vultraz> a pure virtual do_something() method implemented by any widget class that wants to use it?
20160206 15:46:10< vultraz> (add_group and add_to_group might not need to be virtual)
20160206 15:46:30< gfgtdf> vultraz: well, unless you have a conrete idea for a different usecase than togglebutton/togglepanel i'd just do it for togglebutton/tselectable
20160206 15:46:46< vultraz> ok
20160206 15:47:37< gfgtdf> vultraz: specialyl since one can esily generalize oif afterwards it it works for togglebuttons.
20160206 15:48:30< vultraz> right
20160206 15:48:40< vultraz> im just trying to figure out how to make it work with toggle buttons
20160206 15:49:40< vultraz> (on second though add_group/add_to_group should probably be virtual, yeah...)
20160206 15:51:23< vultraz> celticminstrel: comparing two pointers to the same object returns true?
20160206 15:53:14-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Konversation terminated!]
20160206 15:53:29-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160206 15:56:58< vultraz> celticminstrel: also when overriding a virtual method you also need the virtual keyword, right?
20160206 15:57:37< vultraz> er... hm
20160206 15:57:38< vultraz> no?
20160206 15:59:40-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
20160206 16:01:13< gfgtdf> celticminstrel: i think you broke [put_to_recall_list] in https://github.com/wesnoth/wesnoth/commit/c4bb4c253601fc45849fba2cea37fcfe57b3e1ed
20160206 16:01:49< vultraz> hm...
20160206 16:03:07< vultraz> ok I screwed up.. compiler wants an object
20160206 16:03:49< vultraz> but ttoggle button doesn't have a tcontainer object :|
20160206 16:04:55< vultraz> gfgtdf: since groups_ is stored in tcontainer_ don't you need a tcontainer_ object to access it
20160206 16:06:07< gfgtdf> vultraz: yes my idewa was that toggle_buttpn searches for the tcontainer that own teh toggle button (calling parrent until you found one) and use that then.
20160206 16:06:21< vultraz> hmmm
20160206 16:07:08< vultraz> im not sure how to do that
20160206 16:07:46< celticminstrel> [Feb 06@10:51:23am] vultraz: celticminstrel: comparing two pointers to the same object returns true?
20160206 16:07:47< celticminstrel> Provided the pointers are the same type, definitely yes. Even if they aren't, they'll usually compare true if pointing to the same object.
20160206 16:08:22< celticminstrel> gfgtdf: Broke how?
20160206 16:09:23< vultraz> gfgtdf: get_parent()?
20160206 16:09:47< vultraz> so like
20160206 16:10:08< vultraz> get_parent<tcontainer_>this->groups();
20160206 16:12:32-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160206 16:14:17< vultraz> ok this builds
20160206 16:14:19< vultraz> get_parent<tcontainer_>(*this).add_to_group("foo", this);
20160206 16:21:00< gfgtdf> celticminstrel: broke as in: it now doesnt put the unit to the recall list, its just removes them
20160206 16:22:03< celticminstrel> gfgtdf: If you comment out the erase line, does it remain on the map but also go to the recall list?
20160206 16:22:21< vultraz> ok, I think I know how to manipulate the vector
20160206 16:22:36< vultraz> i'll add a method to tgroup that takes a boost::function argument
20160206 16:22:52< vultraz> where the group vector is passed to that function
20160206 16:23:13< gfgtdf> celticminstrel: i don't know, but my guess would be no
20160206 16:24:16< vultraz> celticminstrel: a class needs to inherit from one with virtual members to override them, correct?
20160206 16:24:51< celticminstrel> Members that are not virtual can't be overridden, only hidden.
20160206 16:25:27< vultraz> gfgtdf: is it ok if I make ttoggle_button inherit from tgroup?
20160206 16:26:27< gfgtdf> vultraz: hm i dont realyl know hat you ar epalnning to do
20160206 16:26:46< vultraz> im still figuring it out
20160206 16:27:13< vultraz> ok I need to add ummm
20160206 16:27:22< vultraz> a group getter method
20160206 16:27:32< vultraz> so I need... ITERATORS D:
20160206 16:28:04< gfgtdf> why do you need them? (i don't really like iterators)
20160206 16:28:39< vultraz> well tcontainer_ has a vector of all the groups
20160206 16:28:53< vultraz> and i think I'll need to fetch a specific group from that vector
20160206 16:29:50< gfgtdf> vultraz: if you want to give the groups names, if use a map string- group instead of a vector f groups
20160206 16:29:57-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 16:30:25< vultraz> right now I have the id as a member of each tgroup object
20160206 16:30:54< gfgtdf> vultraz: maybe you shuld just have teh list/map of groups just in the twindow instead of the tcontainer
20160206 16:31:11< vultraz> :|
20160206 16:31:28< vultraz> i guess i could
20160206 16:31:31< vultraz> move it
20160206 16:32:10< gfgtdf> vultraz: if you want only the id to be unique  per window having it twindow is a good idea.
20160206 16:32:48< vultraz> yeah I think group ids should be unique per window
20160206 16:33:33< gfgtdf> vultraz: then you coudl also just call get_window in the toggle buttons.
20160206 16:33:35< vultraz> and then I can use get_window()
20160206 16:33:39< vultraz> right
20160206 16:33:47< vultraz> instead of find_parent
20160206 16:35:41-!- Greg-Boggs [~greg_bogg@199.127.229.254] has joined #wesnoth-dev
20160206 16:42:01-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 16:43:46 * vultraz finds C++ more challenging than his classes
20160206 16:43:53< vultraz> (no pun intended :P )
20160206 16:45:31< vultraz> celticminstrel: ok so uh... if I were to have a function returning an iterator, could I just say... *some_class get_itor() const { *insert loop over objects and get an iterator to return* }
20160206 16:45:45< vultraz> where some_class is the type of object in the vector?
20160206 16:47:20< celticminstrel> Huh?
20160206 16:47:45< vultraz> I have a vector of tgroup objects
20160206 16:47:53< vultraz> and if I wanted to return a pointer to one of them
20160206 16:47:55< vultraz> how would I do it
20160206 16:48:04< celticminstrel> Like a find() call?
20160206 16:48:15< vultraz> I uh... guess, yeah
20160206 16:48:24< vultraz> but I need to access a member variable so I can't use find()
20160206 16:48:32< celticminstrel> Huh?
20160206 16:48:40< vultraz> (need to check if group.id() == some_id)
20160206 16:48:42< celticminstrel> Why can't you access a member variable if you use find()?
20160206 16:48:56< vultraz> you can? O_O
20160206 16:49:09< celticminstrel> I don't know any reason why you can't.
20160206 16:49:16< celticminstrel> It's a vector<tgroup*>, right?
20160206 16:49:40< vultraz> no, std::vector<tgroup>
20160206 16:49:44< celticminstrel> So there's two levels of indirection, which means just the arrow isn't sufficient.
20160206 16:50:15< celticminstrel> ...why is it a vector<tgroup>? Is tgroup not a superclass?
20160206 16:50:29< vultraz> uhhhh.......
20160206 16:50:43< vultraz> nothing inherits from tgroup, yet... 
20160206 16:50:44< celticminstrel> For a vector<tgroup>, with the iterator you'd just need to use the arrow instead of the dot.
20160206 16:50:52< celticminstrel> So, iter->id() instead of group.id().
20160206 16:51:01< celticminstrel> "yet"
20160206 16:51:17< celticminstrel> Does that mean that something could conceivably inherit from tgroup in the future?
20160206 16:52:15< vultraz> depends
20160206 16:52:21< vultraz> I'm still going over the schematics in my head
20160206 16:52:33< vultraz> ie, whether I need a virtual function for manipulation or not
20160206 16:52:37< vultraz> i might not
20160206 16:52:49< vultraz> since i might be able to just have a member variable that takes a boost function argument
20160206 16:52:59< vultraz> but I don't know if that's elegant
20160206 16:53:31< celticminstrel> Well, like I said, if you have an iterator, you need to use the arrow instead of the dot to access members.
20160206 16:53:45< celticminstrel> And if the member itself were a pointer you'd use (*iter)->id().
20160206 16:53:52< vultraz> I also don't know if overrideen virtual functions have access to memebers of the parent class
20160206 16:53:53< vultraz> members*
20160206 16:53:56< vultraz> overridden*
20160206 16:54:26< celticminstrel> If they inherit publicly, they have access to public and protected members of the parent class, but not private members.
20160206 16:54:47< vultraz> ok
20160206 16:54:56< celticminstrel> I forget how it works with protected and private inheritance. It might be the same. But you generally don't use public or private inheritance for polymorphic classes.
20160206 16:55:05< celticminstrel> ^protected or private
20160206 16:56:02< vultraz> and if they inherit privately?
20160206 16:56:24< celticminstrel> I can't remember. It might be the same.
20160206 16:56:40< celticminstrel> But like I said, you don't generally use private inheritance for polymorphic classes.
20160206 16:57:18< vultraz> then uh
20160206 16:57:20< vultraz> what do you use :|
20160206 16:57:28< celticminstrel> Public inheritance.
20160206 16:57:39< vultraz> "But you generally don't use public or private inheritance for polymorphic classes."
20160206 16:57:42< celticminstrel> If you inherit privately it defeats the polymorphism, if I recall correctly.
20160206 16:57:44< vultraz> did you mean protected?
20160206 16:57:56< celticminstrel> I corrected myself right afterwards, yes.
20160206 16:58:00< vultraz> oh
20160206 16:58:02< vultraz> right
20160206 16:58:04< vultraz> didn't see
20160206 16:59:10< celticminstrel> If you inherit privately, you can't assign a tgroup* value to a twidget* variable, except in functions within the tgroup class.
20160206 16:59:20< celticminstrel> I think.
20160206 16:59:56< vultraz> ok, this is what tgroup looks like now
20160206 16:59:58< vultraz> http://pastebin.com/mdf1DSta
20160206 17:00:25< celticminstrel> It's not inheriting from twidget?
20160206 17:00:41< vultraz> oh, right
20160206 17:00:44< celticminstrel> Also, does it make sense to add any kind of widget?
20160206 17:01:03< celticminstrel> What the heck does operate_on_group() do? Add a Doxy comment.
20160206 17:01:08< vultraz> will do
20160206 17:01:19< vultraz> I'm keeping it as twidget in case someone wants to expand it in the future
20160206 17:01:40< vultraz> right now I'm just going to make ttoggle_button inherit from tgroup and implement operate_on_group
20160206 17:02:00< celticminstrel> Why would ttoggle_button inherit from tgroup? How does that make any sense?
20160206 17:02:17< celticminstrel> ttoggle_button is not a tgroup.
20160206 17:02:21< vultraz> i thought you needed to inherit to override a virtual function :|
20160206 17:02:55< celticminstrel> Inheritance (public) expresses an "is a" relation.
20160206 17:03:12< celticminstrel> "class tgroup : public twidget" implies that a group is a type of widget.
20160206 17:03:31< celticminstrel> "class ttoggle_button : public tgroup" implies that a toggle button is a type of group.
20160206 17:03:37< vultraz> oh
20160206 17:03:41< celticminstrel> I'm pretty sure a toggle button is not a type of group.
20160206 17:03:51< celticminstrel> A toggle button is contained in a group.
20160206 17:03:56< vultraz> yes
20160206 17:04:03< celticminstrel> Or, it may be solo.
20160206 17:04:10< celticminstrel> Thus behaving like a checkbox.
20160206 17:05:37< vultraz> ok so
20160206 17:06:04< vultraz> what do I need to do to make sure I can override operate_on_group() in ttoggle_button
20160206 17:06:18< celticminstrel> You can't.
20160206 17:06:27< celticminstrel> Why would you?
20160206 17:06:37< celticminstrel> Why don't you tell me what it's supposed to do first?
20160206 17:07:01< celticminstrel> The name is suspicious.
20160206 17:07:04< vultraz> I was going to let each widget class that uses this define a function to operate on the group
20160206 17:07:18-!- Kwandulin [~Miranda@p200300760F0BC5356CD861C7776FA0D4.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160206 17:07:34< celticminstrel> I don't know what "operate on the group" means.
20160206 17:08:01< vultraz> ok, say, in the toggle button case, we want to give it a "radio" behavior - ie, only one button selected
20160206 17:08:52< celticminstrel> Right.
20160206 17:08:53< vultraz> so it'd go through members_, and unchecking any that didn't match criteria (ie, the widget you clicked on)
20160206 17:08:58< celticminstrel> Right.
20160206 17:08:59< vultraz> s/and//
20160206 17:09:18< vultraz> other widgets would want to do something completely different
20160206 17:09:26< celticminstrel> Why?
20160206 17:09:30< celticminstrel> Like what?
20160206 17:09:32< vultraz> I don't know
20160206 17:09:37< vultraz> I have no usecase right now
20160206 17:09:50< vultraz> I'm just laying groundwork
20160206 17:09:54< celticminstrel> I don't think other widgets should be in a group in the first place.
20160206 17:10:06-!- trewe [~trewe@bl20-24-215.dsl.telepac.pt] has joined #wesnoth-dev
20160206 17:10:09< celticminstrel> Well, unless there're other widgets that have the concept of being "selected".
20160206 17:10:53< vultraz> not really
20160206 17:11:19< vultraz> but you might, say, have two widgets where only one is visible at a time
20160206 17:11:45< vultraz> though that might mean using tgroup in a dialog sense...
20160206 17:12:17< celticminstrel> If you have two widgets where only one is visible at a time, is that really a "group"? It doesn't seem like one to me.
20160206 17:13:10< vultraz> eh, perhaps not
20160206 17:15:24< vultraz> what about 2 sliders that should always have the same value?
20160206 17:15:34< vultraz> granted, that will likely never, ever be used
20160206 17:15:47< celticminstrel> In that case, why are there even two sliders?
20160206 17:15:54< vultraz> good point
20160206 17:16:10< vultraz> radio buttons are really the only good case
20160206 17:16:16< celticminstrel> Maybe two sliders where the limit of one depends on the value of the other, I suppose, but that still doesn't sound like a good candidate for a "group".
20160206 17:16:32< vultraz> so should i use the function argument solution?
20160206 17:17:01< celticminstrel> ?
20160206 17:18:06< vultraz> just have a member of tgroup that accepts a boost::function(void<void>) argument, and then calls that argument with members_ as an argument
20160206 17:18:16< vultraz> calls that function*
20160206 17:18:52< vultraz> (probably will have to use boost::bind too)
20160206 17:20:42< celticminstrel> And what would that passed function do with members_?
20160206 17:20:58-!- trewe [~trewe@bl20-24-215.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
20160206 17:21:18< vultraz> iterate over it and operate on each one
20160206 17:22:02< vultraz> that's why members_ is a vector of pointers
20160206 17:22:44< vultraz> add a widget to a group will pass 'this'
20160206 17:24:11< celticminstrel> That is a better design than having ttoggle_button inherit from tgroup, though I do wonder if there's any point in making this generic.
20160206 17:24:45< vultraz> well, the groups_ vector have to be part of twindow
20160206 17:24:55< vultraz> so it seems logical to make it a little generic
20160206 17:26:00< celticminstrel> Why does the groups_ vector have to be a part of twindow?
20160206 17:26:06< celticminstrel> Is a group not a widget?
20160206 17:26:21< vultraz> ...no?
20160206 17:26:27< celticminstrel> Well, okay.
20160206 17:26:37< vultraz> it's  literally a vector widget pointers
20160206 17:26:44< celticminstrel> A group is more of a controller than a widget, I guess...
20160206 17:26:46< vultraz> that are stuck together to be operated upon
20160206 17:27:05< celticminstrel> But why does the vector have to be part of twindow?
20160206 17:27:13< celticminstrel> Does the window need to know about the group?
20160206 17:27:20< vultraz> to keep group ids unique per window
20160206 17:27:30< celticminstrel> ...I guess to determine which one is selected, maybe?
20160206 17:27:35< vultraz> it can't do in ttoggle_button itself
20160206 17:27:37< vultraz> go*
20160206 17:27:47< celticminstrel> Well, it could.
20160206 17:27:50< celticminstrel> As a pointer.
20160206 17:28:01< celticminstrel> I don't know if that's good design, but it's possible.
20160206 17:28:08< vultraz> uh... no? because there are many many ttoggle_button instances 
20160206 17:28:35< celticminstrel> You'd construct the group in preshow() or something, and assign it to the set of ttoggle_buttons that belong in it.
20160206 17:28:52< celticminstrel> It's a possible way of doing things. I think your way is probably better though.
20160206 17:29:20< celticminstrel> Because that can force unique IDs, like you said, and also makes it simple to ask "which button in this group is currently selected?".
20160206 17:30:15< vultraz> yes
20160206 17:30:35< vultraz> so, back to the manipulation function, I should use the method described above?
20160206 17:31:02< celticminstrel> If you're sticking to making tgroup use twidgets, then sure, I guess.
20160206 17:31:45< celticminstrel> (You could also just make tgroup only work for ttoggle_buttons, and stick that logic directly in the class.)
20160206 17:32:09< vultraz> (I just thought of a possible hole in this entire plan... what happens if the object one of the members_ pointers points to is deleted :| )
20160206 17:32:51< vultraz> guess I should add a if null continue check when looping through it
20160206 17:33:02< celticminstrel> Not sure why that would happen, but yeah, if you think it's a possibility, definitely check.
20160206 17:33:24< celticminstrel> Though why are you using pointers in the first place?
20160206 17:33:32-!- Kwandulin [~Miranda@p200300760F0BC535BDE8DE7D54F871F0.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160206 17:33:58< celticminstrel> Oh, polymorphism, right.
20160206 17:34:08< celticminstrel> Still, you could use shared_ptr.
20160206 17:34:18< vultraz> what is that
20160206 17:34:27< celticminstrel> Smart pointer.
20160206 17:34:42< vultraz> oh dear, that's too complicated for me
20160206 17:35:12< celticminstrel> It's safer, though it doesn't really guard against the possibility you said. It's good for guarding against forgetting to delete.
20160206 17:35:44< celticminstrel> weak_ptr would (at least partially) guard against what you said, but that's even more complicated.
20160206 17:36:08< vultraz> D: 
20160206 17:37:46< celticminstrel> This only works if the caller is also using shared_ptr.
20160206 17:40:42< vultraz> ok, I think I'll actually have the operator function accept one widget from members_
20160206 17:40:54< vultraz> so I can keep the null check in the tgroup implementation
20160206 17:42:08< celticminstrel> The function passed to the tgroup could be something like set_selected(bool).
20160206 17:42:38< celticminstrel> So the tgroup is thus responsible for iterating its members.
20160206 17:42:54< celticminstrel> And calling set_selected(false) on all of them except the selected one.
20160206 17:43:17< vultraz> uh...
20160206 17:43:34< vultraz> i was just going to do this http://pastebin.com/rG8ferRZ
20160206 17:44:05< celticminstrel> That sounds a lot like what I said, but...
20160206 17:44:21< celticminstrel> How does operator_function() know whether the widget is to be selected or unselected?
20160206 17:45:10< vultraz> this...is a good point
20160206 17:45:49< vultraz> let's look at it from the other direction
20160206 17:45:56< vultraz> you have a callback on each button..
20160206 17:46:13< vultraz> each callback passes itself to operator_function()...
20160206 17:48:09< vultraz> celticminstrel: ok so I think
20160206 17:48:22< vultraz> operator_function() should have two ttoggle_button arguments
20160206 17:48:44< vultraz> er
20160206 17:48:46< vultraz> hm
20160206 17:48:52< vultraz> ok we may have a problem
20160206 17:49:02< celticminstrel> ...what's wrong with what I said?
20160206 17:49:30< vultraz> I can't visualize it
20160206 17:49:50< vultraz> where do we get that bool value?
20160206 17:49:59< vultraz> we still need two objects
20160206 17:50:01< vultraz> to check
20160206 17:50:48< celticminstrel> The operate_on_group function needs two objects, yes.
20160206 17:50:55< celticminstrel> Or well.
20160206 17:51:03< celticminstrel> It needs one object as an argument, the other is the iterator.
20160206 17:51:31< vultraz> welll uh
20160206 17:51:38< vultraz> what if...
20160206 17:52:00< vultraz> no, that doesn't work
20160206 17:52:11< celticminstrel> You sure?
20160206 17:52:18< vultraz> no I meant an idea I just had
20160206 17:52:48< vultraz> I'd need to add an in_group variable with the if of a group to ttoggle_button
20160206 17:52:53< vultraz> id*
20160206 17:53:11< vultraz> which is probably a good idea, actually
20160206 17:53:45< vultraz> and since groups are only supposed to have 1 id...
20160206 17:53:48< vultraz> I was thinking
20160206 17:54:19< vultraz> in ttoggle_button::set_value (which is called on click), we could call the get_group() member of twindow with the id of the group a button's in
20160206 17:54:44< vultraz> (still need to implement that - need to figure out what the return value of that function should be - twidget* I think)
20160206 17:54:52< celticminstrel> Though ttoggle_button could store a pointer to its own group.
20160206 17:54:56< vultraz> (er, I mean tgroup*)
20160206 17:55:11< vultraz> it could do that
20160206 17:57:18< vultraz> that would mean uh.. twindow::add_to_group should return something
20160206 17:57:27< vultraz> a pointer to the group
20160206 17:57:49< vultraz> well actually
20160206 17:57:53< vultraz> maybe add_group should do that
20160206 17:58:00< vultraz> er
20160206 17:58:03< vultraz> no they both should
20160206 17:58:10< vultraz> since add_group is called by add_to_group
20160206 18:01:52< vultraz> celticminstrel: how's this look http://pastebin.com/MNwvLcvA
20160206 18:02:41< celticminstrel> Uh yeah, definitely add an error.
20160206 18:03:00< vultraz> (line 7 should be 'return NULL')
20160206 18:03:19< celticminstrel> And line 29 too.
20160206 18:03:45< celticminstrel> Wait no, that should be returning something else.
20160206 18:04:10< vultraz> yeah, need to edit add_member..
20160206 18:04:21< celticminstrel> Why>
20160206 18:04:23< celticminstrel> ^?
20160206 18:04:49< celticminstrel> You want to return &group, right?
20160206 18:05:14< vultraz> oh
20160206 18:05:16< vultraz> right
20160206 18:05:17< vultraz> yes
20160206 18:06:28< vultraz> updated paste
20160206 18:06:35< celticminstrel> What the heck is groups_.last()?
20160206 18:07:13< celticminstrel> I thought groups_ was a vector.
20160206 18:07:19< vultraz> oh, I want back()
20160206 18:07:41< celticminstrel> Yeah, thought so.
20160206 18:08:10< celticminstrel> I actually thought that was C++11, but apparently I was wrong.
20160206 18:09:44< vultraz> dammit
20160206 18:09:47< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\bits\stl_vector.h|713|error: invalid abstract parameter type 'gui2::tgroup'|
20160206 18:10:07< vultraz> it's because i inherit tgroup from twidget
20160206 18:10:13< vultraz> guess I can't do that
20160206 18:10:32< celticminstrel> If you want to do that you need to override all the pure virtual functions.
20160206 18:10:52< celticminstrel> But you're only doing it because I said something, I think, so might as well remove it for now.
20160206 18:14:48< vultraz> ok, ttoggle_button objects now retain a pointer to their member group
20160206 18:14:53< vultraz> SO...
20160206 18:15:06< celticminstrel> Which is NULL if they're not in a group, of course.
20160206 18:15:07< vultraz> why did I need this agaib
20160206 18:15:12< vultraz> again*
20160206 18:15:23< vultraz> of course
20160206 18:15:25< celticminstrel> When clicked you wanted them to call back to their group.
20160206 18:16:43< vultraz> right
20160206 18:17:05< vultraz> ok so I *think*...
20160206 18:17:07< vultraz> uh
20160206 18:17:17< vultraz> I can pass a 'this' argument... to...
20160206 18:18:03< celticminstrel> To operate_on_group.
20160206 18:18:09< vultraz> ok some function needs two arguments..
20160206 18:18:09< celticminstrel> (Which I think should be renamed BTW.)
20160206 18:19:00< vultraz> i just can't seem to picture this
20160206 18:21:32< vultraz> ok so uh
20160206 18:21:40< vultraz> when setting value (set_value)
20160206 18:21:47< vultraz> we check if we're in a group
20160206 18:21:58< vultraz> if so, we call operate_on_group with an argument...
20160206 18:23:24< vultraz> celticminstrel: ok I figured out where I'm lost
20160206 18:23:52< vultraz> I've been working under the assumption that the function passed to operate_on_group will be defined in ttoggle_button
20160206 18:24:09< vultraz> it will be passed to operate_on_group and called from there
20160206 18:24:26< celticminstrel> Didn't I say that was a bad idea?
20160206 18:24:34< vultraz> you did?
20160206 18:24:44< celticminstrel> I said ttoggle_button shouldn't inherit from tgroup.
20160206 18:25:02< vultraz> it doesn't
20160206 18:25:06< vultraz> ok so i'm thinking about this wrong
20160206 18:25:10< vultraz> what if, uh..
20160206 18:25:13< vultraz> WAIT, I know
20160206 18:25:30< vultraz> pass 'this' to operate_on_group (please give me a new name for this)
20160206 18:25:33< vultraz> then
20160206 18:25:43< vultraz> call this->somefunction()
20160206 18:26:17< vultraz> where somefunction() takes a twidget argument
20160206 18:26:27< vultraz> then in some_function we uh
20160206 18:26:38< vultraz> compare this and the provided widget
20160206 18:27:11< vultraz> (I think the whole loop of this has to be moved out of set_value and up into the cl
20160206 18:27:15< vultraz> ick handler
20160206 18:27:25< vultraz> OR I have to introduce a flag to prevent this from looping
20160206 18:27:36< vultraz> either way... no boost::function argument
20160206 18:28:19< vultraz> operate_on_group will also have to become a templated function
20160206 18:30:12< vultraz> ok, so basically, any widget group operator must be called "group_operator()"
20160206 18:30:15< vultraz> fine
20160206 18:30:46< vultraz> I *could* add a virtual member to twidget
20160206 18:30:55< vultraz> but every class would have to override it
20160206 18:31:06< vultraz> and right now that's dumb
20160206 18:34:20< vultraz> "execute_group_actions"
20160206 18:34:21< vultraz> good name
20160206 18:37:49< vultraz> hm
20160206 18:37:51< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\widgets\toggle_button.cpp|200|error: void value not ignored as it ought to be|
20160206 18:38:04< vultraz> group_ = get_window()->add_to_group(group_id, this);
20160206 18:38:13< vultraz> celticminstrel: how is this "not ignoring void value"?
20160206 18:38:36< celticminstrel> I don't really get your chain of thoughts there.
20160206 18:38:50< celticminstrel> Regarding your question, add_to_group presumably returns void.
20160206 18:38:58< celticminstrel> So you can't assign it to something.
20160206 18:39:29< vultraz> no, that overload returns a tgroup pointer
20160206 18:40:40< celticminstrel> Well, that's what the error means.
20160206 18:41:00< celticminstrel> Are there other errors? Maybe fixing one of them will make this error go away.
20160206 18:41:05< vultraz> no, just that
20160206 18:41:33< celticminstrel> Well, the other option would be that get_window returns void, but that's crazy, right?
20160206 18:42:01< vultraz> afaik get_window returns a twindow pointer
20160206 18:44:35< celticminstrel> Are you sure group_id is a string?
20160206 18:45:00< vultraz> yes
20160206 18:45:11< celticminstrel> Are both overloads correctly declared in the twindow header?
20160206 18:45:24< celticminstrel> That should produce errors in window.cpp if they weren't, but...
20160206 18:46:29< vultraz> ahh
20160206 18:47:10< vultraz> i split the get_window() output into a separate variable and now have more errors
20160206 18:47:26< celticminstrel> Fun!
20160206 18:48:08< vultraz> [05:45:10]	celticminstrel	Are both overloads correctly declared in the twindow header? <- t'was an issue
20160206 18:48:33< vultraz> weird that it didn't error otherwise
20160206 18:49:07< celticminstrel> Yeah, should've given an error in window.cpp about the function not matching anything declared in the class.
20160206 18:53:49< vultraz> builds :D
20160206 18:54:05< vultraz> now to implement group_operator
20160206 18:58:51< vultraz> one day maybe someone will refactor this to use the gui2 event chain. some GROUP_EVENT event or something
20160206 18:58:56< vultraz> but not I
20160206 18:59:03< vultraz> I shall use a hacky static flag :P
20160206 19:01:52< vultraz> if this builds, it will be time to test
20160206 19:02:37< vultraz> error: invalid initialization of non-const reference of type 'gui2::ttoggle_button*&' from an rvalue of type 'gui2::ttoggle_button*'|
20160206 19:02:39< vultraz> shit
20160206 19:02:48< vultraz> what is a "*&"
20160206 19:03:37< zookeeper> yay yay managed to build with MSVC again \o/
20160206 19:04:33< vultraz> ah, needed *this
20160206 19:04:53< vultraz> er... shit
20160206 19:05:01< vultraz> undefined reference to `void gui2::tgroup::execute_group_actions<gui2::ttoggle_button>(gui2::ttoggle_button&)'|
20160206 19:05:31< vultraz> guess I have to 
20160206 19:05:36< vultraz> initialize the templated function?
20160206 19:06:30< zookeeper> Aginor, do the #ifdef SDL_GPU stuff in the drawing code have anything to do with SDL2, or is it something entirely different?
20160206 19:06:30< vultraz> nope...
20160206 19:06:41< vultraz> zookeeper: different
20160206 19:06:47-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds]
20160206 19:06:49< zookeeper> okay. old and obsolete?
20160206 19:07:08< vultraz> maybe
20160206 19:07:21< vultraz> we'll probably remove it 
20160206 19:07:23< vultraz> but later
20160206 19:07:56< zookeeper> got it
20160206 19:08:38< vultraz> ugh... this error >_>
20160206 19:09:26< vultraz> the parameters are right..
20160206 19:09:35< vultraz> what's the problem :|
20160206 19:13:09-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 19:15:30< vultraz> ughh
20160206 19:15:34< vultraz> celticminstrel: any ideas? :|
20160206 19:16:14< celticminstrel> *& is a reference to a pointer.
20160206 19:16:19-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 19:16:32< celticminstrel> So, uh.
20160206 19:16:39< celticminstrel> What's this template problem?
20160206 19:17:08< vultraz> weird undefined reference errors
20160206 19:17:22< celticminstrel> Probably because the definition is missing from the translation unit...
20160206 19:17:27< celticminstrel> But why is it a template?
20160206 19:18:02< vultraz> http://pastebin.com/EhHG9Zq9
20160206 19:18:21< vultraz> I need to call the group_operator from a specific class
20160206 19:19:27< celticminstrel> I thought you were going to pass the group_operator as a boost::function.
20160206 19:19:41< vultraz> you said that was a bad idea :|
20160206 19:19:47< celticminstrel> I never said that.
20160206 19:20:23< celticminstrel> I'm pretty sure I didn't.
20160206 19:20:26< vultraz> oh...
20160206 19:20:30< vultraz> we got mixed up
20160206 19:20:39< vultraz> you meant about toggle_button inheriting from tgroup
20160206 19:21:45< vultraz> will making it boost::function change anything?
20160206 19:22:26< celticminstrel> I don't think so.
20160206 19:22:45< celticminstrel> It'll mean it's passed as a function parameter instead of passing the type as a template parameter.
20160206 19:23:37< vultraz> will make the code a little more messy, though
20160206 19:23:49< celticminstrel> Think so?
20160206 19:24:06< vultraz> since I'll have to do... group_->execute_group_actions(boost::bind(&ttoggle_button::group_operator, this, _1));
20160206 19:24:37< vultraz> plus, what type of boost::function should the argument be
20160206 19:26:03< celticminstrel> What exactly does group_operator do?
20160206 19:26:16< vultraz> void ttoggle_button::group_operator(const ttoggle_button* button)
20160206 19:26:18< vultraz> {
20160206 19:26:19< vultraz> 	group_event_handled = true;
20160206 19:26:21< vultraz> 	set_value(this == button);
20160206 19:26:22< vultraz> }
20160206 19:27:40< celticminstrel> I would've passed a bool instead of a widget, but I guess it doesn't matter that much... if you keep it like that, then the functor would be a boost::function<void(twidget*, twidget*)>
20160206 19:28:02< celticminstrel> If you change it to bool, then boost::function<void(twidget*,bool)>
20160206 19:29:06< vultraz> a bool how?
20160206 19:29:39< vultraz> you couldn't get a bool value since 'this' is no longer passed
20160206 19:29:51< celticminstrel> If it was a bool, then execute_group_actions() would call group_operator(widget, widget == caller_widget).
20160206 19:30:33< vultraz> oh
20160206 19:30:51< vultraz> well no, I don't want to do that
20160206 19:30:59< vultraz> I'd rather keep such implementation details in the widget class
20160206 19:31:08-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 19:32:07< celticminstrel> ...then maybe you don't even need caller_widget...
20160206 19:32:47< vultraz> you mean I can call the passed function without it?
20160206 19:32:49< vultraz> sweet
20160206 19:35:24< vultraz> celticminstrel: wait, why did you give it two twidget arguments?
20160206 19:35:59< celticminstrel> The first is this.
20160206 19:36:05< celticminstrel> The second is the declared argument.
20160206 19:36:13< vultraz> oh, ok
20160206 19:36:52< celticminstrel> But, hmm, this is actually being called from the selected widget?
20160206 19:37:05< celticminstrel> Maybe you can bind the this argument instead of passing it.
20160206 19:37:15< vultraz> I... did
20160206 19:37:18< celticminstrel> Then there'd only be one twidget argument in the boost::function.
20160206 19:37:24< celticminstrel> Okay then.
20160206 19:37:27< celticminstrel> Good for you. :)
20160206 19:37:30< vultraz> 		group_->execute_group_actions(boost::bind(
20160206 19:37:32< vultraz> 			&ttoggle_button::group_operator, this, _1));
20160206 19:37:34< vultraz> right?
20160206 19:37:38 * celticminstrel makes mistakes too sometimes.
20160206 19:37:39< celticminstrel> Yeah.
20160206 19:38:12< vultraz> I needed to do that anyway
20160206 19:38:24< vultraz> since I was passing a function without its argument
20160206 19:44:04< vultraz> error: invalid conversion from 'gui2::twidget*' to 'gui2::ttoggle_button*' [-fpermissive]|
20160206 19:44:27< vultraz> whyyy
20160206 19:44:57< vultraz> ;_;
20160206 19:44:59 * vultraz sobs
20160206 19:47:00< vultraz> WHY IS THAT INVALID
20160206 19:47:05< celticminstrel> You need dynamic_cast for that.
20160206 19:47:18< celticminstrel> But why are you converting that?
20160206 19:48:23< vultraz> that is the bind line I posted above
20160206 19:48:37< celticminstrel> Ah, then use static_cast.
20160206 19:48:42< celticminstrel> Wait.
20160206 19:48:45< vultraz> er... 
20160206 19:48:47< vultraz> wait
20160206 19:49:02< celticminstrel> That doesn't seem to fit the bind line.
20160206 19:49:07< vultraz> ttoggle_button* is the argument type of ::group_operator
20160206 19:49:14< vultraz> maybe that's the problem
20160206 19:49:18< celticminstrel> Maybe.
20160206 19:49:32< vultraz> but in that case
20160206 19:49:35< vultraz> a template is needed
20160206 19:49:39< celticminstrel> Why?
20160206 19:49:50< vultraz> to dynamic cast this bit: group_operator(widget);
20160206 19:49:53< vultraz> like I was doing
20160206 19:50:16< vultraz> maybe..
20160206 19:50:16< celticminstrel> Why do you need to dynamic_cast that?
20160206 19:50:44< vultraz> er
20160206 19:50:46< vultraz> hm
20160206 19:50:48< vultraz> wait
20160206 19:50:50< vultraz> other errors
20160206 19:50:51< vultraz> error: no match for call to '(boost::function<void(gui2::twidget*)>) (gui2::twidget**&)'|
20160206 19:51:25< celticminstrel> The problem with making the function a template if you're trying to genericize it to other widgets is that your design means you could have multiple types of widgets in the same group.
20160206 19:52:01< celticminstrel> What line is that error on?
20160206 19:52:26< vultraz> which is why I was using the previous method but that gave undefined reference errors :|
20160206 19:52:54< vultraz> it's on the "group_operator(widget);" line
20160206 19:53:02< vultraz> int he FOREACH(AUTO * widget, members_) loop
20160206 19:53:04< vultraz> int he *
20160206 19:53:16< celticminstrel> Try *widget instead of widget.
20160206 19:55:44-!- Greg-Boggs [~greg_bogg@199.127.229.254] has quit [Remote host closed the connection]
20160206 19:55:53< vultraz> also telling me rror: cannot convert 'gui2::twidget*' to 'gui2::twidget**' in initialization|
20160206 19:56:04< vultraz> for the FOREACH line : | 
20160206 19:56:11< vultraz> maybe just AUTO widget?
20160206 19:56:23< celticminstrel> No.
20160206 19:56:54< celticminstrel> But the two errors are connected.
20160206 20:00:24< vultraz> elaborate?
20160206 20:01:21< celticminstrel> The error at group_operator is caused by the problem with FOREACH.
20160206 20:01:47< vultraz> oh
20160206 20:06:33< vultraz> well I really don't know what to do
20160206 20:11:40< celticminstrel> What's the type of members_ again?
20160206 20:12:07< vultraz> std::vector<twidget*> members_;
20160206 20:14:13-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 20:19:00< celticminstrel> Maybe AUTO instead of AUTO* is right... why don't you try looking at other places where FOREACH is used?
20160206 20:19:24< celticminstrel> Or well, I suppose you could just try it and see if it works.
20160206 20:21:03< vultraz> nope
20160206 20:22:38< vultraz> doesn't work with *widget (complains about twidget&), &widget (complains about twidget**) (complains about ttoggle_button&)
20160206 20:24:24-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 20:25:35< celticminstrel> Are you changing the FOREACH line or the function call?
20160206 20:25:52-!- Greg-Boggs [~greg_bogg@199.127.229.254] has joined #wesnoth-dev
20160206 20:26:16< vultraz> foreach line
20160206 20:27:23< vultraz> i dont understand why this shouldn't work
20160206 20:28:05< celticminstrel> I think you've basically got it right, just some little detail is wrong somewhere. Try looking at other places where FOREACH is used.
20160206 20:28:57< vultraz> in case i'm missing something from being up all night
20160206 20:28:59< vultraz> full output
20160206 20:29:08< vultraz> http://pastebin.com/YLMMKZ75
20160206 20:31:29-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160206 20:31:51< celticminstrel> Didn't you change group_operator() to take a twidget instead of a ttoggle_button?
20160206 20:32:08< vultraz> was...Isupposed to?
20160206 20:32:13< celticminstrel> Yeah.
20160206 20:32:22< vultraz> wouldn't that invalidate the this == button check?
20160206 20:32:41< celticminstrel> Almost certainly no.
20160206 20:32:49< celticminstrel> But if you're worried, static_cast this to twidget.
20160206 20:32:53< celticminstrel> Then it'll be fine.
20160206 20:33:04< celticminstrel> Definitely fine, rather than almost certainly fine.
20160206 20:33:32< celticminstrel> (It's almost certainly because it could fail in the presence of multiple inheritance.)
20160206 20:33:58< vultraz> IT BUILDS
20160206 20:33:59< vultraz> :D
20160206 20:35:16< vultraz> time for a quick test case
20160206 20:40:11< ancestral> Welcome to #vultrazprogramming
20160206 20:40:49< ancestral> Where you can hear about vultraz programming
20160206 20:40:56< ancestral> Way better than livestreaming ;-)
20160206 20:41:02< vultraz> vultraz failing at programming* :P
20160206 20:44:52< vultraz> damn
20160206 20:44:55< vultraz> doesn't seem to be working :|
20160206 20:44:58< vultraz> why dis :| 
20160206 20:48:23< vultraz> I have no idea
20160206 20:48:25< vultraz> will look tomorrow
20160206 20:48:31< vultraz> celticminstrel: ty for help
20160206 21:17:37-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20160206 21:21:29< gfgtdf> vultraz: you know whether string_to_color accepts the #rrggbb format ?
20160206 21:21:50< gfgtdf> vultraz: the one thats used in color= for unstore_unit for example
20160206 22:37:35-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160206 22:48:21-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev
20160206 23:02:55-!- Kwandulin [~Miranda@p200300760F0BC535BDE8DE7D54F871F0.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160206 23:15:25< Aginor> zookeeper: it 's unrelated to SDL2, we want to keep it for now
20160206 23:28:49-!- Greg-Boggs [~greg_bogg@199.127.229.254] has quit [Remote host closed the connection]
20160206 23:49:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160206 23:54:31-!- louis94 [~~louis94@13.149-243-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
20160206 23:59:56-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
--- Log closed Sun Feb 07 00:00:53 2016